VEHICULAR 2020 : The Ninth International Conference on Advances in Vehicular Systems, Technologies and Applications

Towards an Integrated In-Vehicle Isolation and Resilience Framework for

Connected Autonomous Vehicles

Khaled Mahbub, Mohammad Patwary, Antonio Marc Lacoste, Sylvain Allio, Yvan Rafflé
Nehme Orange Labs
Birmingham City University France
Birmingham, United Kingdom Email:{firstname.lastname}@orange.com
Email:{firstname.lastname}@bcu.ac.uk

Abstract—Connected Autonomous Vehicles (CAV) have Internal security barriers to detect and react to an
attracted significant attention, specifically due to successful intrusion are therefore needed to limit the impact of a
deployment of ultra-reliable low-latency communications with compromise and to mitigate its propagation to different
Fifth Generation (5G) wireless networks. Due to the safety- subsystems within a vehicle [1]. Moreover, the adoption of
critical nature of CAV, reliability is one of the well-investigated
areas of research. Security of in-vehicle communications is
new technologies in the automotive domain is opening new
mandatory to achieve this goal. Unfortunately, existing safety and security challenges. For example, the advent of
research so far focused on in-vehicle isolation or resilience new generations of ECUs that are virtualized as lightweight
independently. This short paper presents the elements of an execution environments (e.g., virtual machines, containers)
integrated in-vehicle isolation and resilience framework to on different types of virtualization platforms, (e.g., OKL4
attain a higher degree of reliability for CAV systems. The Microvisor, Proteus Hypervisor, ETAS STA-HVR [3]) may
proposed framework architecture leverages benefits of Trusted face system-level isolation challenges such as side-channels.
Execution Environments to mitigate several classes of threats. This short paper introduces our approach to detect and
The framework implementation is also mapped to the limit the impact of intrusions for in-vehicle networks that
AUTOSAR open automotive standard.
can compromise the safety of autonomous vehicles. This
Keywords - Isolation; Resilience; ECU; Monitoring; Trusted will be a step towards enhancing the robustness of in-
Execution Environment; AUTOSAR; Certification. vehicle communications through the isolation of ECUs, the
detection of and recovery from intrusions. Focusing on
I. INTRODUCTION spoofing, replay, and side-channel attacks, we present
principles of a framework for in-vehicle isolation and
Despite considerable progress in the last decade, the resilience and discuss technical considerations for its
development of fully self-driving vehicles is still largely implementation according to the AUTomotive Open System
under research and experimentation. In such safety-critical ARchitecture (AUTOSAR) open standard.
systems, the resilience of in-vehicle and inter-vehicle This paper is structured as follows: Section II presents
communication is a key element to ensure the security of the related work. Section III introduces our framework and
vehicle. While in-vehicle relates to on-board communication Section IV discusses considerations to adhere to the
between Electronic Control Units (ECUs) acting based on AUTOSAR standard. We conclude our paper in Section V.
inputs from different sensors, inter-vehicular
communications enable data exchange with the external II. RELATED WORK
environment including other vehicles, broadband clouds and A significant body of work focuses on improving
roadside-infrastructures [1]. resilience of connected autonomous vehicles. Solutions
In this system of systems model, the diversity, autonomy against threats can be categorised as i) Proactive Defence,
and connectivity of vehicles mean vulnerabilities at the level ii) Active Defence and iii) Passive Defence [4]-[8]. We give
of the vehicle affect the larger environment [2]. While both next a brief overview of each family of techniques.
types of communication enable safety-critical decision-
making, in-vehicle communication requires special
attention. The disparity of coding practices among the A. Proactive Defence
diversity of specialised vendors in different functionalities Proactive defence is underpinned by the “security by
(e.g., infotainment, braking and steering assistance), and the design” principle practiced in the software industry [6],[7].
trust model induced by the high degree of connectivity and Integration of common security practices, public key
unrestricted interactions between vehicle components to encryption and hash-based message authentication fall
enable comfort features (e.g., adjusting the sound volume under this category [4],[9].
according to the velocity) widen the attack surface [1].

Copyright (c) IARIA, 2020. ISBN: 978-1-61208-795-5 15

VEHICULAR 2020 : The Ninth International Conference on Advances in Vehicular Systems, Technologies and Applications

B. Active Defence III. IN-VEHICLE ISOLATION AND RESILIENCE

Active defence mitigates threats as they occur. For We adopt the active defence approach to improve in-
instance, continuous monitoring can be applied to detect vehicle resilience: security properties related to the
intrusions and preserve the security hygiene of the vehicle communication among ECUs will be continuously
and take adequate remediation actions [10]; in this sense, monitored in order to detect security threats, and actions
real-time monitoring enables the identification and isolation will be taken to mitigate the impact of and gracefully
of faulty applications in safety-critical systems [11]. recover from the detected threat. Recovery in our context
Detection approaches for the in-vehicle network can be consists of rolling back (or forward) to a stable state to
categorised as i) Signature-Based Detection, ii) Anomaly- overcome intrusions [27].
Based Detection and iii) Hybrid Approach [12]-[15]:
• Signature-Based Detection: These approaches use
information about attacks (signatures) as a pattern
characterizing known threats, comparing signatures
against observed events to identify possible attacks.
• Anomaly-Based Detection: These approaches are based
on continuous monitoring of system activities, checking
against a reference model (e.g., profile of the system).
An alarm is raised if deviation from the reference
model is observed. Various mechanisms can be applied
to derive the reference model, such as machine learning
[16],[17], frequency-based [18]-[20], and statistical-
based methods [21],[22].
• Hybrid Approach: This family of approach comprises
several intrusion detection techniques (e.g., signature-
and anomaly-based detection).
In addition to in-vehicle intrusion detection, several
approaches explore detection of side channel attacks for the
automotive domain - at the physical layer [23], using cache- Figure 1. Reference Architecture of Isolation and Resilience Framework
based [24] or interface-based approaches [25],[26].
C. Passive Defence Figure 1 shows the proposed reference architecture for
threat detection and mitigation in the in-vehicle network.
Passive defence mainly focuses on detecting, responding ECUs are grouped into different domains according to
to, and recovering from an attack once it has occurred. This similarity of functionalities. All ECUs in a domain are
type of defence is notably suitable to prevent malwares and connected to the same communication bus and activities of
code injection and modification threats. Therefore, passive each ECU in a domain are controlled by one domain
defences are not suitable for safety-critical systems, like controller. Domain controllers are connected through a
autonomous vehicles, as these approaches do not facilitate common gateway in order to enable communication among
detection and mitigation of adversaries in real-time [8],[10]. the ECUs belong to different domains [4],[9]. The major
It should be noted that proactive defence and passive components of the architecture are:
defence are not suitable to handle adaptive security
requirements, very common in the cyber and the automotive A. Trusted Execution Environment (TEE)
domains. Proactive defence recommends designing control Trusted Execution Environments enable to specify
features to meet the security objectives at system design isolated execution environment in the main processor
time and embedding such features in the system. However, [28],[29]. The TEE provides security features such as
this approach is unable to cover new types of threats once isolated execution, integrity of applications executing in the
the system has been developed. On the other hand, passive TEE, and confidentiality of application assets. Several
defences alone are not suitable for safety-critical systems, hardware vendors provide embedded technologies that can
such as autonomous vehicles, as these approaches detect the be used to support TEE implementations, including AMD
attack once it has occurred. Also the active defence PSP [30], ARM TrustZone [31], EVITA Hardware Security
techniques approaches found in the literature apply Modules (HSM) [32] and Intel SGX Software Guard
continuous monitoring to detect anomalies, but did not Extensions [33]. We aim to explore if TEEs could be
consider their application to secure execution environments applied as secure execution environment for ECUs, thereby
for ECUs. As described in the next sections, our approach ensuring secure/isolated communication from ECU to ECU.
aims to address these limitations.

Copyright (c) IARIA, 2020. ISBN: 978-1-61208-795-5 16

VEHICULAR 2020 : The Ninth International Conference on Advances in Vehicular Systems, Technologies and Applications

B. Side Channel Attack Monitor API for accessing the peripherals and external devices, thus
While TEEs aim to provide secured execution making higher software layers independent of the hardware
environments, they are vulnerable to side-channel attacks layout. And third, the Services Layer (SL) provides top-
[34],[35]. This component focuses on runtime detection of level services (e.g., operating system functionality,
the variants of side-channel attacks (e.g., SGX interface- communication services, management services, memory
based attacks) that are relevant in a vehicular context. services, etc.) to application software components.
The Run-Time Environment (RTE) layer provides
communication services to the application software, acting
C. Monitoring and Certification Manager as a bridge between the application and the BSW layer.
The responsibility of this component is to perform real- The Application Layer mainly consists of software
time monitoring of security properties related to components components (SWC) interconnected to other SWCs and
(e.g., ECUs) in the in-vehicle network to detect security BSW modules. This layer is component-based, which
threats. This component applies the hybrid approach enhances SWC scalability and re-usability.
(including frequency-based, statistical-based, and deep Figure 3 shows the mapping of the major components of
packet inspection approaches) to detect spoofing and replay our framework to the AUTOSAR architecture. We propose
attacks. Based on the validity of the security properties, this to add an ECU that takes the role of monitoring existing
component also maintains the certificates (detailed in ECUs in the system, and to isolate ECUs.
Section IV.B) that certify the valid state of the ECUs. The left side (yellow box) of the Figure 3 shows the
deployment of virtual ECUs within the TEE, following the
IV. IMPLEMENTATION CONSIDERATIONS AUTOSAR architecture. The right side of the Figure 3
We adopt the AUTOSAR open standard for automotive shows the Domain Controller, Monitoring & Certification
software architecture and framework to implement the Manager and Side Channel Attack Monitor components of
architecture presented in Section III. The AUTOSAR the framework developed as SWCs in the AUTOSAR
consortium was formed by major automotive OEMs like application layer, i.e., these software components will reside
BMW, Ford, Daimler and Chrysler to standardize the within a trusted virtual ECU and will collect the data
automotive software architecture and framework, thereby transmitted among the virtual ECUs of the in-vehicle
facilitating scalability, reusability and interoperability across network. Such data will be used for monitoring the security
the products lines from different OEMs [36]. The use of properties related to different ECUs.
AUTOSAR in the implementation would therefore
inherently enable the prototype to have the same benefits.
Next, we briefly introduce AUTOSAR, and then discuss
the mapping between our framework and AUTOSAR. In
AUTOSAR, the ECU software is abstracted in a layered
architecture, built on top of the underlying micro-controller
hardware [37]. As shown in Figure 2, this architecture is
composed of three layers, namely Basic Software (BSW),
Runtime Environment (RTE), and Application Layer.

Figure 3. Mapping the framework to AUTOSAR

A. Monitoring
Figure 2. Overview of AUTOSAR components [37]
As shown in Figure 3, the Monitoring and Certification
Basic Software Layer (BSW) is the bottom layer of the Manager and the Side Channel Attack Monitor will collect
architecture and provides core system functionalities. This the data transmitted among the virtual ECUs of the in-
layer has 3 sub-layers. First, the Micro-controller vehicle network. A sub-component, namely DataCollector,
Abstraction Layer (MCAL) contains internal driver modules will be deployed for transforming the data from a legacy
that access the underlying micro-controller and internal format (e.g., CAN bus, being the most widely used protocol
peripherals directly. Second, the ECU Abstraction Layer in the automotive industry [38]) to a format that used for
(ECUAL) interfaces the drivers of the MCAL and offers an monitoring.

Copyright (c) IARIA, 2020. ISBN: 978-1-61208-795-5 17

VEHICULAR 2020 : The Ninth International Conference on Advances in Vehicular Systems, Technologies and Applications

This design may help to support multiple  AggregationRule: defines how monitoring results
communication standards in the framework (e.g., should be aggregated, e.g., for results with
Automotive Ethernet) by implementing a dedicated numerical values by applying statistical methods.
DataCollector (e.g., converting in-vehicle data from  AggregationResult: stores the aggregation result.
Automotive Ethernet to network monitoring format). Using
multiple monitoring ECUs (e.g., for each sets of Domain V. CONCLUSION AND OUTLOOK
Controllers) may help addressing safety constraints to avoid This position paper provided an overview of defence
single points of failure. strategies to mitigate common threats to in-vehicle
networks. We proposed an architecture and framework to
B. Certificate Model
enhance in-vehicle isolation and resilience focusing on
The Monitoring & Certification Manager and Side spoofing, replay and side-channel attacks. The framework
Channel Attack Monitor perform real-time monitoring of follows an active defence strategy to detect and react to
security properties related to ECUs to detect security threats intrusions on the in-vehicle network and to recover from
and produce a certificate for the in-vehicle network. attacks. This recovery may be rolling back to a stable state
Monitoring is driven by security properties expressed as to overcome an intrusion (e.g., in [27]), or to estimate the
condition-action rules verified by a rule engine (e.g., CLIPS stable state by applying different techniques (e.g., in [5]).
[39]) against runtime facts (i.e., runtime data). Monitoring This framework may also be used to detect anomaly or
results are accumulated to produce a certificate that certifies misbehavior, which are not necessarily resulting from
the state of the monitored components (e.g., ECUs). cyberattacks but simply from system faults and to limit their
The certificate structure includes the following elements: propagation in such a system of systems (e.g., in [40]).
1) CertificateID: represents the unique identifier of a Next steps are to implement the framework, and to evaluate
generated certificate during the monitoring process. its isolation and resilience benefits in a simple setting, first
2) MonitoringResultAggregator: aggregates monitoring using simulations, before a possible testbed implementation.
results produced by monitoring different components (e.g.,
ECUs, CAN bus etc.) of the in-vehicle network. This REFERENCES
element contains the following sub-elements: [1] M. Faezipour, M. Nourani, A. Saeed, and S Addepalli, “Progress and
• AggregationTime: denotes the time of aggregation. challenges in intelligent vehicle area networks,” Communications of
• Duration: specifies the timespan between the ACM, vol. 55, no. 2, pp. 90-100, Feb. 2012.
monitoring results considered for aggregation. [2] J. Boardman and B. Sauser, “System of Systems-the meaning of,”
2006 IEEE/SMC International Conference on System of Systems
• ToMLis: specifies a list of TargetOfMonitoring Engineering, pp. 6-pp, Apr. 2006, IEEE.
considered for the aggregation operation. [3] A.K. Rajan, A. Feucht, L. Gamer, and I. Smaili, “Hypervisor for
• AggregationRule: defines how monitoring results Consolidating Real-Time Automotive Control Units: Its Procedure,
should be aggregated, e.g., for results with Implications and Hidden Pitfalls,” Journal of Systems Architecture,
vol. 82, pp. 37-48, Jan. 2018.
numerical values by applying statistical methods.
[4] K. Daimi, M. Saed, S. Bone, and John Robb, “Securing Vehicle’s
• AggregationResult: stores the aggregation result. Electronic Control Units,” Twelfth International Conference on
Networking and Services, 2016.
3) TargetOfMonitoring (ToM): a component (e.g., ECU,
[5] V. Marquis et al., “Toward attack-resilient state estimation and
CAN bus, etc.) monitored to identify security threats control of autonomous cyber-physical systems,” Systems and
associated with it. Information Engineering Design Symposium (SIEDS), pp. 70-75,
The ToM has the following sub-elements 2018.
• ToMType: the type of component to be monitored. [6] D. A. Brown et al. “Automotive Security Best Practices:
Recommendations for security and privacy in the era of the next-
• ToMID: a unique identifier of the component in the generation car,” McAfee White Paper, Aug. 2016.
in-vehicle network. [7] A. Chattopadhyay and K. Lam, “Autonomous Vehicle: Security by
• MonitoringRule: the security property related to this Design,” Oct 2018, arXiv:1810.00545v1 [Retrieved: 13-05-2020].
component to be monitored. [8] M. Saed, K. Daimi, and S. Bayan, “A Survey of Autonomous Vehicle
• MonitoringEvidenceAggregator: contains the Technology and Security,” VEHICULAR 2019.
aggregation of results by monitoring the [9] M. S. Ul Alam, “Securing Vehicle Electronic Control Unit (ECU)
Communications and Stored Data,” Master of Science Thesis, School
MonitoringRule related to this component. of Computing, Queen's University Kingston, Ontario, Canada, Sep.
2018.
The MonitoringEvidence Aggregator contains the [10] V. L. Thing and J. Wu, “Autonomous Vehicle Security: A Taxonomy
following sub-elements: of Attacks and Defences,” 2016 IEEE International Conference on
Internet of Things (iThings) and IEEE Green Computing and
 AggregationTime; denotes the time of aggregation. Communications (GreenCom) and IEEE Cyber, Physical and Social
 Duration: specifies the time span between in- Computing (CPSCom) and IEEE Smart Data (SmartData), pp. 164-
vehicle network data considered for monitoring. 170, Dec. 2016.

Copyright (c) IARIA, 2020. ISBN: 978-1-61208-795-5 18

VEHICULAR 2020 : The Ninth International Conference on Advances in Vehicular Systems, Technologies and Applications

[11] B. Motruk, J. Diemer, R. Buchty, R. Ernst, and M. Berekovic, [25] J. Wang, Y. Cheng, Q. Li, and Y. Jiang, “Interface-Based Side
“IDAMC: A many-core platform with run-time monitoring for Channel Attack Against Intel SGX,” Oct. 2018,
mixed-criticality,” 2012 IEEE 14th International Symposium on https://arxiv.org/abs/1811.05378 [Retrieved: 13-05-2020]
High-Assurance Systems Engineering, pp. 24-31, Oct. 2012, IEEE. [26] N. Weichbrodt, P. Aublin, and R. Kapitza, “sgx-perf: A Performance
[12] G. Dupont, J. Hartog, S. Etalle, and A. Lekidis. (2019). “Network Analysis Tool for Intel SGX Enclaves,” 19th International
intrusion detection systems for in-vehicle network.” Technical report, Middleware Conference, pp. 201-213, doi:10.1145/3274808.3274824.
https://arxiv.org/abs/1905.11587 [Retrieved: 13-05-2020] [27] A. Binun, A. Bloch, S. Dolev, M. R. Kahil, B. Menuhin, R. Yagel, T.
[13] S. F. Lokman, A. T. Othman, and M. H. Abu-Bakar, “Intrusion Coupaye, M. Lacoste, A. Wailly. “Self-stabilizing virtual machine
detection system for automotive Controller Area Network (CAN) bus hypervisor architecture for resilient cloud,” 2014 IEEE World
system: a review,” EURASIP Journal on Wireless Communications Congress on Services pp. 200-207, June 2014. IEEE.
and Networking. 2019, doi: 10.1186/s13638-019-1484-3. [28] M. Sabt, M. Achemlal and A. Bouabdallah, “Trusted Execution
[14] P Kaur, M. Kumar, and A. Bhandari “A review of detection Environment: What It is, and What It is Not,” 2015 IEEE
approaches for distributed denial of service attacks” Systems Science Trustcom/BigDataSE/ISPA, Helsinki, pp. 57-64, 2015
& Control Engineering. pp. 301-320, Dec. 2016. doi:10.1109/Trustcom.2015.357.
[15] A. Tomlinson, J. Bryans, and S. Shaikh, “Towards Viable Intrusion [29] “Trusted Execution Environment (TEE) 101: A Primer”, Secure
Detection Methods For The Automotive Controller Area Network,” Technology Alliance, White Paper, Version 1.0, April 2018.
2nd ACM Computer Science in Cars Symposium, pp. 1-9, Sep. 2018. [30] AMD, AMD Secure Processor technology (AMD-SP),
[16] E. Seo, H. M. Song, and H. K. Kim, “GIDS: GAN based Intrusion https://www.amd.com/en/technologies/security [Retrieved: 13-05-
Detection System for In-Vehicle Network,” 2018 16th Annual 2020]
Conference on Privacy, Security and Trust (PST), pp. 1-6, 2018, doi: [31] “GlobalPlatform based Trusted Execution Environment and
10.1109/PST.2018.8514157. TrustZone-Ready: The foundations for trusted services”, ARM,
[17] M. J. Kang and J. W. Kang, “Intrusion detection system using deep White Paper, October 2013.
neural network for in-vehicle network security,” PLoS One, vol. 11, [32] M. Wolf and T. Gendrullis, “Design, implementation, and evaluation
no. 6, 2016. of a vehicular hardware security module,” International Conference
[18] A. Taylor, N. Japkowicz, and S. Leblanc, “Frequency-based anomaly on Information Security and Cryptology, pp. 302-318, Nov. 2011.
detection for the automotive CAN bus,” 2015 World Congress on [33] J.-E. Ekberg, K. Kostiainen, and N. Asokan, “Trusted Execution
Industrial Control Systems Security (WCICSS), pp. 45-49, 2015, Environments on Mobile Devices,” ACM CCS 2013 Tutorial,
doi:10.1109/WCICSS.2015.7420322. https://www.cs.helsinki.fi/group/secures/CCS-tutorial/tutorial-
[19] C. Young, H. Olufowobi, G. Bloom, and J. Zambreno, “Automotive slides.pdf [Retrieved : 13-05-2020].
Intrusion Detection Based on Constant CAN Message Frequencies [34] F. Brasser, U. Müller, A. Dmitrienko, K. Kostiainen, S. Capkun, and
Across Vehicle Driving Modes,” pp. 9-14, Mar. 2019, A. Sadeghi, “Software Grand Exposure: SGX Cache Attacks Are
doi:10.1145/3309171.3309179. Practical,” WOOT'17 Proceedings of the 11th USENIX Conference
[20] H. S. Sánchez, D. Rotondo, T. Escobet, V. Puig, J. Saludes, and on Offensive Technologies, 2017.
J. Quevedo, “Detection of replay attacks in cyber-physical systems [35] M. Schwarz, S. Weiser, D. Gruss, C. Maurice, and S. Mangard,
using a frequency-based signature,” Journal of the Franklin Institute, “Malware Guard Extension: Using SGX to Conceal Cache Attacks,”
vol. 356, no. 5, 2019. In: Polychronakis M., Meier M. (eds) Detection of Intrusions and
[21] A. A. Sivasamy, and B. Sundan, “A dynamic intrusion detection Malware, and Vulnerability Assessment. DIMVA 2017. Lecture
system based on multivariate Hotelling’s T2 statistics approach for Notes in Computer Science, vol 10327. Springer.
network environments,” The Scientific World Journal, 2015, [36] AUTOSAR History, https://www.autosar.org/about/history/,
doi:10.1155/2015/850153. [Retrieved : 10-02-2020].
[22] A. Qayyum, M. H. Islam, and M. Jamil, “Taxonomy of statistical [37] AUTOSAR, "AUTOSAR: Layered Software Architecture.",
based anomaly detection techniques for intrusion detection,” IEEE https://www.autosar.org/fileadmin/user_upload/standards/classic/4-
Symposium on Emerging Technologies, pp. 270-276, 3/AUTOSAR_EXP_LayeredSoftwareArchitecture.pdf [Retrieved:
doi:10.1109/ICET.2005.1558893. 13-05-2020]
[23] S. Jain, Q. Wang, M. T. Arafin, and J. Guajardo, “Probing Attacks on [38] C. Schlegel, “The role of CAN in the age of Ethernet and IoT,”
Physical Layer Key Agreement for Automotive Controller Area International CAN Conference (iCC), 2017.
Networks,” Asian Hardware Oriented Security and Trust Symposium,
pp. 7-12, 2018. [39] “CLIPS, A Tool for Building Expert Systems,”
http://www.clipsrules.net/index.html [Retrieved: 13-03-2020].
[24] Y. Kulah, B. Dincer, C. Yilmaz, and E. Savas, “SpyDetector: An
approach for detecting side-channel attacks at runtime,” International [40] A. Wasicek, M. D. Pesé, A. Weimerskirch, Y. Burakova, K. Singh
Journal of Information Security, vol. 18, pp. 393–422, “Context-aware Intrusion Detection in Automotive Control Systems,”
doi.org/10.1007/s10207-018-0411-7. 5th ESCAR Conference, 2017.

Copyright (c) IARIA, 2020. ISBN: 978-1-61208-795-5 19