FIVADMI A Framework For In-Vehicle Anomaly Detecti

future internet
Article
FIVADMI: A Framework for In-Vehicle Anomaly Detection by
Monitoring and Isolation †
Khaled Mahbub 1, *, Antonio Nehme 1 , Mohammad Patwary 2 , Marc Lacoste 3 and Sylvain Allio 3
1 College of Computing, Birmingham City University, Birmingham B5 5JU, UK; antonio.nehme@bcu.ac.uk

2 Digital Innovation & Solution Centre, University of Wolverhampton, Wolverhampton WV1 1LY, UK;
patwary@wlv.ac.uk
3 Department of Security, Orange Labs, 38240 Meylan, France; marc.lacoste@orange.com (M.L.);
sylvain.allio@orange.com (S.A.)
* Correspondence: khaled.mahbub@bcu.ac.uk
† This article is a revised and expanded version of a paper entitled “Towards an Integrated In-Vehicle Isolation
and Resilience Framework for Connected Autonomous Vehicles”, which was presented at VEHICULAR 2020,
Porto, Portugal, 18–22 October 2020.
Abstract: Self-driving vehicles have attracted significant attention in the automotive industry that is
heavily investing to reach the level of reliability needed from these safety critical systems. Security of
in-vehicle communications is mandatory to achieve this goal. Most of the existing research to detect
anomalies for in-vehicle communication does not take into account the low processing power of the
in-vehicle Network and ECUs (Electronic Control Units). Also, these approaches do not consider
system level isolation challenges such as side-channel vulnerabilities, that may arise due to adoption
of new technologies in the automotive domain. This paper introduces and discusses the design of a
framework to detect anomalies in in-vehicle communications, including side channel attacks. The
proposed framework supports real time monitoring of data exchanges among the components of
in-vehicle communication network and ensures the isolation of the components in in-vehicle network
by deploying them in Trusted Execution Environments (TEEs). The framework is designed based on
the AUTOSAR open standard for automotive software architecture and framework. The paper also
discusses the implementation and evaluation of the proposed framework.
Citation: Mahbub, K.; Nehme, A.;
Patwary, M.; Lacoste, M.; Allio, S.
Keywords: AUTOSAR; ECU; isolation; resilience; system security
FIVADMI: A Framework for
In-Vehicle Anomaly Detection by
Monitoring and Isolation. Future
Internet 2024, 16, 288. https://
doi.org/10.3390/fi16080288 1. Introduction
Academic Editors: Stefano Rinaldi

Modern vehicles integrate many electronic and mechanical subsystems to provide
and Alan Oliveira De Sá
added-value services such as driving assistance and entertainment functions to drivers and
passengers. Electronic Control Units (ECU) are the major components that coordinate such
Received: 1 July 2024 subsystems. Most often, ECUs are driven by software and need to communicate with each
Revised: 30 July 2024 other and with the outside environment (e.g., external services or other vehicles). While
Accepted: 2 August 2024 the communication among ECUs is enabled by the In-Vehicle Network (IVN), and commu-
Published: 8 August 2024
nication with the external environment can be achieved using various technologies such
as Vehicle-to-Road (V2R) Infrastructure and Vehicle-to-Everything (V2X) connections [1].
While both types of communication enable safety-critical decision-making, in-vehicle com-
munication requires special attention. This is mainly due to the use of Controller Area
Copyright: © 2024 by the authors.
Licensee MDPI, Basel, Switzerland.
Network (CAN), the predominant in-vehicle communication protocol [2].
This article is an open access article
The design and development of CAN did not take IVN cybersecurity and protection
distributed under the terms and into account and vehicles were considered as closed systems [3–7]; this assumption was
conditions of the Creative Commons reasonable when the automated functions in vehicles were not safety critical. However, the
Attribution (CC BY) license (https:// seamless integration of information technology into modern vehicles, capable of performing
creativecommons.org/licenses/by/ critical functions, transformed them into open systems with a large attack surface [5,8].
4.0/). In-vehicle communication based on CAN is not protected against attacks, such as in-vehicle
Future Internet 2024, 16, 288. https://doi.org/10.3390/fi16080288 https://www.mdpi.com/journal/futureinternet

Future Internet 2024, 16, 288 2 of 26
Spoofing, Eavesdropping, DoS, Replay, Injection etc. [4–6,8–10]. Moreover, the adoption of
new technologies in the automotive domain is opening new safety and security challenges.
For example, the advent of new generations of ECUs virtualized as lightweight execution
environments (e.g., VMs, containers) on different types of virtualization platforms (e.g.,
OKL4 microvisor, Proteus hypervisor, ETAS STA-HVR) may face system-level isolation
challenges such as side-channel vulnerabilities.
The development of IVN security countermeasures is hindered by various factors. The
application of sophisticated attack detection mechanisms requires significant amounts of
computing power and therefore cannot be used in vehicles due to the limited ECU process-
ing capabilities [11–13]. Moreover, the implementation of IVN security mechanisms must
ensure that the normal functionalities of the vehicle are not impacted [14]. Improvement
of security and resilience of autonomous vehicles has attracted significant attention in the
literature. A prominent example are approaches inspired by the principle of “security by
design” practiced in the software industry [15–18] and stating that existing secure devel-
opment processes should be adapted and incorporated in the design and development of
autonomous vehicles. These approaches, however, may not be readily acceptable to the
manufacturer as they may require a major redesign of the vehicle or of its components.
Various techniques have been applied to perform real-time IVN detection of threats and
attacks including signature based [2,14], machine learning based [19,20] and frequency
based techniques [7,21,22]. These approaches, however, may not be effective due to the low
processing power of the CAN network and the lack of uniform semantics of CAN messages
across different car makes and models.
This paper is an extended version of our position paper [23] and discusses the design,
implementation and evaluation of a Framework for In-Vehicle Anomaly Detection by
Monitoring and Isolation (FIVADMI). More specifically, FIVADMI supports the detection
of anomalies when ECUs exchange information on a CAN bus based IVN. FIVADMI
adopts a holistic approach that enables detection of anomalies in a compromised vehicle
at the communication level (e.g., Injection and DoS attacks in the CAN bus) as well as
at the application level (e.g., OBD level, such as anomalies in the acceleration or coolant
temperature of a compromised vehicle). For the detection of runtime anomalies, FIVADMI
relies on an external rule engine (CLIPS [24]) to detect novel attacks without any significant
change in the FIVADMI implementation. By analysing the detected anomalies, FIVADMI
produces certificates that reflect the safety and the stability of the current state of the vehicle.
The implementation of FIVADMI is based on the AUTomotive Open System ARchitecture
(AUTOSAR) open standard, version R22-11,for automotive software architecture and
framework. Hence FIVADMI inherently offers scalability, reusability and interoperability
across the product lines from different Original Equipment Manufacturers (OEMs) [25].
FIVADMI also ensures isolation of ECUs on the IVN by deploying each ECU within a
Trusted Execution Environment (TEE), TEE support is being provided by the OpenEnclave
open source project [26].
This paper is structured as follows. Section 2 provides an overview of in-vehicle Elec-
tric/Electronic (E/E) Architecture, in-vehicle threats and existing approaches to mitigate
in-vehicle threats. Section 3 discusses the FIVADMI design principles and architecture.
Section 4 describes the implementation of the main components of FIVADMI. Section 5
presents the experimental results on the evaluation of our implementation. We conclude
in Section 6 discussing the limitations of the current implementation and possible future
improvements.
2. Related Work
In this section, we briefly provide an overview of in-vehicle Electric/Electronic (E/E)
Architecture to highlight different communication patterns in a vehicle. We then focus on
the state of the art of in-vehicle threats. Finally, we present the existing approaches to
mitigate in-vehicle security threats.
Future Internet 2024, 16, x FOR PEER REVIEW 3 of 28
2.1. In-Vehicle E/E Architecture

2.1. In‐Vehicle E/E Architecture
An Electronic Control Unit (ECU) can be considered as an embedded computer in
An Electronic
vehicles that controlsControl
oneUnit
or (ECU) can be considered
more electrical system as or an embedded computer
subsystems. Typically,indifferent
ve‐
hicles that controls
mechanical one or (e.g.,
components more sensors
electricaland
system or subsystems.
actuators) Typically,
are attached different
to ECUs. me‐
In common
chanical components
scenarios, ECUs receive (e.g., sensors
input fromand actuators)
sensors, areECUs
other attached
andto ECUs. In Units
On-Board common sce‐ and
(OBUs)
narios, ECUs
control variousreceive input fromby
functionalities sensors,
managingotherthe
ECUs and On‐Board
actuators. ModernUnits (OBUs)
vehicles and
incorporate
acontrol various functionalities
large number of ECUs. Theby managing
ECUs the actuators.
generally communicateModern withvehicles incorporate
each other a of
by means
large number of buses,
communication ECUs. The
where ECUs generally
buses may varycommunicate
depending with
on each otherattributes
different by meanssuch
of as
communication
speed, capacity,buses, where
etc. Some ofbuses may vary depending
the commonly used busesonare different attributes
(i) Controller Areasuch as
Network
speed, capacity, etc. Some of the commonly used buses are (i) Controller
(CAN), (ii) FlexRay and (iii) CAN with flexible data rate (CAN FD). In-vehicle buses are Area Network
(CAN), (ii) FlexRay and (iii) CAN with flexible data rate (CAN FD). In‐vehicle buses are
interconnected following different architectural patterns depending on the complexity,
interconnected following different architectural patterns depending on the complexity,
bandwidth and real-time requirements of the vehicle [16,27–29]. In the following, we
bandwidth and real‐time requirements of the vehicle [16,27–29]. In the following, we
briefly present the most common in-vehicle network architectures.
briefly present the most common in‐vehicle network architectures.
Hierarchical with Central Gateway E/E Architecture—As shown in Figure 1, in this
Hierarchical with Central Gateway E/E Architecture—As shown in Figure 1, in this
class of architecture, ECUs are installed into different buses interconnected by a central
class of architecture, ECUs are installed into different buses interconnected by a central
gateway. Thehierarchy
gateway. The hierarchycomes
comesfrom fromthethe assignment
assignment of functions
of functions to buses
to buses withwith different
different
bandwidths following their real-time and size requirements [27]. The
bandwidths following their real‐time and size requirements [27]. The central gateway is central gateway is
responsible to manage the inter-ECU communications and to convert
responsible to manage the inter‐ECU communications and to convert data from one bus data from one bus
format to another
format to anotherbus busformat
format[16,27,29].
[16,27,29].
Figure 1.
Figure 1. In‐Vehicle
In-VehicleHierarchical
Hierarchicalwith
withCentral
CentralGateway
GatewayE/EE/E
Architecture [28].[28].
Architecture
Domain‐based E/E
Domain-based E/EArchitecture—As
Architecture—As shown
shownin Figure
in Figure2, in2,this classclass
in this of architecture,
of architecture,
ECUs are grouped
ECUs groupedinto intodifferent
differentdomains
domainsaccording
accordingto similarity
to similarityof functionalities [28]. [28].
of functionalities For For
example, all
example, all the
theECUs
ECUsthatthatrelate
relatetoto
the powertrain
the powertrain control of the
control vehicle
of the can be
vehicle canput
bein one
put in one
domain. While the functionalities of one domain may be for entertainment
domain. While the functionalities of one domain may be for entertainment and comfort and comfort
(e.g., audio,
(e.g., audio, telephony),
telephony),others
othersperform
performsafety‐critical
safety-criticalfunctions
functions (e.g., lane
(e.g., keeping,
lane stabil‐
keeping, stability
control) [1]. All the ECUs in a domain are connected to the same communication bus.
ity control) [1]. All the ECUs in a domain are connected to the same communication bus. The
The activities
activities of each
of each ECU ECUin aindomain
a domain areare controlledbybya asingle
controlled singledomain
domain controller.
controller. Do‐
Domain
main controllers are connected through a common gateway to enable
controllers are connected through a common gateway to enable communication among ECUs communication
among ECUs belonging to different domains [16,27,29].
belonging to different domains [16,27,29].
Single Bus E/E Architecture—As shown in Figure 3, in this class of architecture all the
ECUs are connected to a single bus. This pattern is suitable for a less complex architecture
when a small number of ECUs are used in a vehicle [6,16,27,29].
Future Internet
Future 2024,
Internet 16,16,
2024, 288x FOR PEER REVIEW 4 of 284 of 26
Figure 2. In‐Vehicle Domain‐based E/E Architecture [28].
Single Bus E/E Architecture—As shown in Figure 3, in this class of architecture all
the ECUs
Figure are connected to a single
2. In‐Vehicle bus. This pattern is suitable for a less complex architec‐
Figure 2. In-Vehicle Domain‐based
Domain-basedE/EE/EArchitecture [28].
Architecture [28].
ture when a small number of ECUs are used in a vehicle [6,16,27,29].
Single Bus E/E Architecture—As shown in Figure 3, in this class of architecture all
the ECUs are connected to a single bus. This pattern is suitable for a less complex architec‐
ture when a small number of ECUs are used in a vehicle [6,16,27,29].
Figure 3.
Figure 3. In‐Vehicle
In-Vehicle Single
SingleBus
BusE/E
E/EArchitecture
Architecture[13].
[13].
2.2.
2.2. In-Vehicle Threats
In‐Vehicle Threats
FigureResearch inthe
in
3. In‐Vehicle the areaBus
area
Single ofofautomotive
automotive
E/E safety
safety
Architecture hashas
[13]. demonstrated
demonstrated thatthat modern
modern automobiles
automobiles
are vulnerable
are vulnerable to aa widewide range
range of of security
security attacks and may endanger
endanger thethe safety
safety ofof the
the pas-
2.2. In‐Vehicle
passengers andThreats
drivers. Possible threats can be classified in two broad categories:
sengers and drivers. Possible threats can be classified two broad categories: (i) Physical (i) Phys‐
ical Threats
Threats and and
Research (ii) (ii)
theCyber
inCyber ofThreats
Threats
area [6,15,18,30,31].
[6,15,18,30,31].
automotive safety has demonstrated that modern automobiles
are vulnerable to a wide range of security attacks and may endanger the safety of the
2.2.1.
2.2.1. Physical
andThreats
Physical
passengers Threats
drivers. Possible threats can be classified in two broad categories: (i) Phys‐
ical Threats
In‐vehicle
In-vehicle andspoofing: Threats [6,15,18,30,31].
(ii) Cyber In‐vehicle
spoofing:In-vehicle spoofing
spoofingrefersreferstotoattacks
attackswherewhereananattacker
attacker pretends
pretends to
to have
have another
another identity
identity andand influencesthe
influences thevehicle’s
vehicle’soperation
operation by by providing
providingfalse falseor ormod‐
modified
2.2.1.
ified Physical
data Threats
[2,6,15,31].
data [2,6,15,31].
Denial
In‐vehicle
Denial of
of Service:
spoofing:
Service: InInDenial
In‐vehicle
Denial of of
Service
spoofing
Service(DoS)
refers
(DoS)attacks,
to an attacker
attacks
attacks, an where manages
an
attacker attacker
managesto pretends
compro‐
to compro-
mise a component (e.g., ECU, Sensor etc.) and inhibits
mise a component (e.g., ECU, Sensor etc.) and inhibits the regular operation ofor
to have another identity and influences the vehicle’s the regular
operation by operation
providing of the
false IVN by by
mod‐
the IVN
various
ified datameans such
[2,6,15,31]. as the intentional flooding of the network
various means such as the intentional flooding of the network with messages [1,2,15,18]. with messages [1,2,15,18].
Side‐Channels:
Denial of Service:
Side-Channels: InInside‐channel
Inside-channel attacks,
Denial of Service thethe
(DoS)
attacks, adversary
attacks,
adversary collects
an attackerinformation
collects manages
informationfrom a hid‐a hid-
to compro‐
from
den
mise channel
a componentthat leaks
(e.g., physical
ECU, or logical
Sensor etc.) parameters
and inhibits of regular
the a system and analyses
operation of the the
IVN col‐
by
den channel that leaks physical or logical parameters of a system and analyses the collected
lected
various information
means such toasestablish
the patterns
intentional that canofextract
flooding the privatewith
network information.
messages The hidden
[1,2,15,18].
information to establish patterns that can extract private information. The hidden channel
channel may already In
Side‐Channels: beside‐channel
available inattacks,
hardware the as(such as incollects
adversary a processor’s cache from implemen‐
may already be available in hardware (such in a processor’sinformation
cache implementation), a hid‐ or
tation),
den or is created
channel that leaksusing hardware
physical or and software
logical parameters techniques
of a system[32–35].
and A wide range
analyses the of
col‐
is created using hardware and software techniques [32–35]. A wide range of side-channel
side‐channel attacks have been studied. Some of these, related
lected information to establish patterns that can extract private information. The hidden to the automotive domain,
attacks have been studied. Some of these, related to the automotive domain, are mentioned
are mentioned
channel here. The
may already variation in
be available of CAN
hardwarebus signals
(such as canin be analysed tocache
a processor’s breakimplemen‐
encrypted
here.
and The variationin‐vehicle
authenticated of CAN communication
bus signals canprotocols be analysed (e.g.,topoor
break key encrypted
provisioning andtoauthenti-
ex‐
tation), or is created using hardware and software techniques [32–35]. A wide range of
cated
plore in-vehicle
additional communication
vulnerabilities). protocols
CAN bus (e.g.,
signal poor key
variation provisioning
can be measuredto explore
in additional
different
side‐channel attacks have been studied. Some of these, related to the automotive domain,
vulnerabilities).
ways, for example, CAN accessbus signal variation can using
be measured in different ways, for example,
are mentioned here.a) The variation the wires
of CAN directly
bus signals a high‐precision
can be analysed tooscilloscope,
break encrypted b) a
(a) access
compromised the wires
ECU directly
connected using
to the a high-precision
CAN bus at the oscilloscope,
input and a (b) a compromised
modified CAN controller ECU
and authenticated in‐vehicle communication protocols (e.g., poor key provisioning to ex‐
connected
capable to the
of sampling
plore additional CAN bus at the
the bus at a high
vulnerabilities). input and
CANfrequency a modified
bus signal[34,35].
variationCAN
Even controller
canstronger
be measured capable of
key provisioning sampling
in different
the bus
protocols at a
forhigh
CAN frequency
bus (e.g., [34,35].
Pns‐CAN Even
[36])stronger
can be key
exploited
ways, for example, a) access the wires directly using a high‐precision oscilloscope,provisioning
following protocols
this approachfor CANb) a bus
[34].
(e.g., Pns-CAN
Cache‐based [36])
side‐channel can be
attacksexploited
exploit following
the key‐dependentthis approach
compromised ECU connected to the CAN bus at the input and a modified CAN controller cache [34].
access Cache-based
patterns of side-channel
crypto‐
attacks
capableexploit
graphic the key-dependent
applications.
of sampling Typically,
the bus at athis cache
high accessuses
approach
frequency patterns
a spyof
[34,35]. cryptographic
process
Even keyapplications.
to intentionally
stronger createTypi-
provisioning
cally,
cache this approach
contentions uses
with the a spy process
cryptographic to intentionally
application. The create cache
contentions
protocols for CAN bus (e.g., Pns‐CAN [36]) can be exploited following this approach [34]. contentions
are then analysedwith the
cryptographic application. The contentions are then analysed
Cache‐based side‐channel attacks exploit the key‐dependent cache access patterns of crypto‐ to infer cache access patterns,
which
graphic applications. Typically, this approach uses a spy process to intentionally create by
are in turn associated with likely key values to extract the secret key processed
the cryptographic
cache contentions with application [33,37]. Side
the cryptographic channel attacks
application. are even are
The contentions applicable to Trusted
then analysed
Execution Environment (TEE) [38–41]. For example, Intel SGX (version 1 and 2) suffers
from Page Fault Attacks due to the sharing of memory, managed by the OS, by multiple
enclaves [39,42]. Intel SGX is also vulnerable to interface-based side-channel attacks, which can
be exploited to infer the information of enclave input data, i.e., the observable enclave inter-
face (ECALL/OCALL) invocation patterns (e.g., interface parameter sizes and invocation
delay etc.) determined by different enclave input data [43].
2.2.2. Cyber Threats

Eavesdropping: The attacker may sniff and store messages transmitted among differ-
ent components (e.g., between ECUs) of a vehicle, or between a vehicle and the outside
world. In passive eavesdropping, the attacker may exploit stored messages to achieve various
goals such as extracting critical information (e.g., location or route information of a vehi-
cle) to launch further attacks. In active eavesdropping, the attacker modifies the content of
intercepted messages or creates new messages in different ways such as injection of mali-
cious messages, delay of the transmission of messages, and/or reorder the transmission of
messages, to produce a malicious effect on the operation of the vehicle [2,18,44].
Denial of Service: As for in-vehicle DoS attacks, the attacker may cause disruption
in authorized communication channels by applying different techniques such as jamming
wireless medium or external facing sensors [2,30,45,46].
Replay Attack: In a replay attack, an attacker may record authenticated transmitted
messages. Subsequently, the valid messages are retransmitted to gain entry to the vehicle
or to perform illegitimate operations [15,18,31,47].
Code Modification and Code Injection: The attacker may gain unauthorised access to
some components (e.g., IVN, ECUs) of a vehicle through other types of attacks (e.g., replay
attack) and inject harmful code in ECUs to produce malicious effects or perform malicious
modification to ECU code [2,18].
Packet Fuzzing: The attacker continuously sends invalid data to a component (e.g.,
ECU) to trigger error or fault condition, with an intention that the error condition may
expose security loopholes that can be exploited to carry out further attacks [2,6].
2.3. In-Vehicle Threat Detection and Mitigation Approaches

A significant body of work in the literature focuses on the improvement of resilience
of autonomous vehicles. The measures covered in these works to counter the threats
and attacks on autonomous vehicles can be classified in 3 broad categories, which are
(i) Proactive Defences, (ii) Active Defences and (iii) Passive Defences [2,15–17,31].
2.3.1. Proactive Defences

Proactive defences to improve autonomous vehicle security is underpinned by the
“security by design” principle practiced in the software industry [15,17]. Examples include:
public key encryption to encrypt messages exchanged between ECUs through the CAN
bus [16,27]; or hash-based message authentication to ensure integrity of messages during in-
vehicle communication [18]. Security objectives/requirements should be identified during
the system analysis phase and appropriate control features should be planned during the
system design phase to meet the identified security objectives. The compliance to security
guidelines and a static testing of security policies and components can lead to certifications.
These approaches are invasive in nature, which require a major redesign of the vehicle or
its components and may not be readily acceptable to the manufacturer. Moreover, security
measures implemented following these approaches may not be able to handle new type of
threats that have been discovered after a vehicle has been designed and manufactured [48].
2.3.2. Active Defences

Active defence recommends near real-time encounter of adversaries as they occur. For
example, continuous monitoring can be applied to check the security health conditions of
the autonomous vehicles and take adequate remediation actions (e.g., reconfigure attack
targets and improve tactics to have better control when the attack occurs) [49]. In this sense,
real-time monitoring enables the certification of applications in safety critical systems [50].
For example, the concept of watermarking may be used to detect in real-time replay attacks
and spoofing attacks in the in-vehicle network [31]. A known private signal is inserted in
the system as watermark. The system output is then compared with the expected output
based on the known dynamics of the system. Once monitoring detects an anomaly, Kalman
Filter functions are applied to determine the ideal state of the attack target. Existing IVN
intrusion detection systems can be categorised as (i) Signature-Based, (ii) Anomaly-Based
and (iii) Hybrid [2,13,14,47,51,52].
Signature-Based Detection: These approaches use information about attacks (sig-
natures) as a pattern that characterize known threats, and compare signatures against
observed events to identify possible attacks [47]. Various mechanisms can be used to derive
attacks signatures, e.g., state transition analysis, expert systems, description scripts, etc.
Anomaly-Based Detection: These approaches recommend continuous monitoring
of the activities of a system, checking against a reference model (e.g., profile of the sys-
tem). Alarms are raised if deviation from the reference model is observed [51]. Various
mechanisms can be applied to derive the reference model of the system, such as:
• Artificial Intelligence (AI) and Machine-Learning (ML) Based: ML methods typically
attempt to learn patterns in the data, and can be supervised or unsupervised [19,20,53].
Various models are possible, e.g., Deep learning [19,20].
• Frequency Based: Given that the majority of ECUs in a vehicle communicate at a
regular interval, this approach utilizes known CAN packet frequency between packet
sequences to detect anomalies [7,21,22].
• Statistical Based: These approaches compare the currently observed statistical profile
(e.g., difference of mean, median, mode of a variable or multiple variables of interest) of
the system against a previously determined statistical profile of the system [51,54,55].
Hybrid-Based Approach: combines several IDS techniques (e.g., signature-based and
anomaly-based detection approaches). Since IVN attacks take different forms, a single
approach is not enough to detect all attack types. Hybrid approaches have the potential to
maximize IVN attack detection [2,13,14,52].
In addition, several approaches enable to detect side channel attacks related to the
automotive domain.
• Side channel attacks at the physical layer can be prevented at the hardware level by
applying various techniques, for example, by varying the voltage level in the bus
during transmission (e.g., by using multiple transceivers for each node connected to
the bus) [34].
• Cache-based attacks can be detected by quantifying contentions in shared resources,
associating these contentions with processes (e.g., a victim process), and issuing a
warning at runtime whenever the contentions reach a “suspicious” level [37].
• Interface-based attacks through TEE (SGX) side channels can be detected by continu-
ously tracking the SGX interface events (ecall/ocall) and determine anomaly [50,56].
Work related to side channel attacks range from discussions and demonstrations of
side channel related vulnerabilities [39,42,57–59], mitigations of these attacks with coun-
termeasures at the hardware and software levels [42,58,60], and detections of suspicious
activities suggesting attempts for side channel attacks [61–63]. While the first category
reveals security flaws that often result in reporting vulnerabilities followed by patches
from the software vendors [59] or other countermeasures found the literature (second
category) [42,60], the third category very often uses hardware and software based coun-
ters or other accessories (oscilloscope, CPMs) that can reflect attempts for a side channel
attack [64,65]. It should be noted that existing approaches for active defence may not
be easily applicable in the automotive domain. For example, signature based detection
and machine learning based detection are not easy for the CAN network due to the low
processing power of the network. Moreover, despite CAN being an open protocol, variation
in the specification of transmission of CAN frames in different makes and model hinders to
develop a uniform solution [14,66].
2.3.3. Passive Defences

Passive defence mechanisms mainly focus on detecting, responding and recovering
from a security attack once it occurs. This type of defence is suitable to mitigate malwares
and code injection and modification techniques. Therefore, it does not support adaptive
security mechanisms [16,49,67].
3. FIVADMI: A Framework for Improving In-Vehicle Isolation and Resilience

This section presents an overview of a Framework for In-Vehicle Anomaly Detection
by Monitoring and Isolation (FIVADMI) which supports the detection of IVN anomalies
by monitoring the data packets exchanged among ECUs. The framework also certifies
the IVN state by analysing the monitoring results. In the following sections, we discuss
the FIVADMI design principles, introduce the architecture of the framework, discuss the
monitoring and certification schemes, and provide some implementation considerations.
3.1. FIVADMI Design Principles

The major objective of FIVADMI is to improve in-vehicle resilience by (1) identifying
anomalies in real time in the IVN operation, and (2) taking mitigation actions for the identified
anomalies. FIVADMI aims to deal with different issues that may arise due to the application
of future generation ECUs (e.g., virtualized as lightweight execution environments such
as VMs and Containers) within the vehicle. More specifically, FIVADMI aims to ensure
system-level isolation of ECUs and provide protection against side channel attacks to secure
communications. Moreover, FIVADMI is designed to be scalable, interoperable and reusable.
Resilience: FIVADMI adopts the active defence approach to improve in-vehicle re-
silience, i.e., security properties related to the communication among ECUs are contin-
uously monitored to detect security threats. Proactive defence is not suited to handle
common adaptive security requirements in the cyber and automotive domains: it recom-
mends to design control features to meet security objectives at system design time, which
are then integrated into the system life-time. However, this approach cannot address new
types of threats once the system has been developed. Passive defence is also not suitable for
safety-critical systems, like autonomous vehicles, as that approach detects attacks once they
have occurred. Therefore, FIVADMI takes actions to mitigate the impact of and gracefully
recover from detected security threats. In our context, recovery consists of rolling back (or
forward) to a stable state to overcome an intrusion [68]. A full description of the rolling
back process is out of the scope of this paper. Also, FIVADMI is based on an external rule
engine for real-time detection of anomalies. That approach makes FIVADMI non-invasive,
and is most suitable for the automotive domain.
Isolation and side-channel protection: FIVADMI ensures isolation of ECUs in the
in-vehicle network by deploying each ECU within a Trusted Execution Environment (TEE).
FIVADMI also deploys a component to detect side channel attacks in a vehicular context.
Scalability, interoperability, reusability: FIVADMI is based on the AUTOSAR open
standard for automotive software architecture [25]. This choice gives an assurance of
scalability, interoperability, and reusability.
3.2. FIVADMI Architecture

Figure 4 shows the reference architecture for IVN threat detection and mitigation.
FIVADMI assumes an in-vehicle domain-based E/E architecture. The major components of the
architecture are described next.
Trusted Execution Environment (TEE): Trusted Computing gave birth to a number of
industry initiatives to specify isolated execution environments in the main processor [38,41].
TEE provides security features such as isolated execution, integrity of applications exe-
cuting with the TEE, and confidentiality of application assets. Several hardware vendors
have embedded hardware technologies to support TEE implementations, including AMD
PSP [69], ARM TrustZone [70], EVITA Hardware Security Module (HSM) [71] and Intel SGX
Software Guard Extensions [44]. The Trusted Platform Module (TPM), based on Trusted
the architecture are described next.
Trusted Execution Environment (TEE): Trusted Computing gave birth to a number
of industry initiatives to specify isolated execution environments in the main processor
[38,41]. TEE provides security features such as isolated execution, integrity of applications
executing with the TEE, and confidentiality of application assets. Several hardware ven‐
Future Internet 2024, 16, 288
dors have embedded hardware technologies to support TEE implementations, including 8 of 26
AMD PSP [69], ARM TrustZone [70], EVITA Hardware Security Module (HSM) [71] and
Intel SGX Software Guard Extensions [44]. The Trusted Platform Module (TPM), based on
Computing
Trusted Group (TCG)
Computing Group [56]
(TCG)specifications, is a dedicated
[56] specifications, processor
is a dedicated to secure
processor hardware.
to secure
In this work,
hardware. wework,
In this explore
wehow to apply
explore how toTEE
applyasTEE
execution environments
as execution for ECUs
environments to ensure
for ECUs
isolated
to ensureand secure
isolated andcommunications between
secure communications ECUs. ECUs.
between
Figure
Figure4.4.Reference
ReferenceArchitecture
Architectureof of
FIVADMI.
FIVADMI.
Side
SideChannel
ChannelAttack
AttackMonitor
Monitor (SCAM):
(SCAM): TEEs remain
TEEs vulnerable
remain to side
vulnerable tochannel at‐
side channel at-
tacks [42,58]. This component focuses on the runtime detection of side channel
tacks [42,58]. This component focuses on the runtime detection of side channel attacks (e.g., attacks
(e.g.,
SGX SGX interface
interface basedbased attacks)
attacks) that that are relevant
are relevant in a in a vehicular
vehicular context.
context. Through
Through the the
monitor-
monitoring of Hardware Performance Counters, this component
ing of Hardware Performance Counters, this component flags suspicions rowhammer flags suspicions row‐ and
hammer
cache and and cacheside
covert and channel
covert side channel attacks.
attacks.
Monitoring and Certification Manager
Monitoring and Certification Manager (MCM):
(MCM): ThisThis
component
component performs real‐time
performs real-time
monitoring of security properties related to IVN components (e.g., ECUs)
monitoring of security properties related to IVN components (e.g., ECUs) to detect to detect secu‐
security
rity threats. It applies hybrid techniques (including frequency‐based and
threats. It applies hybrid techniques (including frequency-based and statistical-based statistical‐based
approaches, and deep packet inspection) to detect threats. Based on the validity of the
approaches, and deep packet inspection) to detect threats. Based on the validity of the
security properties, this component also maintains the certificates that certify the valid
security properties, this component also maintains the certificates that certify the valid state
state of ECUs.
of ECUs.
To implement the architecture, FIVADMI adopts the AUTomotive Open System AR‐
To implement the architecture, FIVADMI adopts the AUTomotive Open System AR-
chitecture (AUTOSAR) open standard. The AUTOSAR consortium was formed by major
chitecture (AUTOSAR) open standard. The AUTOSAR consortium was formed by major
automotive OEMs like BMW, Ford, and Daimler Chrysler to standardize the automotive
automotive OEMs like BMW, Ford, and Daimler Chrysler to standardize the automotive
software architecture and framework, thereby facilitating scalability, reusability and in-
teroperability across product lines from different OEMs [25]. By adopting AUTOSAR in
the implementation, FIVADMI inherits the corresponding benefits of that standard (e.g.,
scalability, reusability and interoperability).
In AUTOSAR, ECU software is abstracted as a layered architecture built on top of
the underlying micro-controller hardware [72]. As shown in Figure 5, this architecture is
composed of three layers: namely Basic Software (BSW), Runtime Environment (RTE), and
Application Layer.
In AUTOSAR, ECU software is abstracted as a layered architecture built on top of the
In AUTOSAR, ECU software is abstracted as a layered architecture built on top of the
underlying micro‐controller hardware [72]. As shown in Figure 5, this architecture is com‐
underlying micro‐controller hardware [72]. As shown in Figure 5, this architecture is com‐9 of 26
posed of three layers: namely Basic Software (BSW), Runtime Environment (RTE), and Ap‐
posed of three layers: namely Basic Software (BSW), Runtime Environment (RTE), and Ap‐
plication Layer.
plication Layer.
Figure
Figure 5. Overviewof
5. Overview ofSoftware
SoftwareLayers
LayersHigh‐Level
High-Level View
View [72].
[72].
Figure 5. Overview of Software Layers High‐Level View [72].
Basic Software Layer
Basic Software Layer(BSW): thislayer
(BSW):this layerprovides
provides core
core system
system functionalities.
functionalities. As As
Basic Software Layer (BSW): this layer (i)
provides core system functionalities. As
shown
shown ininFigure
Figure6, 6,
this layer
this has has
layer 3 sub‐layers,Micro-controller
3 sub-layers, Abstraction
(i) Micro‐controller Layer (MCAL)—
Abstraction Layer
shown
contains in Figure 6,
internal driversthis layer
modules has 3 sub‐layers, (i) Micro‐controller Abstraction Layer
(MCAL)—contains internal drivers that access
modules theaccess
that micro-controller and internal
the micro‐controller peripherals
and internal
(MCAL)—contains
directly, internal drivers
ECU Abstraction
(ii) directly, Layermodules that access the micro‐controller
(ECUAL)—interfaces the drivers and
the internal
peripherals (ii) ECU Abstraction Layer (ECUAL)—interfaces the of
drivers MCAL
of the and
peripherals directly, (ii) ECU Abstraction Layer (ECUAL)—interfaces the drivers of the
offers
MCALanand APIoffers
for accessing
an API for peripherals
accessing and externaland
peripherals devices, thusdevices,
external makingthushigher software
making
MCAL and offers an API for accessing peripherals and external devices, thus making
layers
higherindependent
software layers of the hardwareoflayout,
independent Services
and (iii)layout,
the hardware Layer
and (iii) (SL)—provides top level
Services Layer (SL)—
higher software layers independent of the hardware layout, and (iii) Services Layer (SL)—
services
provides(e.g., operating
top level servicessystem,
(e.g., communication,
operating system,management,
communication, andmanagement,
memory services)
and to
provides top level services (e.g., operating system, communication, management, and
memory services) to application
application software components. software components.
memory services) to application software components.
Figure 6. Overview of Software Layers Refined view [72].

Run-Time Environment (RTE): this layer provides communication services to appli-

cation software, acting as a bridge between applications and the BSW layer.
Application Layer: this layer mainly consists of Software Components (SWC) inter-
connected to other SWCs and BSW modules. This layer adopts a component-based style of
architecture that enhances scalability and re-usability of SWCs.
Figure 7 shows the mapping of FIVADMI architecture with the AUTOSAR architecture.
The left side (yellow box) of Figure 7 shows the deployment of virtual ECUs within a TEE
following the AUTOSAR architecture. The right side of Figure 7 shows the Domain Con-
troller, Monitoring & Certification Manager and Side Channel Attack Monitor components
in FIVADMI, developed as Software Components (SWCs) in the application layer of the
AUTOSAR architecture. These components reside within a trusted virtual ECU and collect
connected to other SWCs and BSW modules. This layer adopts a component‐based sty
of architecture that enhances scalability and re‐usability of SWCs.
Figure 7 shows the mapping of FIVADMI architecture with the AUTOSAR archite
ture. The left side (yellow box) of Figure 7 shows the deployment of virtual ECUs withi
Future Internet 2024, 16, 288 a TEE following the AUTOSAR architecture. The right side of Figure 7 shows the Domai
10 of 26
Controller, Monitoring & Certification Manager and Side Channel Attack Monitor com
ponents in FIVADMI, developed as Software Components (SWCs) in the application laye
of the AUTOSAR architecture. These components reside within a trusted virtual ECU an
the data transmitted
collectamong the
the data virtual ECUs
transmitted amongwithin the vehicle.
the virtual ECUsThe collected
within data The
the vehicle. is used
collected da
for monitoring is
the properties related to different ECUs.
used for monitoring the properties related to different ECUs.
Figure
Figure 7. Mapping 7. Mapping
of FIVADMI andofAUTOSAR
FIVADMI and AUTOSAR Architecture.
Architecture.
3.3. Monitoring 3.3.

and Monitoring
Certificationand Certification Manager
Manager
This componentThis component
performs performs
real-time real‐time
monitoring monitoring
of security of security
properties and ofproperties and of beha
behavioural
properties relatedioural properties
to IVN related(e.g.,
components to IVN components
ECUs) to detect(e.g., ECUs) toSecurity
anomalies. detect anomalies. Security pro
properties are
erties are
used to detect threats used
and to detect
attacks threats
at the and attacks
in-vehicle at the in‐vehicle
communication levelcommunication
such as Injectionlevel such a
InjectionBehavioural
attacks or DoS attacks. attacks or DoS attacks.
properties areBehavioural properties
used to detect are used to
behavioural detect behavioural
anomalies of the anom
alies of the vehicle apparent at the application or OBD level, such
vehicle apparent at the application or OBD level, such as anomalies in vehicle acceleration as anomalies in vehic
acceleration Based
or in coolant temperature. or in coolant
on the temperature. Based on
monitoring results, thisthe monitoringalso
component results, this componen
produces
and maintains the certificates of the validity state of individual ECUs and the overall IVN.ECUs an
also produces and maintains the certificates of the validity state of individual
the overall
The UML activity IVN. shown in Figure 8 presents high level view of the FIVADMI
diagram
The UML activity diagram shown in Figure 8 presents high level view of th
monitoring and certification process. The Monitoring and Certification Manager collab-
FIVADMI monitoring and certification process. The Monitoring and Certification Man
orates with a Rule Engine and with the IVN. The Monitoring and Certification Manager
ager collaborates with a Rule Engine and with the IVN. The Monitoring and Certificatio
receives the regular data exchanged among ECUs and forwards them to the Rule Engine to
Manager receives the regular data exchanged among ECUs and forwards them to the Ru
verify the rules corresponding to the security and behavior policy. In the sequel, security
Engine to verify the rules corresponding to the security and behavior policy. In the seque
properties and behavioural properties are denoted as security rules and as OBD rules
respectively.
At first, the Monitoring and Certification Manager creates the data structures to store
runtime data received from the IVN. It then instructs the Rule Engine to create new instances
for the OBD rules, with the corresponding data structures inside the Engine.
When the Monitoring and Certification Manager receives data from the IVN, it in-
structs the Rule Engine to create instances of security rules and to execute all rules against
the received data. After this step, the Monitoring and Certification Manager collects the rule
execution results and analyses them. Based on the monitoring results, the Monitoring and
Certification Manager produces a new certificate or updates the existing one. More detailed
descriptions of the monitoring scheme and of the certification schemes are presented in
Section 4.3.
Future Internet 2024, 16, 288 security properties and behavioural properties are denoted as security rules and as OB
11 of 26
rules respectively.
Figure 8. Overview of Monitoring

Figure 8. Overviewand Certification
of Monitoring andProcess.
Certification Process.
3.4. Certification Model

At first, the Monitoring and Certification Manager creates the data structures to stor
In FIVADMI, the Monitoring
runtime data received andfrom
Certification
the IVN. ItManager and the
then instructs theSide Channel
Rule Engine Attack
to create new in
Monitor perform stances for themonitoring
real-time OBD rules, of with the corresponding
security data structures
properties related to ECUs inside
and the Engine.
of be-
havioural propertiesWhen of thethe Monitoring
vehicle andanomalies.
to detect CertificationThese
Manager receives data
components thenfrom the IVN, it in
produce
structs the Rule
a certificate to certify validEngine
state ofto individual
create instances
ECUs of and
security rules
of the and toIVN.
overall execute all rules
Figure 9 again
the received
shows a high-level structuredata. After
of the this step, thecertificate.
corresponding Monitoring and Certification Manager collects th
rule execution
The main elements of theresults and analyses
Certificate them.
structure areBased on the monitoring results, the Monitorin
the following.
and Certification Manager produces a new certificate
CertificateID: Represents the unique identifier of a generated certificate or updates
duringthe existing one. Mor
monitoring.
detailed descriptions of the monitoring scheme and
MonitoringResultAggregator: Contains the aggregation of monitoring results of the certification schemes
pro- are pre
sented in Section 4.3.
duced by monitoring different components (e.g., ECUs, CAN bus) of the IVN. This element
contains the following sub-elements:
3.4. Certification Model
• AggregationTime: Represents the time of aggregation.
In FIVADMI, the Monitoring and Certification Manager and the Side Channel Attac
• Duration: Specifies time span between monitoring results considered for aggregation
Monitor perform real‐time monitoring of security properties related to ECUs and of be
(setup by external config file).
havioural properties of the vehicle to detect anomalies. These components then produc
• ToMList: Contains a list of TargetOfMonitoring considered for aggregation.
a certificate to certify the valid state of individual ECUs and of the overall IVN. Figure
• AggregationRule: Defines
shows a high‐level how monitoring
structure of theresults should be
corresponding aggregated. For instance,
certificate.
results with numerical values can be aggregated by applying statistical methods (setup
by an external configuration file).
• AggregationResult: Stores the aggregation result.
TargetOfMonitoring (ToM): Represents a component (e.g., ECU, CAN bus) that is
monitored to identify security threats associated with it. This element has the following
sub-elements:
• ToMType: Type of component (e.g., ECU, CAN bus) to be monitored.
• ToMID: Unique IVN component identifier.
• MonitoringRule: Security property related to this component that is monitored.
• MonitoringEvidenceAggregator: Contains aggregation of results by monitoring the

MonitoringRule related to this component. This element contains the following sub-
elements:
a. AggregationTime: Represents the time of aggregation.
b. Duration: Specifies time span between which in-vehicle network data were
considered for monitoring (setup by external configuration file).
c. AggregationRule: Defines how monitoring results should be aggregated. For
instance, results with numerical values can be aggregated by applying statistical
Future Internet 2024, 16, x FOR PEER REVIEW methods (external configuration file). 12 of 28
d. AggregationResult: Stores the aggregation result.
Figure 9.
Figure 9. Overview
OverviewofofCertification
CertificationModel.
Model.
3.5. Side
The Channel Attack of
main elements Monitor
the Certificate structure are the following.
CertificateID:
Side Represents
channel attacks are the unique “noisy”
generally identifier[73],
of a generated certificate
meaning that duringa mon‐
they leave trace that
itoring.
enables flagging suspicious activities. Cache based side channel attacks, including flush
MonitoringResultAggregator:
and reload, Contains
prime and probe and evict the aggregation
and time of be
are proven to monitoring
effective results pro‐ that
approaches
jeopardise the confidentiality of execution in an enclave [42]. The majority of sideele‐
duced by monitoring different components (e.g., ECUs, CAN bus) of the IVN. This channel
ment contains the following sub‐elements:
detection approaches use Hardware Performance Counters (HPCs) which are special regis-
 used
ters AggregationTime:
for performanceRepresents
monitoring the time
[74]. of
HPCaggregation.
based tools reveal run time based software
 Duration: Specifies time span between
and hardware events including CPU cycles and cachemonitoring results considered
hits and missesfor aggregation
[61,63]. Cache Hits
(setup by external config file).
and Misses are among the top key indicators of side channel related activities [61–63], and
 ToMList:
different Contains
patterns a list of TargetOfMonitoring
of abnormalities in these indicators considered for aggregation.
reflects different attack strategies [62].

Many of the detection approaches in the literature use L1, L2 be
AggregationRule: Defines how monitoring results should andaggregated. For in‐ to
L3 Cache attributes
stance, results with numerical values can be aggregated by applying statistical meth‐
detect Cache based side channel attacks [61,63,75]. Machine learning based approach could
ods (setup by an external configuration file).
be an option for similar classifications due to the capability of these approaches to recognise
 AggregationResult: Stores the aggregation result.
complex patterns from different inputs [61]. Simple rules can also be used for less complex
TargetOfMonitoring
classifications. In FIVADMI (ToM): Represents
we adopt a component
rule-based (e.g.,asECU,
approach CAN bus)
it conforms thatthe
with is low
monitored to identify security threats associated with it. This element has the following
sub‐elements:
 ToMType: Type of component (e.g., ECU, CAN bus) to be monitored.
 ToMID: Unique IVN component identifier.
 MonitoringRule: Security property related to this component that is monitored.
 MonitoringEvidenceAggregator: Contains aggregation of results by monitoring the
ware and hardware events including CPU cycles and cache hits and misses [61,63]. Cache
Hits and Misses are among the top key indicators of side channel related activities [61–
63], and different patterns of abnormalities in these indicators reflects different attack
strategies [62]. Many of the detection approaches in the literature use L1, L2 and L3 Cache
Future Internet 2024, 16, 288 attributes to detect Cache based side channel attacks [61,63,75]. Machine learning based 13 of 26
approach could be an option for similar classifications due to the capability of these ap‐
proaches to recognise complex patterns from different inputs [61]. Simple rules can also
be used for less complex classifications. In FIVADMI we adopt rule‐based approach as it
processing power of in-vehicle Network and ECUs. Figure 10 gives an overarching view
conforms with the low processing power of in‐vehicle Network and ECUs. Figure 10 gives
of the design that the Side Channel Attack Monitor in FIVADMI adheres to; through the
an overarching view of the design that the Side Channel Attack Monitor in FIVADMI ad‐
readings on the hardware performance counters, the classification tier uses classification
heres to; through the readings on the hardware performance counters, the classification
rules to flag suspicions of side channel activities.
tier uses classification rules to flag suspicions of side channel activities.
Figure 10.
Figure 10. Overview
Overviewof
ofHPC
HPCBased
BasedDetection
DetectionApproaches
Approachesforfor
Side Channel
Side Attacks.
Channel Attacks.
4. Implementation
4. Implementation of
ofFIVADMI
FIVADMI
This section
This section presents
presents the
the implementation
implementation details
details of
of FIVADMI.
FIVADMI. TheThe first
first part
part highlights
high‐
lights
the the specification
specification of ourof our Trusted
Trusted Execution
Execution Environment.
Environment. This This is followed
is followed withwith a
a detailed
detailed explanation of the technology and algorithms used for our monitoring
explanation of the technology and algorithms used for our monitoring scheme. scheme.
4.1. Trusted
4.1. Trusted Execution
Execution Environment
Environment(TEE)
(TEE)
Open Enclave
Open Enclave(OE)
(OE)is is open
anan source
open project
source to develop
project applications
to develop in a trusted
applications in aexe‐
trusted
cution environment. OE enables to build trusted programmes called enclave applications
execution environment. OE enables to build trusted programmes called enclave applications
that interact with untrusted applications, known as host applications [26]. Through SGX-
enabled operations and support of an Intel CPU with SGX capabilities, enclaves ensure
the confidentiality of execution and protection of data [26]. Figure 11 gives an overview
of the OE architecture. To execute the code of an enclave, a host application, known
to the enclave, calls the interface of the functions in the enclave; these calls are Enclave
Calls (ECalls). Enclaves can also call untrusted functions and services provided by the
operating system through an interface of the host application; these calls are Outside Calls
(OCalls) [76]. ECalls and OCalls are listed as trusted and untrusted functions respectively
in a configuration file before the enclave is built; Edger8r, a tool part of the Intel SGX
SDK, generates the interfaces specified between the host and the enclave using an Enclave
Definition Language (EDL). Interactions are restricted to the specified interfaces throughout
the lifecycle of the enclave [77].
In FIVADMI, an enclave is part of the application layer of the ECU. It hosts OBD
messages essential to define its functionality. In our prototype, the data hosted within
the enclave includes data recorded from real vehicles and used for testing as well as data
generated at runtime to simulate real-life behaviour of in-vehicle traffic. While the dynamic
data is generated at runtime, the static data is stored in encrypted form. Decryption occurs
through a call from the host bound to the enclave.
(ECalls). Enclaves can also call untrusted functions and services provided by the operating
system through an interface of the host application; these calls are Outside Calls (OCalls)
[76]. ECalls and OCalls are listed as trusted and untrusted functions respectively in a con‐
figuration file before the enclave is built; Edger8r, a tool part of the Intel SGX SDK, gener‐
ates the interfaces specified between the host and the enclave using an Enclave Definition
Language (EDL). Interactions are restricted to the specified interfaces throughout the
lifecycle of the enclave [77].
Figure 11.
Figure 11. Overview
Overviewof
ofthe
theOpen
OpenEnclave
EnclaveArchitecture.
Architecture.
4.2. Side Channel Attack

In FIVADMI, Monitor
an enclave is part of the application layer of the ECU. It hosts OBD
messages
HexPADSessential to define
[62,78] is anits functionality.
open-source In our prototype,
implementation theuses
that dataPerf
hosted
andwithin thedetec-
covers
enclave includes data recorded from real vehicles and used for testing as well
tions for a variety of side channel attacks including cache-based attacks. HexPADS uses as data
generated
cache hits, at runtime
cache misses to and
simulate faults asbehaviour
page real‐life of in‐vehicle
HPC attributes; traffic. While
these attributes can the dy‐
be accessed
namic data is generated at runtime, the static data is stored in encrypted form. Decryption
through ‘Windows Performance Monitor’ [79]. We adopted the algorithm of HexPADs
occurs through a call from the host bound to the enclave.
(Figure 12) to detect Cache Side Channel attacks and used Microsoft Excel (version 2016)
to apply the formulas on the readings. Determining the thresholds for the side channel
4.2. Side Channel Attack Monitor
detection algorithm in our environment was done through studying the changes in the
HexPADS [62,78] is an open‐source implementation that uses Perf and covers detec‐
values of the monitored HPC attributes when a side channel attack is performed. To study
tions for a variety of side channel attacks including cache‐based attacks. HexPADS uses
this change, we recorded the values of these attributes for two cases: the first with an
cache hits, cache misses and page faults as HPC attributes; these attributes can be accessed
ECU is running and the second with the same ECU running in parallel with a script that
through ‘Windows Performance Monitor’ [79]. We adopted the algorithm of HexPADs
performs a side channel attack. For each case, we collected the data for 300 min equally
(Figure 12) to detect Cache Side Channel attacks and used Microsoft Excel (version 2016)
spread over 15 iterations. For the attack, we used an open-source project that performs
to apply the formulas on the readings. Determining the thresholds for the side channel
adetection
simple Flush + Reload,
algorithm in ouraenvironment
cache-basedwas sidedone
channel
throughattack [80]. The
studying the approach
changes inincludes
the
two phases: a profiling phase to locate a memory address that is
values of the monitored HPC attributes when a side channel attack is performed. the most engaged
To studyduring
the
thisexecution
Future Internet 2024, 16, x FOR PEER REVIEW
change, weofrecorded
the victim application,
the values of thesefollowed
attributeswith an cases:
for two exploitation
the firstphase
with anthe
15 of
ECUtargets
28
that memory
is running andaddress to perform
the second with thethe Flush
same ECU+ Reload
running[81]. The project
in parallel with aincludes anper‐
script that attacker
application,
forms a side and the attack.
channel executable of a case,
For each Virtual
weECU is the
collected thevictim application.
data for The algorithm
300 min equally spread in
Figure
over 15
shows 12
our shows
iterations. our
Forside
side channel the channel
attack,
detection wedetection algorithm,
used anadopted
algorithm, fromadopted
open‐source from
project that
HexPADS, HexPADS,
performs
with with the
a simple
the threshold
threshold
obtained obtained
Flush + Reload,
from from
studying thestudying
a cache‐based cache the cache
sideactivity
channel activity
inattack
our in our
[80]. The
environment. environment.
approach includes two phases:
a profiling phase to locate a memory address that is the most engaged during the execu‐
tion of the victim application, followed with an exploitation phase the targets that memory
address to perform the Flush + Reload [81]. The project includes an attacker application,
and the executable of a Virtual ECU is the victim application. The algorithm in Figure 12
Figure 12.
Figure TheAlgorithm
12.The Algorithmforfor Cache
Cache Side
Side Channel
Channel Detection.
Detection.
Lookingatatthe
Looking thefigure,
figure,the
the algorithm
algorithm relies
relies on threshold
on threshold values
values of hardware
of hardware perfor-
perfor‐
mance counters
mance countersthat
thatgive
giveearly
earlyindications
indicationsofofsidesidechannel
channel attacks.
attacks. TheThe phase
phase of identifying
of identify‐
these
ing thresholds
these thresholdsenables thethe
enables algorithm
algorithmto to
adapt
adapt to to
different
different operating
operatingsystems
systemsforforthe
theECUs,
leadingleading
ECUs, to increasing the applicability
to increasing of theofproposed
the applicability the proposed approach to autonomous
approach to autonomous vehicles
vehicles using
using chips chips
from from a of
a variety variety
OEM.ofThis
OEM. This algorithm
algorithm is effective
is effective and lightweight,
and lightweight, enabling its
enabling
deployment its deployment
on ECUs that onhave
ECUs thatlimited
very have very limited computational
computational resources.
resources. The Theof the
simplicity
simplicity
rule-basedofapproach
the rule‐based
makesapproach
it suitablemakes it suitable forECUs
for state-of-the-art state‐of‐the‐art
where theECUs
on-chipwhere
memory
the on‐chip memory is limited to 5 MB as indicated
is limited to 5 MB as indicated by a list compiled by NXP [82]. by a list compiled by NXP [82].
4.3. Monitoring Scheme

In FIVADMI, the Monitoring and Certification Manager uses a predefined set of
security rules and of OBD rules. To specify the high‐level rules, we use a variant of
Event Calculus (EC) [83,84], which is a first order temporal logic language. The choice
4.3. Monitoring Scheme

In FIVADMI, the Monitoring and Certification Manager uses a predefined set of
security rules and of OBD rules. To specify the high-level rules, we use a variant of Event
Calculus (EC) [83,84], which is a first order temporal logic language. The choice of event
calculus as the specification language has been motivated by the need for expressing the
rules in terms of events and temporal constraints, which are the driving factors of our
monitoring scheme. In EC, the behaviour of a system is specified in terms of events and
fluents. An event is something that occurs at a specific instance of time and may change
the state of a system. A fluent is a signifier of a system state (e.g., the value of a variable).
The occurrence of an event is signified by the predicate Happens (e, t), which signifies that
an event e occurs at some time t. An event may initiate or terminate a fluent specifying
part of the state of a system. In EC, these effects are represented by the predicates Initiates
(e,f,t) and Terminates (e,f,t), respectively. The former of these predicates signifies that a
fluent f starts to hold after the event e at time t. The latter predicate signifies that a fluent
f ceases to hold after the event e occurs at time t. An EC specification may also use the
predicates Initially (f) and HoldsAt (f,t). The former of these predicates signifies
Future Internet 2024, 16, x FOR PEER REVIEW 16 of that
28 the
fluent f holds in the beginning of the operation of a system and the latter predicate signifies
that the fluent f holds at time t.
In the
Rule rest
IR3 of this
is used tosection, we fluent
update the present the EC rules
CAN_Data. Eachused
timeby the Monitoring
a CAN and Certifi-
frame is received
cation Manager. We then discuss the algorithm that coordinates the monitoring
(signified by the predicate Happens(CAN_Frame(cID, cMsg), cTS)), the values of dID, dMsgprocess.
and dTS in the fluent CAN_Data are updated which is signified by the predicates Initi‐
4.3.1. Rules for Security
ates(CAN_Frame(cID, Properties
cMsg), equalTo(dID, cID),cTS), Initiates(CAN_Frame(cID, cMsg),
Figure 13cMsg),
equalTo(dMsg, showscTS)
rules
andexpressed in EC, to monitor
Initiates(CAN_Frame(cID, injection
cMsg), attack. cTS), cTS).
equalTo(dTS,
Figure
Figure13.
13.EC
ECRules—Injection
Rules—InjectionAttack
AttackDetection.
Detection.
Rule
RuleIR2 IR1issignifies
used to detect IVN injection
the creation of theattacks. FIVADMI appliesdMsg,
fluent CAN_Data(dID, a frequency
dTS) withbasedempty
analysis
values atapproach. By design,
the beginning most
of the CAN messages
monitoring are This
process. transmitted
fluent at regular
will frequencies.
be used to store CAN
These
frame frequencies
source ID, the are message
nearly constant,
contained evenin during
the CAN transitions
frame and between
the timevehicle
stamp driving
of receipt.
modes [2,7,22].
Rule IR3 isFIVADMI
used tochecks
update thethe
difference of arrival times
fluent CAN_Data. between
Each time atwoCAN successive
frame is re-
CAN
ceivedframes fromby
(signified thethe
same source. Happens(CAN_Frame(cID,
predicate If the difference is less thancMsg),
a predefined threshold,
cTS)), the values itof dID,
raises
dMsg and dTS in the fluent CAN_Data are updated which is signified by thehas
an alarm as an injection attack might have occurred. The CAN frame that ar‐
predicates
rived
Initiates(CAN_Frame(cID, cMsg), equalTo(dID, cID),cTS), Initiates(CAN_Frame(cID,IDcMsg),
(signified by the predicate Happens (CAN Frame(cID, cMsg), cTS)) contains the
and time stampcMsg),
equalTo(dMsg, of thecTS)
current
andCAN frame. The fluent CAN_Data
Initiates(CAN_Frame(cID, (signified by cTS),
cMsg), equalTo(dTS, HoldsATcTS).
(CANRule
DataIR2 (dID, dMsg, dTS), cTS)) contains the ID and time stamp of the
is used to detect IVN injection attacks. FIVADMI applies a frequency previous frame.based
The difference of arrival time stamps of two successive CAN frames from the same source
analysis approach. By design, most CAN messages are transmitted at regular frequencies.
is checked. The rule checks that both CAN frames have valid data and different time
These frequencies are nearly constant, even during transitions between vehicle driving
stamps. The rule also checks that both frames are from the same source and that the dif‐
modes [2,7,22]. FIVADMI checks the difference of arrival times between two successive
ference between time stamps is less than a threshold (e.g., 50). If these conditions are vio‐
CAN frames from the same source. If the difference is less than a predefined threshold,
lated, then an alert is raised.
it raises an alarm as an injection attack might have occurred. The CAN frame that has
arrived
4.3.2. (signified
Rules PropertiesHappens (CAN Frame(cID, cMsg), cTS)) contains the ID
by the predicate
for Behavioural
and time stamp of the current CAN frame. The fluent CAN_Data (signified by HoldsAT
Figure 14 shows rules expressed in EC, to detect anomalies in vehicle speed. How‐
(CAN Data (dID, dMsg, dTS), cTS)) contains the ID and time stamp of the previous frame.
ever, it should be noted that similar rules can be specified to detect anomalies in coolant
The difference of arrival time stamps of two successive CAN frames from the same source is
temperature, ambient temperature, and intake air temperature.
checked. The rule checks that both CAN frames have valid data and different time stamps.
The rule also checks that both frames are from the same source and that the difference
CAN frames from the same source. If the difference is less than a predefined threshold, it
raises an alarm as an injection attack might have occurred. The CAN frame that has ar‐
rived (signified by the predicate Happens (CAN Frame(cID, cMsg), cTS)) contains the ID
and time stamp of the current CAN frame. The fluent CAN_Data (signified by HoldsAT
(CAN Data (dID, dMsg, dTS), cTS)) contains the ID and time stamp of the previous frame.
The difference of arrival time stamps of two successive CAN frames from the same source
is checked. The rule checks that both CAN frames have valid data and different time
stamps. The rule also checks that both frames are from the same source and that the dif‐
between
ference time stamps
between is less is
time stamps than
lessathan
threshold (e.g., 50).
a threshold (e.g.,If50).
these conditions
If these are violated,
conditions are vio‐ then
an alert
lated, is an
then raised.
alert is raised.
4.3.2.Rules
4.3.2. Rulesfor
forBehavioural
Behavioural Properties
Properties
Figure1414shows
Figure showsrules
rules expressed
expressed in EC,
in EC, to detect
to detect anomalies
anomalies in vehicle
in vehicle speed.
speed. How‐ How-
temperature,ambient
temperature, ambienttemperature,
temperature, and
and intake
intake air air temperature.
temperature.
Figure14.
Figure ECRules—Vehicle
14.EC Rules—Vehicle Speed
Speed Anomaly
Anomaly Detection.
Detection.
RuleSR1
Rule SR1signifies
signifiesthe
the creation
creation of of
thethe fluent
fluent OBD_Data(dID,
OBD_Data(dID, dSpd,dSpd,
dTS) dTS)
with with
emptyempty
values at the beginning of the monitoring process. This fluent will be used to store store
values at the beginning of the monitoring process. This fluent will be used to CAN CAN
frame source ID,
frame source ID, the vehicle speed reading
reading contained in the CAN frame and the timestamp
contained in the CAN frame and the time
of receipt.
stamp of receipt.
Rule SR4 is used to update the fluent OBD_Data. Each time a CAN frame is re-
ceived (signified by the predicate Happens(CAN Frame(cID, cSpd), cTS)), the values of
dID, dSpdg and dTS in the fluent OBD_Data are updated which is signified by the predi-
cates Initiates(CAN Frame(cID, cSpd), equalTo(dID, cID),cTS), Initiates(CAN Frame(cID, cSpd),
equalTo(dSpd, cSpd), cTS) and Initiates(CAN Frame(cID, cSpd), equalTo(dTS, cTS), cTS).
Rules SR2 and SR3 are used to detect anomalies in acceleration and deceleration respec-
tively. This is done by calculating acceleration (or deceleration) of the vehicle as follows:
(v2 − v1)
Acc = (1)
(t2 − t1)
where v2 and v1 are vehicle speeds at time points t2 and t1 respectively. If the calculated
acceleration (or deceleration) is greater (or lower) than an acceptable threshold, an alarm
is raised.
According to the rule SR2, the CAN frame that has arrived (signified by the predicate
Happens (CAN_Frame (cID, cSpd), cTS)) contains the speed value and time stamp of the
current CAN frame. The fluent OBD_Data (signified by HoldsAT (OBD_Data(dID, dSpd,
dTS), cTS)) contains the speed value and time stamp of the previous frame. The rule checks
that both current CAN_Frame and the previous CAN_Frame have valid speed value and
different time stamps; the acceleration is computed. An alert is raised if the acceleration is
above a threshold.
Rule SR3 checks the anomaly in deceleration, which can be explained in a similar way
as the Rule SR2.
4.3.3. Monitoring Algorithm

Runtime monitoring of security and behavioural rules in FIVADMI is carried out by
a Rule Engine. The current implementation of FIVADMI is based on the CLIPS [24] rule
engine: in typical usage, CLIPS maintains a set of facts and a set of rules, where rules operate
on facts. In CLIPS, a fact is a piece of information (e.g., variable), and a rule takes the form
similar to IF (condition) THEN (action) ELSE (action) statements in a procedural language.
CLIPS uses an improved form of the well-known Rete algorithm [85] to match rules against
facts. Rules written in CLIPS can be considered as data-driven programs, the facts being
the data that trigger execution of rules via the inference engine. The inference engine then
decides which rules should be executed and when.
EC rules described in Sections 4.3.1 and 4.3.2 are easily transformed into corresponding
CLIPS specification. More specifically, fluents in EC are transformed into facts (e.g., the
fluent CAN_Data(dID, dMsg, dTS) is transformed into a fact called CAN_Data to contain id,
message, and timestamp. Similarly, the fluent OBD_Data(dID, dSpd, dTS) is transformed
into a fact called OBD_Data and EC rules are transformed into CLIPS rules. At boot-time,
instances of these rules are created in CLIPS. At runtime, the Monitoring and Certification
Manager receives CAN frames from the IVN, retrieves relevant data from each frame, and
stores these data into facts in CLIPS. Security rules and OBD rules are then run against
these facts.
Future Internet 2024, 16, x FOR PEER REVIEW
Figure 15 shows the algorithm that drives the monitoring process in FIVADMI. 18 of 28 The
monitoring algorithm is divided into three methods.
Figure 15.
Figure 15. Monitoring
MonitoringAlgorithm.
Algorithm.
Method monitoring().
monitoring().ThisThismethod
method starts
starts thethe monitoring
monitoring process.
process. FactsFacts are in
are created
created(lines
CLIPS in CLIPS
1–2). (lines 1–2). The corresponding
The corresponding OBD rules are OBD alsorules are (line
created also created (line in
3). The loop 3).line 4
The loop
drives thein line 4 drives
monitoring the monitoring
process: when a CAN process:
Framewhen a CAN
arrives, Frame arrives,
the security rules andthethe
se‐ OBD
curityare
rules rules and the using
monitored, OBD methods
rules are security_rules_check()
monitored, using methods security_rules_check()
and obd_rules_check() respectively.
and obd_rules_check() respectively.
Method security_rules_check(). Upon receipt of a CAN frame, the ID, message, and
time Method
stamp ofsecurity_rules_check().
the frame are extracted.Upon
Factreceipt
CAN Dataof a CAN frame,
in CLIPS the ID, message,
is updated andThen,
(lines 1–2).
time stamp of the frame are extracted. Fact CAN Data in CLIPS is updated
security rules and corresponding facts are created for each type of threat to be detected(lines 1–2).
Then, security rules and corresponding facts are created for each type of threat to
(lines 3–5). Fact and rule names are made unique by appending the CAN ID and time
be detected (lines 3–5). Fact and rule names are made unique by appending the
stamp. This enables checking security rules for two successive CAN frames coming from
CAN ID and time stamp. This enables checking security rules for two successive CAN
frames coming from the same source. CLIPS executes the security rules and collects
the execution results (line 6–7). According to the dynamics of CLIPS rule engine, if a
security rule triggers a result (e.g., alert or absence of alert) at any time point,
that rule will continue to produce that result for the subsequent time points,
which will be considered as a false positive or false negative. Therefore, security rules
the same source. CLIPS executes the security rules and collects the execution results (line
6–7). According to the dynamics of CLIPS rule engine, if a security rule triggers a result
(e.g., alert or absence of alert) at any time point, that rule will continue to produce that
result for the subsequent time points, which will be considered as a false positive or false
negative. Therefore, security rules that have produced a result are removed from CLIPS.
The result is saved for further analysis during the production of certificates. (line 9).
Method obd_rules_check(). Upon receipt of a CAN frame, the OBD related data
Future Internet 2024, 16, x FOR PEER (e.g.,
REVIEW speed, coolant temperature, intake air temperature and ambient temperature) 19 of 28 is
extracted and checked. Fact OBD_Data is updated accordingly using that data, executing
the corresponding rule. The end of the method is similar to the algorithm for checking the
security rules. results are aggregated over a period of time and used to produce
Monitoring
Monitoring results
certificate, following theare aggregated
certificate over presented
model a period ofintime and used
Section 3.4. to
In produce
FIVADMI, certificate,
a
JSON data structure is used to construct the elements of the certificate. JSONstructure
following the certificate model presented in Section 3.4. In FIVADMI, a JSON data is
is used for
chosen to construct the elements
its lightweight processingof and
the certificate.
low memory JSON is chosen
footprint for itstolightweight
compared older
processing and low
data structures. Usingmemory
JSON, afootprint compared
certificate to older
gets updated data
at the endstructures. Using JSON, a
of each monitoring
certificate
cycle, gets updated
spanning at the end ofperiod
over a configurable each monitoring cycle,
of time, during thespanning overprocess
certification a configurable
of
period of time,
a vehicle. Figureduring the certification
16 shows process ofwith
a skeleton structure a vehicle. Figure 16
the different shows aofskeleton
elements a
structure with the different elements of a certificate.
certificate.
Figure 16. Certificate

Certificate Generated
Generated by
by FIVADMI.
FIVADMI.
5. Results
5. Results
We carried
We carriedoutouta set
a of
setexperiments to evaluate
of experiments the implementation
to evaluate of FIVADMI.ofIn this
the implementation
set of evaluation
FIVADMI. experiments,
In this an environment
set of evaluation experiments, is set
anup that includes
environment is three
set uprunning
that in‐ECUs
connected
cludes viarunning
three the sameECUsCAN connected
bus: one ECU viaisthe
programmed
same CAN tobus:
sendone
and ECU
another to receive
is pro‐
grammed
CAN frames. to send
The and
thirdanother to receive
ECU performs theCAN frames.and
monitoring Thecertification
third ECU functions.
performs This
the monitoring
setup is used forand certification
the evaluation of functions. This setup
anomaly detection, theisresilience
used for the evaluation
of our of
implementation
anomaly
of FIVADMI,detection,
and thetheSide
resilience
Channelof our implementation
Monitor in our framework.of FIVADMI, andof
The rest the Side
this section
Channel Monitor in our framework. The rest of this section discusses
discusses the evaluation of our implementation of FIVADMI: Section 5.1 demonstrates the the evalua‐
tion of our
anomaly implementation
detection functionalityof FIVADMI: Sectionand
of our framework 5.1shows
demonstrates the violations
the detected anomaly with
detection functionality of our framework and shows the detected
sudden accelerations; Section 5.2 tests the resilience of our implementation through violations with
the use
sudden accelerations; Section 5.2 tests the resilience of our implementation
of a fuzzer for the generation of CAN packets; Section 5.3 covers the evaluation of our Side through
the use ofMonitor
Channel a fuzzerand
for discusses
the generation of CAN
the results thatpackets; Section 5.3 covers the evalua‐
we obtained.
tion of our Side Channel Monitor and discusses the results that we obtained.
5.1. Evaluation of the Anomaly Detection

We used data from real vehicles, found on Github [86], to evaluate our frame‐
work. The dataset contains readings for OBD data including speed and temperature
related attributes covered by our rules. The dataset covers readings from different
drivers and vehicles. Using an OBD encoder that we developed, we generated
CAN frames for each record in the dataset for the evaluation. When the dataset
is used for the testing of our monitoring rules, the result of the inspection with the
5.1. Evaluation of the Anomaly Detection

We used data from real vehicles, found on Github [86], to evaluate our framework. The
dataset contains readings for OBD data including speed and temperature related attributes
covered by our rules. The dataset covers readings from different drivers and vehicles.
Using an OBD encoder that we developed, we generated CAN frames for each record in
Future Internet 2024, 16, x FOR PEERthe
REVIEWdataset for the evaluation. When the dataset is used for the testing of our monitoring 20 of 28
rules, the result of the inspection with the speed rules shows a close to zero violation rate
for drivers on the same vehicle and for the same driver on different vehicles. We adopted a
similar approach to that of Taylor et al. [22] to introduce anomalies based on this real data:
et al. [22] to introduce anomalies based on this real data: we raised the rate of the OBD
we raised the rate of the OBD messages. For instance, when the rate of the messages is 10×,
messages. For instance, when the rate of the messages is 10×, the change of speed in
the change
testing dataofisspeed in of
10× that testing data is 10× that of real data.
real data.
Figure
Figure 17 shows the change inin
17 shows the change the
the violation
violation rate
rate (number
(number of violation
of violation alerts/total
alerts/total number
number
ofof alerts)
alerts) for Speed and Intake Air Temperature ToMs in two vehicles. The results show that,
for Speed and Intake Air Temperature ToMs in two vehicles. The results show
while the alerts
that, while for speed
the alerts anomaly
for speed increase
anomaly withwith
increase the rate of speed
the rate change,
of speed thethe
change, temperature
tem‐
rules remain steady. This is due to the minimal change of the temperature
perature rules remain steady. This is due to the minimal change of the temperature related related data in
the
dataevaluated vehicles.
in the evaluated vehicles.
Figure 17.
Figure 17. Violation
ViolationRates
RatesininSpeed
Speedand
andIAT from
IAT different
from vehicles.
different vehicles.
The high
The high observed
observedanomaly
anomalyratio in in
ratio thethe
graph results
graph from
results the the
from configuration of a of a
configuration
threshold value in the monitoring rules. For the purpose of this evaluation,
threshold value in the monitoring rules. For the purpose of this evaluation, the value the value of of
the threshold was chosen to reflect coloured labels implemented as part
the threshold was chosen to reflect coloured labels implemented as part of the FIVADMIof the FIVADMI
framework. In the example above, the Certification Manager is configured to assign a
framework. In the example above, the Certification Manager is configured to assign a
Green label when the anomaly rate for a ToM is less than 25%, Red when greater than
Green label when the anomaly rate for a ToM is less than 25%, Red when greater than 75%,
75%, and Amber otherwise.
and Amber otherwise.
To maximise the adoption of our framework, the monitoring and certification rules
To maximise the adoption of our framework, the monitoring and certification rules are
are configurable to adapt to the specification of different vehicles in terms of frequency of
configurable to adapt to the specification of different vehicles in terms of frequency of OBD
OBD messages from different ECUs, or acceptable speed shifts within a particular
messages from different ECUs, or acceptable speed shifts within a particular timeframe,
timeframe, among other specifications. Similarly to the case described above, real data
among
derived from specifications.
other different driversSimilarly
using theto the vehicle
same case described above,
reflect similar real data
results derived
for speed andfrom
different drivers using the same vehicle reflect similar results for speed and
temperature rules. Figure 18 shows the violation rate alerts for speed rules for different temperature
rules. Figure
drivers. 18 showsdifference
The observed the violation rate
in the alerts for
violation speed
rates rules
seems duefor
todifferent drivers.
the drivers’ beh‐ The
observed difference in the violation rates seems due to the drivers’
viaours: in this case, Driver 3 achieved the most steady driving pattern. behviaours: in this case,
Driver 3 achieved the most steady driving pattern.
Future Internet
Future 2024,
Internet 16,16,
2024, 288x FOR PEER REVIEW 20 of 26
21 of 28
Figure 18.
Figure 18. Violation
Violation Rates
Ratesfor
forSpeed
Speedfor
fordifferent
differentdrivers with
drivers thethe
with same vehicle.
same vehicle.
5.2. Evaluation
5.2. Evaluation of
of the
theResilience
ResilienceofofFIVADMI
FIVADMI
To test
To test the resilience
resilience ofofthe theframework,
framework, a fuzzer
a fuzzer [87][87]
waswasused to generate
used to generateCANCAN
frames. In order to demonstrate the applicability of our framework
frames. In order to demonstrate the applicability of our framework in realistic settings, in realistic settings, we we
configured the fuzzer to produce CAN frames of up to 128 bits
configured the fuzzer to produce CAN frames of up to 128 bits per frame and 100 frames per frame and 100 frames
persecond.
per second. This
This conforms
conformswith withthethesize
sizeofofa real CAN
a real CAN frame
frame andand
CAN CANbit rates [88].[88].
bit rates
FIVADMI was run over a period of two days with CAN frames generated byby
FIVADMI was run over a period of two days with CAN frames generated thethe
fuzzer
fuzzer to verify that these frames do not trigger any malfunction that
to verify that these frames do not trigger any malfunction that will disrupt the functionality will disrupt the
functionality
of the tool [6].ofThethe generated
tool [6]. Thecertificate
generatedincludes
certificatethe includes
followingthe following ToMs: ‘Injec‐
ToMs: ‘Injection’, ‘Speed’,
tion’, ‘Speed’, ‘Intake Air Temperature’, and ‘Coolant’. This proves the diversity of CAN
‘Intake Air Temperature’, and ‘Coolant’. This proves the diversity of CAN frames generated
frames generated by the fuzzer. The Targets of Monitoring and the Aggregation results
by the fuzzer. The Targets of Monitoring and the Aggregation results are updated in the
are updated in the certificate at the end of each monitoring cycle (every 1 min) to include
certificate at the end of each monitoring cycle (every 1 min) to include the results of the
the results of the inspection of newly received CAN frames with the monitoring rules.
inspection of newly received CAN frames with the monitoring rules. Figure 19 shows the
Figure 19 shows the certificate generated by FIVADMI after a two‐day evaluation for
certificate generated by FIVADMI after a two-day evaluation for CAN frames generated
CAN frames generated using the fuzzer, reflecting the resilience of our implementation.
using the fuzzer, reflecting
The Aggregation rules in the theparent
resilience
elementof our implementation.
of the JSON structureThe Aggregation
in the rules in
certificate de‐
the parent element of the JSON structure in the certificate describe,
scribe, in natural language, the rule followed to label the certificate with a colour. In the in natural language,
the rule followed
certificate below, 7to labelare
ToMs thecovered.
certificate
Four with
ToMs a colour. In the
reflect less thancertificate below, 7(ToM
25% of violations ToMs are
covered.
Injection Four
for IDsToMs801, reflect
101, 502 less
andthan 25%ToM).
Speed of violations
Two ToM (ToM
haveInjection
more than for75%
IDs of
801, 101, 502
viola‐
and
tionsSpeed
(ToM ToM).
ID 702 Two ToM have
and Coolant more
ToM). Thethan 75% rate
violation of violations
of the IAT (ToM
ToM isID 702The
66%. andmon‐Coolant
ToM).
itoringThe
ECU violation rate of to
is configured theassign
IAT ToMequal is weight
66%. The to monitoring ECU is configured
the ToM to determine the colour to of
assign
equal weight to
the certificate; the that
given ToM4/7 to of
determine
the ToMsthe are colour
Green, of 1/7the certificate;
is Amber given
and 2/7 that aggre‐
are red, 4/7 of the
ToMs
gationare Green,
result 1/7 is
defaults toAmber
Amber and as the2/7 are red,
colour codeaggregation result
of the certificate as defaults to Amber as the
per our Aggregation
colour code of the
Rule (reflected in thecertificate as per
certificate). We our
shouldAggregation
note that the Rule (reflected Rule
Aggregation in theiscertificate).
configura‐ We
should
ble whichnoteenables
that the Aggregation
assigning moreRule is configurable
weight to a particular which
Targetenables assigningthat
of Monitoring morehasweight
a
more critical functionality than the others.
to a particular Target of Monitoring that has a more critical functionality than the others.
Future Internet 2024, 16, x FOR PEER REVIEW 22 of21
28of 26
Figure 19. Certificate Produced by FIVADMI for Fuzzer‐Generated CAN Frames. (Shortened).
Figure 19. Certificate Produced by FIVADMI for Fuzzer-Generated CAN Frames. (Shortened).
5.3.Evaluation
5.3. Evaluationofofthe
theSide
Side Channel
Channel Monitor
Monitor
ToTovalidate
validateand
andevaluate
evaluate the
the side
side channel
channelattack
attackmonitoring
monitoringof of
FIVADMI, we we
FIVADMI, tested
tested
the implementation on 10 simulations with a side channel attack targeting the running
the implementation on 10 simulations with a side channel attack targeting the running
ECU and 10 simulations when the ECU runs without a side channel attack. Once again to
ECU and 10 simulations when the ECU runs without a side channel attack. Once again
to demonstrate the applicability of FIVADMI in realistic settings, we created ECU based
on an AUTOSAR implementation [89], that emulates ARM Versatile boards [90] following
demonstrate the applicability of FIVADMI in realistic settings, we created ECU based on

an AUTOSAR
the AUTOSARimplementation
specification. It[89], thatbe
should emulates ARM
noted, as ourVersatile boards [90]
implementation wasfollowing
successfully
the AUTOSAR specification. It should be noted, as our implementation was successfully
deployed and executed within a virtual ECU, the framework may have negligible overhead
deployed and executed within a virtual ECU, the framework may have negligible over‐
when deployed in realistic settings. Nevertheless, one possible approach would be to
head when deployed in realistic settings. Nevertheless, one possible approach would be
deploy FIVADMI in a dedicated ECU to avoid any impact that FIVADMI may have on the
to deploy FIVADMI in a dedicated ECU to avoid any impact that FIVADMI may have on
regular operation of a vehicle.
the regular operation of a vehicle.
Each of these simulations is scheduled for 20 min, and the collected data from the
Each of these simulations is scheduled for 20 min, and the collected data from the
performance counter is studied after the execution with our side channel monitor. Out of
performance counter is studied after the execution with our side channel monitor. Out of
the 20 experiments
the 20 experiments shownshownininFigure
Figure20,20,our
our side
side channel
channel successfully
successfully classified
classified 14 cases
14 cases
(highlighted
(highlighted in green); the wrong classifications (highlighted in red) were equally distrib‐ dis-
in green); the wrong classifications (highlighted in red) were equally
tributed between
uted between falsefalse positives
positives andnegatives.
and false false negatives. This reflects
This reflects a 70%
a 70% rate rate of successful
of successful clas‐
classification of side channel attacks.
sification of side channel attacks.
Figure 20.
Figure 20. Classification
ClassificationPerformed
PerformedThrough
ThroughSCAM.
SCAM.
Our implementation
Our implementation has hasa aperformance
performance advantage
advantageover HexPADS
over HexPADS [78],[78],
the Linux
the Linux
based implementation that SCAM is based on. The performance overhead
based implementation that SCAM is based on. The performance overhead derived derived fromfrom
HexPADS’ active defense is not applicable to SCAM. Also, while Hex‐PADS’
HexPADS’ active defense is not applicable to SCAM. Also, while Hex-PADS’ implementa- implemen‐
tation
tion uses
uses a buffer
a buffer to store
to store thethe
HPC HPC reading
reading [78],
[78], Windows
Windows Performance
Performance Monitor
Monitor in
in SCAM
SCAM uses is configured to update a parseable data structure on the disc to minimize
uses is configured to update a parseable data structure on the disc to minimize the memory the
memory usage of the approach. Both SCAM and HexPADS use a statistical classification
usage of the approach. Both SCAM and HexPADS use a statistical classification approach
approach for side channel attacks; both implementations follow a similar process for find‐
for side channel attacks; both implementations follow a similar process for finding the
ing the thresholds used by the classification algorithm.
thresholds used by the classification algorithm.
6. Conclusions and Outlook
6. Conclusions and Outlook
This paper discusses the design, implementation and experimental evaluation of a
This paper discusses the design, implementation and experimental evaluation of a
framework to enhance in‐vehicle isolation and resilience focusing on anomalies in the
framework to enhance in-vehicle isolation and resilience focusing on anomalies in the
communication layer (e.g., injection attack) and application layer (e.g., anomalies in vehi‐
communication layer (e.g., injection attack) and application layer (e.g., anomalies in vehicle
cle speed and coolant temperature). The framework follows an active defence strategy to
speed and coolant temperature). The framework follows an active defence strategy to detect
detect the anomalies in real time. The design and implementation of the framework is
the anomalies
based on AUTOSAR in realopen
time.standard
The design and implementation
to enable of theand
scalability, reusability framework is based on
interoperability
AUTOSAR
across the product lines from different OEMs. AUTOSAR based design is chosen asacross
open standard to enable scalability, reusability and interoperability AU‐ the
product
TOSAR is the most prevalent software architecture for ECUs in the automotive industry. is
lines from different OEMs. AUTOSAR based design is chosen as AUTOSAR
the most prevalent
However, it should besoftware architecture
noted that for ECUs inthe
in our implementation theframework
automotive industry.inside
is deployed However,
itvirtual
should be noted that in our implementation the framework is deployed
ECU, and it collects CAN frames from the CAN bus. Implementation of FIVADMI inside virtual
ECU,
does not use any system library from AUTOSAR, in that sense our framework is not not
and it collects CAN frames from the CAN bus. Implementation of FIVADMI does
use any tied
closely systemwithlibrary from AUTOSAR,
AUTOSAR in that
and can easily be sense our to
adapted framework
non AUTUSAR is not closely
based tied
with AUTOSAR and can easily be adapted to non AUTUSAR based automotive software
architecture (e.g., POSIX based architecture [91]) that is gaining popularity recently.
The next step to enhance the framework would be to react to intrusions on the in-
vehicle network and to recover from attacks. This recovery may be rolling back to a stable
state to overcome an intrusion, or to estimate the stable state by applying different tech-
niques. For example, Kalman filtering can be applied to estimate the correct state of a
system, where system state is defined by the variables including the variables (fluents) mon-
itored by FIVADMI. Kalman filter would estimate the next states of the system independent
of the monitoring done by FIVADMI. If deviation in the value of a monitored variable is
detected by FIVADMI, the system can assume the estimated value for that variable in the
state predicted by Kalman filter.
Author Contributions: Conceptualization—K.M., A.N., M.P., M.L. and S.A.; methodology—K.M.,

A.N. and M.L.; software—A.N.; validation—K.M., A.N., M.P., M.L. and S.A.; investigation—K.M.,
A.N., M.P., M.L. and S.A.; writing—original draft preparation—K.M. and A.N.; writing—K.M. and
A.N.; supervision, K.M. All authors have read and agreed to the published version of the manuscript.
Funding: This study was funded by Orange Labs, France. Commissioned Research Agreement No.
J06171.
Data Availability Statement: The data that support the experiments of this study are publicly
available from https://github.com/cephasax/OBDdatasets (accessed on 04 April 2024). The datasets
generated through simulation during the study can be made available from the corresponding author
on reasonable request.
Conflicts of Interest: Authors have no conflicts of interest to disclose.
References
1. Faezipour, M.; Nourani, M.; Saeed, A.; Addepalli, S. Progress and challenges in intelligent vehicle area networks. Commun. ACM
2012, 55, 90–100. [CrossRef]
2. Lokman, S.-F.; Othman, A.T.; Abu-Bakar, M.-H. Intrusion detection system for automotive controller area network (can) bus
system: A review. EURASIP J. Wirel. Commun. Netw. 2019, 2019, 184. [CrossRef]
3. Aliwa, E.; Rana, O.; Perera, C.; Burnap, P. Cyberattacks and countermeasures for in-vehicle networks. ACM Comput. Surv. (CSUR)
2021, 54, 1–37. [CrossRef]
4. Boudguiga, A.; Klaudel, W.; Boulanger, A.; Chiron, P. A simple intrusion detection method for controller area network. In
Proceedings of the 2016 IEEE International Conference on Communications (ICC), Kuala Lumpur, Malaysia, 23–27 May 2016;
pp. 1–7.
5. Gmiden, M.; Gmiden, M.H.; Trabelsi, H. An intrusion detection method for securing in-vehicle can bus. In Proceedings of the
2016 17th International Conference on Sciences and Techniques of Automatic Control and Computer Engineering (STA), Sousse,
Tunisia, 19–21 December 2016; pp. 176–180.
6. Yang, G.; Tang, C.; Jiang, Z.; Liu, X. Towards interpretable and lightweight intrusion detection for in-vehicle network. In
Proceedings of the 2022 4th International Conference on Communications, Information System and Computer Engineering
(CISCE), Shenzhen, China, 27–29 May 2022; pp. 179–182.
7. Young, C.; Olufowobi, H.; Bloom, G.; Zambreno, J. Automotive intrusion detection based on constant can message frequencies
across vehicle driving modes. In Proceedings of the ACM Workshop on Automotive Cybersecurity, Dallas, TX, USA, 27 March
2019; pp. 9–14.
8. Checkoway, S.; McCoy, D.; Kantor, B.; Anderson, D.; Shacham, H.; Savage, S.; Koscher, K.; Czeskis, A.; Roesner, F.; Kohno, T.
Comprehensive experimental analyses of automotive attack surfaces. In Proceedings of the 20th USENIX Security Symposium
(USENIX Security 11), San Francisco, CA, USA, 8–12 August 2011.
9. Carsten, P.; Andel, T.R.; Yampolskiy, M.; McDonald, J.T. In-vehicle networks: Attacks, vulnerabilities, and proposed solutions.
In Proceedings of the 10th Annual Cyber and Information Security Research Conference, Oak Ridge, TN, USA, 6–8 April 2015;
pp. 1–8.
10. Wolf, M.; Weimerskirch, A.; Paar, C. Security in automotive bus systems. In Workshop on Embedded Security in Cars; Springer:
Bochum, Germany, 2004; pp. 1–13.
11. Hoppe, T.; Kiltz, S.; Dittmann, J. Applying intrusion detection to automotive it-early insights and remaining challenges. J. Inf.
Assur. Secur. (JIAS) 2009, 4, 226–235.
12. Schulze, S.; Pukall, M.; Saake, G.; Hoppe, T.; Dittmann, J. On the need of data management in automotive systems. Datenbanksys-
teme in Business, Technologie und Web (BTW)–13. In Proceedings of the Fachtagung des GI-Fachbereichs” Datenbanken und
Informationssysteme” (DBIS), Munster, Germany, 2–6 March 2009.
13. Tomlinson, A.; Bryans, J.; Shaikh, S.A. Towards viable intrusion detection methods for the automotive controller area network. In
Proceedings of the 2nd ACM Computer Science in Cars Symposium, Munich, Germany, 13–14 September 2018; pp. 1–9.
14. Dupont, G.; Hartog, J.D.; Etalle, S.; Lekidis, A. Network intrusion detection systems for in-vehicle network-technical report. arXiv
2019, arXiv:1905.11587.
15. Chattopadhyay, A.; Lam, K.-Y.; Tavva, Y. Autonomous vehicle: Security by design. IEEE Trans. Intell. Transp. Syst. 2020, 22,
7015–7029. [CrossRef]
16. Daimi, K.; Saed, M.; Bone, S.; Robb, J. Securing vehicle’s electronic control units. In Proceedings of the Twelfth International
Conference on Networking and Services, Lisbon, Portugal, 26–30 June 2016.
17. David, C.; Fry, S. Automotive Security Best Practices. Recommendations for Security and Privacy in the Era of the Next-Generation
Car. 2016. Available online: https://motordna.io/static/stickerlook/images/wp-automotive-security.pdf (accessed on 20 June
2024).
18. Poudel, B.; Munir, A. Design and evaluation of a reconfigurable ecu architecture for secure and dependable automotive cps. IEEE
Trans. Dependable Secur. Comput. 2018, 18, 235–252. [CrossRef]
19. Kang, M.-J.; Kang, J.-W. Intrusion detection system using deep neural network for in-vehicle network security. PLoS ONE 2016,
11, e0155781. [CrossRef] [PubMed]
20. Seo, E.; Song, H.M.; Kim, H.K. Gids: Gan based intrusion detection system for in-vehicle network. In Proceedings of the 2018
16th Annual Conference on Privacy, Security and Trust (PST), Belfast, Northern Ireland, 28–30 August 2018; pp. 1–6.
21. Sanchez, H.S.; Rotondo, D.; Escobet, T.; Puig, V.; Saludes, J.; Quevedo, J. Detection of replay attacks in cyber-physical systems
using a frequency-based signature. J. Frankl. Inst. 2019, 356, 2798–2824. [CrossRef]
22. Taylor, A.; Japkowicz, N.; Leblanc, S. Frequency-based anomaly detection for the automotive can bus. In Proceedings of the 2015
World Congress on Industrial Control Systems Security (WCICSS), London, UK, 14–16 December 2015; pp. 45–49.
23. Mahbub, K.; Patwary, M.; Nehme, A.; Lacoste, M.; Allio, S.; Rafflé, Y. Towards an Integrated In-Vehicle Isolation and Resilience
Framework for Connected Autonomous Vehicles. In Proceedings of the VEHICULAR 2020, Porto, Portugal, 18–22 October 2020.
24. Riley, G. Clips: A Tool for Building Expert Systems. 1999. Available online: https://ntrs.nasa.gov/api/citations/19910014730/
downloads/19910014730.pdf (accessed on 20 June 2024).
25. AUTOSAR. Autosar History. 2017. Available online: https://www.autosar.org/about/history/note (accessed on 20 June 2024).
26. OpenEnclave. Open Enclave sdk. 2019. Available online: https://github.com/openenclave/openenclavenote (accessed on 21
June 2024).
27. Alam, M.S.U. Securing Vehicle Electronic Control Unit (ecu) Communications and Stored Data. Master’s Thesis, School of
Computing, Queen’s University, Kingston, ON, Canada, 2018.
28. Hoang, D.; Park, S.; Rhee, J. Traffic-effective architecture for seamless can-based in-vehicle network systems. In Proceedings
of the 2022 13th International Conference on Information and Communication Technology Convergence (ICTC), Jeju Island,
Republic of Korea, 19–21 October 2022; pp. 1612–1614.
29. Mundhenk, P. Security for Automotive Electrical/Electronic (E/E) Architectures. PhD Thesis, Faculty of Electrical Engineering
and Information Technology, The Technical University of Munich, Munich, Germany, 2017.
30. ENISI. Cyber Security and Resilience of Smart Cars: Good Practices and Recommendations; European Union Agency for Network and
Information Security (ENISA): Athens, Greece, 2016.
31. Marquis, V.; Ho, R.; Rainey, W.; Kimpel, M.; Ghiorzi, J.; Cricchi, W.; Bezzo, N. Toward attack-resilient state estimation and control
of autonomous cyber-physical systems. In Proceedings of the 2018 Systems and Information Engineering Design Symposium
(SIEDS), Charlottesville, VA, USA, 27 April 2018; pp. 70–75.
32. Bazm, M.-M.; Lacoste, M.; Südholt, M.; Menaud, J.-M. Side-channels beyond the cloud edge: New isolation threats and solutions.
In Proceedings of the CSNet 2017: 1st Cyber Security in Networking Conference, Rio de Janeiro, Brazil, 18–20 October 2017;
pp. 1–8.
33. Bazm, M.-M.; Lacoste, M.; Südholt, M.; Menaud, J.-M. Side Channels in the Cloud: Isolation Challenges, Attacks, and Counter-
measures. 2017. hal-01591808. Available online: https://inria.hal.science/hal-01591808 (accessed on 20 June 2024).
34. Jain, S.; Wang, Q.; Arafin, M.T.; Guajardo, J. Probing attacks on physical layer key agreement for automotive controller area
networks. In Proceedings of the 2018 Asian Hardware Oriented Security and Trust Symposium (AsianHOST), Hong Kong, China,
17–18 December 2018; pp. 7–12.
35. O’Flynn, C.; d’Eon, G. Power analysis and fault attacks against secure can: How safe are your keys? SAE Int. J. Transp. Cybersecur.
Priv. 2018, 1, 3–18. [CrossRef]
36. Mueller, A.; Lothspeich, T. Plug-and-secure communication for can. CAN Newsl. 2015, 4, 10–14.
37. Kulah, Y.; Dincer, B.; Yilmaz, C.; Savas, E. Spy detector: An approach for detecting side-channel attacks at runtime. Int. J. Inf.
Secur. 2019, 18, 393–422. [CrossRef]
38. A Secure Technology Alliance Mobile Council White Paper. Trusted Execution Environment (TEE) 101: A primer, Version 1.0, 2018.
Available online: https://www.securetechalliance.org/wp-content/uploads/TEE-101-White-Paper-FINAL2-April-2018.pdf
(accessed on 15 May 2024).
39. Jiang, J.; Soriente, C.; Karame, G. On the challenges of detecting side-channel attacks in sgx. In Proceedings of the 25th
International Symposium on Research in Attacks, Intrusions and Defenses, Limassol, Cyprus, 26–28 October 2022; pp. 86–98.
40. Moghimi, D.; Van Bulck, J.; Heninger, N.; Piessens, F.; Sunar, B. Copycat: Controlled instruction-level attacks on enclaves. In
Proceedings of the 29th USENIX Security Symposium (USENIX Security 20), Boston, MA, USA, 12–14 August 2020; pp. 469–486.
41. Sabt, M.; Achemlal, M.; Bouabdallah, A. Trusted execution environment: What it is, and what it is not. In Proceedings of the 2015
IEEE Trustcom/BigDataSE/ISPA, Helsinki, Finland, 20–22 August 2015; pp. 57–64.
42. Brasser, F.; Müller, U.; Dmitrienko, A.; Kostiainen, K.; Capkun, S.; Sadeghi, A.-R. Software grand exposure: Sgx cache attacks
are practical. In Proceedings of the 11th USENIX Conference on Offensive Technologies (WOOT’17), Berkeley, CA, USA, 16–18
August 2017.
43. Wang, J.; Cheng, Y.; Li, Q.; Jiang, Y. Interface-based side channel attack against intel sgx. 2018. Available online: https:
//arxiv.org/abs/1811.05378 (accessed on 15 March 2024).
44. Ekberg, J.-E.; Kostiainen, K.; Asokan, N. Trusted execution environments on mobile devices. In Proceedings of the 2013 ACM
SIGSAC Conference on Computer & Communications Security, Berlin, Germany, 4–8 November 2013; pp. 1497–1498.
45. Ohira, S.; Desta, A.; Arai, I.; Inoue, H.; Fujikawa, K. Normal and malicious sliding windows similarity analysis method for fast
and accurate ids against dos attacks on in-vehicle networks. IEEE Access 2020, 8, 42422–42435. [CrossRef]
46. Stotz, J.P.; Bißmeyer, N.; Kargl, F.; Dietzel, S.; Papadimitratos, P.; Schleiffer, C. Security requirements of vehicle security architec-
ture. Deliverable: D1.1, PRESERVE. 2011. Available online: https://www.preserve-project.eu/www.preserve-project.eu/sites/
preserve-project.eu/files/PRESERVE-D1.1-Security%20Requirements%20of%20Vehicle%20Security%20Architecture.pdf (ac-
cessed on 15 May 2024).
47. Karopoulos, G.; Kambourakis, G.; Chatzoglou, E.; Hern’andez-Ramos, J.; Kouliaridis, V. Demystifying in-vehicle intrusion
detection systems: A survey of surveys and a meta-taxonomy. Electronics 2022, 11, 1072. [CrossRef]
48. Hamad, M.; Nolte, M.; Prevelakis, V. A framework for policy based secure intra vehicle communication. In Proceedings of the
2017 IEEE Vehicular Networking Conference (VNC), Torino, Italy, 27–29 November 2017; pp. 1–8.
49. Thing, V.L.; Wu, J. Autonomous vehicle security: A taxonomy of attacks and defences. In Proceedings of the 2016 IEEE
International Conference on Internet of Things (iThings) and IEEE Green Computing and Communications (GreenCom) and
IEEE Cyber, Physical and Social Computing (CPSCom) and IEEE Smart Data (SmartData), Chengdu, China, 15–18 December
2016; pp. 164–170.
50. Motruk, B.; Diemer, J.; Buchty, R.; Ernst, R.; Berekovic, M. Idamc: A many-core platform with run-time monitoring for mixed-
criticality. In Proceedings of the 2012 IEEE 14th International Symposium on High-Assurance Systems Engineering, Omaha, NE,
USA, 25–27 October 2012; pp. 24–31.
51. Jo, W.; Kim, S.; Kim, H.; Shin, Y.; Shon, T. Automatic whitelist generation system for ethernet based in-vehicle network. Comput.
Ind. 2022, 142, 103735. [CrossRef]
52. Kumar, M.; Bhandari, A. A review of detection approaches for distributed denial of service attacks. Syst. Sci. Control Eng. 2017, 5,
301–320.
53. Dalila Ressi, Riccardo Romanello, Carla Piazza, Sabina Rossi: AI-enhanced blockchain technology: A review of advancements
and opportunities. J. Netw. Comput. Appl. 2024, 225, 103858. [CrossRef]
54. Qayyum, A.; Islam, M.H.; Jamil, M. Taxonomy of statistical based anomaly detection techniques for intrusion detection. In
Proceedings of the IEEE Symposium on Emerging Technologies, Islamabad, Pakistan, 18 September 2005; pp. 270–276.
55. Sivasamy, A.A.; Sundan, B. A dynamic intrusion detection system based on multivariate hotelling’s t2 statistics approach for
network environments. Sci. World J. 2015, 2015, 850153. [CrossRef] [PubMed]
56. TCG. Trusted Computing Group (tcg). 2015. Available online: https://trustedcomputinggroup.org/wpcontent/uploads/
TCGStorageArchitectureCoreSpecv2.01r1.00.pdf (accessed on 15 May 2024).
57. Hund, R.; Willems, C.; Holz, T. Practical timing side channel attacks against kernel space aslr. In Proceedings of the 2013 IEEE
Symposium on Security and Privacy, San Francisco, CA, USA, 19–22 May 2013.
58. Schwarz, M.; Weiser, S.; Gruss, D.; Maurice, C.; Mangard, S. Malware guard extension: Using sgx to conceal cache attacks. In
Proceedings of the Detection of Intrusions and Malware, and Vulnerability Assessment. DIMVA 2017, Bonn, Germany, 6–7 July
2017; Volume 10327 of Lecture Notes in Computer Science. Springer: Berlin/Heidelberg, Germany, 2017.
59. Van Bulck, J.; Oswald, D.; Marin, E.; Aldoseri, A.; Garcia, F.D.; Piessens, F. A tale of two worlds: Assessing the vulnerability of
enclave shielding runtimes. In Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security,
London, UK, 11–15 November 2019.
60. Khandaker, M.R.; Cheng, Y.; Wang, Z.; Wei, T. Coin attacks: On insecurity of enclave untrusted interfaces in sgx. In Proceedings
of the Twenty-Fifth International Conference on Architectural Support for Programming Languages and Operating Systems,
Lausanne, Switzerland, 16–20 March 2020.
61. Mushtaq, M.; Akram, A.; Bhatti, M.K.; Chaudhry, M.; Lapotre, V.; Gogniat, G. Nights-watch: A cache-based side-channel intrusion
detector using hardware performance counters. In Proceedings of the 7th International Workshop on Hardware and Architectural
Support for Security and Privacy, Los Angeles, CA, USA, 2 June 2018.
62. Payer, M. Hexpads: A platform to detect ”stealth” attacks. In Proceedings of the International Symposium on Engineering Secure
Software and Systems, London, UK, 6–8 April 2016.
63. Wang, H.; Sayadi, H.; Rafatirad, S.; Sasan, A.; Homayoun, H. Scarf: Detecting side-channel attacks at real-time using low-level
hardware features. In Proceedings of the 2020 IEEE 26th International Symposium on On-Line Testing and Robust System Design
(IOLTS), Naples, Italy, 13–15 July 2020.
64. Bazm, M.-M.; Sautereau, T.; Lacoste, M.; Sudholt, M.; Menaud, J.-M. Cache-based side-channel attacks detection through intel
cache monitoring technology and hardware performance counters. In Proceedings of the 2018 Third International Conference on
Fog and Mobile Edge Computing (FMEC), Barcelona, Spain, 23–26 April 2018.
65. Gamaarachchi, H.; Ganegoda, H. Power analysis based side channel attack. arXiv 2018, arXiv:1801.00932.
66. Palanca, A.; Evenchick, E.; Maggi, F.; Zanero, S. A stealth, selective, link-layer denial-of-service attack against automotive networks.
In Proceedings of the Detection of Intrusions and Malware, and Vulnerability Assessment: 14th International Conference, DIMVA
2017, Bonn, Germany, 6–7 July 2017; Proceedings 14; Springer: Berlin/Heidelberg, Germany, 2017; pp. 185–206.
67. Xie, Y.; Zhou, Y.; Xu, J.; Zhou, J.; Chen, X.; Xiao, F. Cybersecurity protection on in-vehicle networks for distributed automotive
cyber-physical systems: State-of-the-art and future challenges. Softw. Pract. Exp. 2021, 51, 2108–2127. [CrossRef]
68. Binun, A.; Bloch, M.; Dolev, S.; Kahil, M.R.; Menuhin, B.; Yagel, R.; Coupaye, T.; Lacoste, M.; Wailly, A. Self-stabilizing virtual
machine hypervisor architecture for resilient cloud. In Proceedings of the 2014 IEEE World Congress on Services, Anchorage, AK,
USA, 27 June–2 July 2014; pp. 200–207.
69. Huang, A.; Liu, Y.; Chen, T.; Zhou, Y.; Sun, Q.; Chai, H.; Yang, Q. Starfl: Hybrid federated learning architecture for smart urban
computing. ACM Trans. Intell. Syst. Technol. (TIST) 2021, 12, 1–23. [CrossRef]
70. Thornton, S. Globalplatform Trusted Execution Environment and Trustzone. 2017. Available online: https://www.
microcontrollertips.com/embedded-security-brief-arm-trustzone-explained/ (accessed on 12 November 2023).
71. Wolf, M.; Gendrullis, T. Design, implementation, and evaluation of a vehicular hardware security module. In Proceedings of the
International Conference on Information Security and Cryptology, Seoul, Republics of Korea, 30 November–2 December 2011;
Springer: Berlin/Heidelberg, Germany, 2011; pp. 302–318.
72. AUTOSAR. Autosar: Layered Software Architecture. 2017. Available online: https://www.autosar.org/fileadmin/standards/R4
-3/CP/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf (accessed on 4 April 2024).
73. Paundu, A.W.; Fall, D.; Miyamoto, D.; Kadobayashi, Y. Leveraging Kvm Events To Detect Cache-Based Side Channel Attacks In A
Virtualization Environment. Secur. Commun. Netw. 2018, 2018, 1–18. [CrossRef]
74. Akram, A.; Mushtaq, M.; Bhatti, M.K.; Lapotre, V.; Gogniat, G. Meet the sherlock holmes’ of side channel leakage: A survey of
cache sca detection techniques. IEEE Access 2020, 8, 70836–70860. [CrossRef]
75. Zhang, T.; Zhang, Y.; Lee, R.B. Cloudradar: A real-time side-channel attack detection system in clouds. In Proceedings of the
International Symposium on Research in Attacks, Intrusions, and Defenses, Crete, Greece, 10–12 September 2018; Springer: Cham,
Switzerland, 2016.
76. Intel. Intel Software Guard Extensions Developer Guide. 2016. Available online: https://software.intel.com/enus/node/702976
(accessed on 20 March 2024).
77. Intel. Intel Software Guard Extension sdk for linux os. 2023. Available online: https://download.01.org/intel-sgx/latest/linux-
latest/docs/Intel_SGX_SDK_Release_Notes_Linux_2.22_Open_Source.pdf (accessed on 15 March 2024).
78. HexHive. Hexpads, a Host-Based, Performance-Counter-Based Attack Detection System. 2018. Available online: https:
//github.com/HexHive/HexPADS (accessed on 20 April 2024).
79. Microsoft. Overview of Windows Performance Monitor. 2023. Available online: https://learn.microsoft.com/en-us/previous-
versions/windows/it-pro/windows-server-2008-r2-and-2008/cc749154(v=ws.11) (accessed on 10 March 2024).
80. IAIK. Cache Template Attacks. 2019. Available online: https://github.com/IAIK/cachetemplateattacks (accessed on 15 December
2023).
81. Gruss, D.; Spreitzer, R.; Mangard, S. Cache template attacks: Automating attacks on inclusive last-level caches. In Proceedings of
the 24th USENIX Security Symposium (USENIX Security 15), Washington, DC, USA, 12–14 August 2015.
82. NXP, i. MX RT Crossover MCUs. 2024. Available online: https://www.nxp.com/products/processors-and-microcontrollers/
arm-microcontrollers/i-mx-rt-crossover-mcus:IMX-RT-SERIES (accessed on 26 July 2024).
83. Mahbub, K.; Spanoudakis, G. Monitoring ws-agreements: An event calculus–based approach. In Test and Analysis of Web Services;
Springer: Berlin/Heidelberg, Germany, 2007; pp. 265–306.
84. Shanahan, M. The Event Calculus Explained; Springer: Berlin/Heidelberg, Germany, 1999.
85. Doorenbos, R. Production Matching for Large Learning Systems. PhD Thesis, Carnegie Mellon University, Pittsburgh, PA, USA,
1995.
86. Barreto, C. Obddatasets. 2019. Available online: https://github.com/cephasax/OBDdatasets (accessed on 4 April 2024).
87. CaringCaribou. Caring Caribou, a Friendly Car Exploration Tool. 2018. Available online: https://github.com/CaringCaribou/
caringcaribou (accessed on 8 August 2023).
88. Andreica, T.; Curiac, C.-D.; Jichici, C.; Groza, B. Android Head Units vs. In-Vehicle ECUs: Performance Assessment for Deploying
In-Vehicle Intrusion Detection Systems for the CAN Bus. IEEE Access 2022, 10, 95161–95178. [CrossRef]
89. Parai Wang. Automotive Software and Its Tool-Chain. Available online: https://github.com/autoas/as/ (accessed on 26 July
2024).
90. Arm Versatile Boards. Available online: https://www.qemu.org/docs/master/system/arm/versatile.html (accessed on 26 July
2024).
91. Thoen, F.; Smart, K.; Amringer, N. Accelerating Development of Software-Defined Vehicles with Virtual ECUs. White Paper,
Synopsis. Available online: https://www.synopsys.com/content/dam/synopsys/verification/white-papers/virtual-ecu-wp.
pdf (accessed on 26 July 2024).
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual
author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to
people or property resulting from any ideas, methods, instructions or products referred to in the content.

FIVADMI A Framework For In-Vehicle Anomaly Detecti

Uploaded by

Copyright:

Available Formats

FIVADMI A Framework For In-Vehicle Anomaly Detecti

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FIVADMI A Framework For In-Vehicle Anomaly Detecti

Uploaded by

Copyright:

Available Formats

future internet

1 College of Computing, Birmingham City University, Birmingham B5 5JU, UK; antonio.nehme@bcu.ac.uk

Academic Editors: Stefano Rinaldi

Future Internet 2024, 16, 288. https://doi.org/10.3390/fi16080288 https://www.mdpi.com/journal/futureinternet

2.1. In-Vehicle E/E Architecture

Figure 2. In‐Vehicle Domain‐based E/E Architecture [28].

2.2.2. Cyber Threats

2.3. In-Vehicle Threat Detection and Mitigation Approaches

2.3.1. Proactive Defences

2.3.2. Active Defences

2.3.3. Passive Defences

3. FIVADMI: A Framework for Improving In-Vehicle Isolation and Resilience

3.1. FIVADMI Design Principles

3.2. FIVADMI Architecture

Figure 6. Overview of Software Layers Refined view [72].

Run-Time Environment (RTE): this layer provides communication services to appli-

3.3. Monitoring 3.3.

Figure 8. Overview of Monitoring

3.4. Certification Model

• MonitoringEvidenceAggregator: Contains aggregation of results by monitoring the

4.2. Side Channel Attack

4.3. Monitoring Scheme

4.3. Monitoring Scheme

4.3.3. Monitoring Algorithm

Figure 16. Certificate

5.1. Evaluation of the Anomaly Detection

5.1. Evaluation of the Anomaly Detection

Future Internet 2024, 16, 288 22 of 26

demonstrate the applicability of FIVADMI in realistic settings, we created ECU based on

Author Contributions: Conceptualization—K.M., A.N., M.P., M.L. and S.A.; methodology—K.M.,

You might also like