Towards An Integrated In-Vehicle Isolation And Resilience .

2y ago
30 Views
2 Downloads
419.37 KB
5 Pages
Last View : 15d ago
Last Download : 2m ago
Upload by : Joanna Keil
Transcription

VEHICULAR 2020 : The Ninth International Conference on Advances in Vehicular Systems, Technologies and ApplicationsTowards an Integrated In-Vehicle Isolation and Resilience Framework forConnected Autonomous VehiclesKhaled Mahbub, Mohammad Patwary, AntonioNehmeMarc Lacoste, Sylvain Allio, Yvan RaffléAbstract—Connected Autonomous Vehicles (CAV) haveattracted significant attention, specifically due to successfuldeployment of ultra-reliable low-latency communications withFifth Generation (5G) wireless networks. Due to the safetycritical nature of CAV, reliability is one of the well-investigatedareas of research. Security of in-vehicle communications ismandatory to achieve this goal. Unfortunately, existingresearch so far focused on in-vehicle isolation or resilienceindependently. This short paper presents the elements of anintegrated in-vehicle isolation and resilience framework toattain a higher degree of reliability for CAV systems. Theproposed framework architecture leverages benefits of TrustedExecution Environments to mitigate several classes of threats.The framework implementation is also mapped to theAUTOSAR open automotive standard.Internal security barriers to detect and react to anintrusion are therefore needed to limit the impact of acompromise and to mitigate its propagation to differentsubsystems within a vehicle [1]. Moreover, the adoption ofnew technologies in the automotive domain is opening newsafety and security challenges. For example, the advent ofnew generations of ECUs that are virtualized as lightweightexecution environments (e.g., virtual machines, containers)on different types of virtualization platforms, (e.g., OKL4Microvisor, Proteus Hypervisor, ETAS STA-HVR [3]) mayface system-level isolation challenges such as side-channels.This short paper introduces our approach to detect andlimit the impact of intrusions for in-vehicle networks thatcan compromise the safety of autonomous vehicles. Thiswill be a step towards enhancing the robustness of invehicle communications through the isolation of ECUs, thedetection of and recovery from intrusions. Focusing onspoofing, replay, and side-channel attacks, we presentprinciples of a framework for in-vehicle isolation andresilience and discuss technical considerations for itsimplementation according to the AUTomotive Open SystemARchitecture (AUTOSAR) open standard.This paper is structured as follows: Section II presentsrelated work. Section III introduces our framework andSection IV discusses considerations to adhere to theAUTOSAR standard. We conclude our paper in Section V.Birmingham City UniversityBirmingham, United s - Isolation; Resilience; ECU; Monitoring; TrustedExecution Environment; AUTOSAR; Certification.I.INTRODUCTIONDespite considerable progress in the last decade, thedevelopment of fully self-driving vehicles is still largelyunder research and experimentation. In such safety-criticalsystems, the resilience of in-vehicle and inter-vehiclecommunication is a key element to ensure the security of thevehicle. While in-vehicle relates to on-board communicationbetween Electronic Control Units (ECUs) acting based ications enable data exchange with the externalenvironment including other vehicles, broadband clouds androadside-infrastructures [1].In this system of systems model, the diversity, autonomyand connectivity of vehicles mean vulnerabilities at the levelof the vehicle affect the larger environment [2]. While bothtypes of communication enable safety-critical decisionmaking, in-vehicle communication requires specialattention. The disparity of coding practices among thediversity of specialised vendors in different functionalities(e.g., infotainment, braking and steering assistance), and thetrust model induced by the high degree of connectivity andunrestricted interactions between vehicle components toenable comfort features (e.g., adjusting the sound volumeaccording to the velocity) widen the attack surface [1].Copyright (c) IARIA, 2020.ISBN: 978-1-61208-795-5Orange RELATED WORKA significant body of work focuses on improvingresilience of connected autonomous vehicles. Solutionsagainst threats can be categorised as i) Proactive Defence,ii) Active Defence and iii) Passive Defence [4]-[8]. We givenext a brief overview of each family of techniques.A. Proactive DefenceProactive defence is underpinned by the “security bydesign” principle practiced in the software industry [6],[7].Integration of common security practices, public keyencryption and hash-based message authentication fallunder this category [4],[9].15

VEHICULAR 2020 : The Ninth International Conference on Advances in Vehicular Systems, Technologies and ApplicationsB. Active DefenceActive defence mitigates threats as they occur. Forinstance, continuous monitoring can be applied to detectintrusions and preserve the security hygiene of the vehicleand take adequate remediation actions [10]; in this sense,real-time monitoring enables the identification and isolationof faulty applications in safety-critical systems [11].Detection approaches for the in-vehicle network can becategorised as i) Signature-Based Detection, ii) AnomalyBased Detection and iii) Hybrid Approach [12]-[15]: Signature-Based Detection: These approaches useinformation about attacks (signatures) as a patterncharacterizing known threats, comparing signaturesagainst observed events to identify possible attacks. Anomaly-Based Detection: These approaches are basedon continuous monitoring of system activities, checkingagainst a reference model (e.g., profile of the system).An alarm is raised if deviation from the referencemodel is observed. Various mechanisms can be appliedto derive the reference model, such as machine learning[16],[17], frequency-based [18]-[20], and statisticalbased methods [21],[22]. Hybrid Approach: This family of approach comprisesseveral intrusion detection techniques (e.g., signatureand anomaly-based detection).In addition to in-vehicle intrusion detection, severalapproaches explore detection of side channel attacks for theautomotive domain - at the physical layer [23], using cachebased [24] or interface-based approaches [25],[26].C. Passive DefencePassive defence mainly focuses on detecting, respondingto, and recovering from an attack once it has occurred. Thistype of defence is notably suitable to prevent malwares andcode injection and modification threats. Therefore, passivedefences are not suitable for safety-critical systems, likeautonomous vehicles, as these approaches do not facilitatedetection and mitigation of adversaries in real-time [8],[10].It should be noted that proactive defence and passivedefence are not suitable to handle adaptive securityrequirements, very common in the cyber and the automotivedomains. Proactive defence recommends designing controlfeatures to meet the security objectives at system designtime and embedding such features in the system. However,this approach is unable to cover new types of threats oncethe system has been developed. On the other hand, passivedefences alone are not suitable for safety-critical systems,such as autonomous vehicles, as these approaches detect theattack once it has occurred. Also the active defencetechniques approaches found in the literature applycontinuous monitoring to detect anomalies, but did notconsider their application to secure execution environmentsfor ECUs. As described in the next sections, our approachaims to address these limitations.Copyright (c) IARIA, 2020.ISBN: 978-1-61208-795-5III.IN-VEHICLE ISOLATION AND RESILIENCEWe adopt the active defence approach to improve invehicle resilience: security properties related to thecommunication among ECUs will be continuouslymonitored in order to detect security threats, and actionswill be taken to mitigate the impact of and gracefullyrecover from the detected threat. Recovery in our contextconsists of rolling back (or forward) to a stable state toovercome intrusions [27].Figure 1. Reference Architecture of Isolation and Resilience FrameworkFigure 1 shows the proposed reference architecture forthreat detection and mitigation in the in-vehicle network.ECUs are grouped into different domains according tosimilarity of functionalities. All ECUs in a domain areconnected to the same communication bus and activities ofeach ECU in a domain are controlled by one domaincontroller. Domain controllers are connected through acommon gateway in order to enable communication amongthe ECUs belong to different domains [4],[9]. The majorcomponents of the architecture are:A. Trusted Execution Environment (TEE)Trusted Execution Environments enable to specifyisolated execution environment in the main processor[28],[29]. The TEE provides security features such asisolated execution, integrity of applications executing in theTEE, and confidentiality of application assets. Severalhardware vendors provide embedded technologies that canbe used to support TEE implementations, including AMDPSP [30], ARM TrustZone [31], EVITA Hardware SecurityModules (HSM) [32] and Intel SGX Software GuardExtensions [33]. We aim to explore if TEEs could beapplied as secure execution environment for ECUs, therebyensuring secure/isolated communication from ECU to ECU.16

VEHICULAR 2020 : The Ninth International Conference on Advances in Vehicular Systems, Technologies and ApplicationsB. Side Channel Attack MonitorWhile TEEs aim to provide secured executionenvironments, they are vulnerable to side-channel attacks[34],[35]. This component focuses on runtime detection ofthe variants of side-channel attacks (e.g., SGX interfacebased attacks) that are relevant in a vehicular context.C. Monitoring and Certification ManagerThe responsibility of this component is to perform realtime monitoring of security properties related to components(e.g., ECUs) in the in-vehicle network to detect securitythreats. This component applies the hybrid approach(including frequency-based, statistical-based, and deeppacket inspection approaches) to detect spoofing and replayattacks. Based on the validity of the security properties, thiscomponent also maintains the certificates (detailed inSection IV.B) that certify the valid state of the ECUs.IV.IMPLEMENTATION CONSIDERATIONSWe adopt the AUTOSAR open standard for automotivesoftware architecture and framework to implement thearchitecture presented in Section III. The AUTOSARconsortium was formed by major automotive OEMs likeBMW, Ford, Daimler and Chrysler to standardize theautomotive software architecture and framework, therebyfacilitating scalability, reusability and interoperability acrossthe products lines from different OEMs [36]. The use ofAUTOSAR in the implementation would thereforeinherently enable the prototype to have the same benefits.Next, we briefly introduce AUTOSAR, and then discussthe mapping between our framework and AUTOSAR. InAUTOSAR, the ECU software is abstracted in a layeredarchitecture, built on top of the underlying micro-controllerhardware [37]. As shown in Figure 2, this architecture iscomposed of three layers, namely Basic Software (BSW),Runtime Environment (RTE), and Application Layer.API for accessing the peripherals and external devices, thusmaking higher software layers independent of the hardwarelayout. And third, the Services Layer (SL) provides toplevel services (e.g., operating system functionality,communication services, management services, memoryservices, etc.) to application software components.The Run-Time Environment (RTE) layer providescommunication services to the application software, actingas a bridge between the application and the BSW layer.The Application Layer mainly consists of softwarecomponents (SWC) interconnected to other SWCs andBSW modules. This layer is component-based, whichenhances SWC scalability and re-usability.Figure 3 shows the mapping of the major components ofour framework to the AUTOSAR architecture. We proposeto add an ECU that takes the role of monitoring existingECUs in the system, and to isolate ECUs.The left side (yellow box) of the Figure 3 shows thedeployment of virtual ECUs within the TEE, following theAUTOSAR architecture. The right side of the Figure 3shows the Domain Controller, Monitoring & CertificationManager and Side Channel Attack Monitor components ofthe framework developed as SWCs in the AUTOSARapplication layer, i.e., these software components will residewithin a trusted virtual ECU and will collect the datatransmitted among the virtual ECUs of the in-vehiclenetwork. Such data will be used for monitoring the securityproperties related to different ECUs.Figure 3. Mapping the framework to AUTOSARFigure 2. Overview of AUTOSAR components [37]Basic Software Layer (BSW) is the bottom layer of thearchitecture and provides core system functionalities. Thislayer has 3 sub-layers. First, the Micro-controllerAbstraction Layer (MCAL) contains internal driver modulesthat access the underlying micro-controller and internalperipherals directly. Second, the ECU Abstraction Layer(ECUAL) interfaces the drivers of the MCAL and offers anCopyright (c) IARIA, 2020.ISBN: 978-1-61208-795-5A. MonitoringAs shown in Figure 3, the Monitoring and CertificationManager and the Side Channel Attack Monitor will collectthe data transmitted among the virtual ECUs of the invehicle network. A sub-component, namely DataCollector,will be deployed for transforming the data from a legacyformat (e.g., CAN bus, being the most widely used protocolin the automotive industry [38]) to a format that used formonitoring.17

VEHICULAR 2020 : The Ninth International Conference on Advances in Vehicular Systems, Technologies and ApplicationsThis design may help to support multiplecommunication standards in the framework (e.g.,Automotive Ethernet) by implementing a dedicatedDataCollector (e.g., converting in-vehicle data fromAutomotive Ethernet to network monitoring format). Usingmultiple monitoring ECUs (e.g., for each sets of DomainControllers) may help addressing safety constraints to avoidsingle points of failure.B. Certificate ModelThe Monitoring & Certification Manager and SideChannel Attack Monitor perform real-time monitoring ofsecurity properties related to ECUs to detect security threatsand produce a certificate for the in-vehicle network.Monitoring is driven by security properties expressed ascondition-action rules verified by a rule engine (e.g., CLIPS[39]) against runtime facts (i.e., runtime data). Monitoringresults are accumulated to produce a certificate that certifiesthe state of the monitored components (e.g., ECUs).The certificate structure includes the following elements:1) CertificateID: represents the unique identifier of agenerated certificate during the monitoring process.2) MonitoringResultAggregator: aggregates monitoringresults produced by monitoring different components (e.g.,ECUs, CAN bus etc.) of the in-vehicle network. Thiselement contains the following sub-elements: AggregationTime: denotes the time of aggregation. Duration: specifies the timespan betweenmonitoring results considered for aggregation. ToMLis: specifies a list of TargetOfMonitoringconsidered for the aggregation operation. AggregationRule: defines how monitoring resultsshould be aggregated, e.g., for results withnumerical values by applying statistical methods. AggregationResult: stores the aggregation result.3) TargetOfMonitoring (ToM): a component (e.g., ECU,CAN bus, etc.) monitored to identify security threatsassociated with it.The ToM has the following sub-elements ToMType: the type of component to be monitored. ToMID: a unique identifier of the component in thein-vehicle network. MonitoringRule: the security property related to thiscomponent to be monitored. n of results by monitoring theMonitoringRule related to this component.The MonitoringEvidence Aggregator contains thefollowing sub-elements: AggregationTime; denotes the time of aggregation. Duration: specifies the time span between invehicle network data considered for monitoring.Copyright (c) IARIA, 2020.ISBN: 978-1-61208-795-5 AggregationRule: defines how monitoring resultsshould be aggregated, e.g., for results withnumerical values by applying statistical methods.AggregationResult: stores the aggregation result.V.CONCLUSION AND OUTLOOKThis position paper provided an overview of defencestrategies to mitigate common threats to in-vehiclenetworks. We proposed an architecture and framework toenhance in-vehicle isolation and resilience focusing onspoofing, replay and side-channel attacks. The frameworkfollows an active defence strategy to detect and react tointrusions on the in-vehicle network and to recover fromattacks. This recovery may be rolling back to a stable stateto overcome an intrusion (e.g., in [27]), or to estimate thestable state by applying different techniques (e.g., in [5]).This framework may also be used to detect anomaly ormisbehavior, which are not necessarily resulting fromcyberattacks but simply from system faults and to limit theirpropagation in such a system of systems (e.g., in [40]).Next steps are to implement the framework, and to evaluateits isolation and resilience benefits in a simple setting, firstusing simulations, before a possible testbed implementation.REFERENCES[1]M. Faezipour, M. Nourani, A. Saeed, and S Addepalli, “Progress andchallenges in intelligent vehicle area networks,” Communications ofthe ACM, vol. 55, no. 2, pp. 90-100, Feb. 2012.[2] J. Boardman and B. Sauser, “System of Systems-the meaning of,”2006 IEEE/SMC International Conference on System of SystemsEngineering, pp. 6-pp, Apr. 2006, IEEE.[3] A.K. Rajan, A. Feucht, L. Gamer, and I. Smaili, “Hypervisor forConsolidating Real-Time Automotive Control Units: Its Procedure,Implications and Hidden Pitfalls,” Journal of Systems Architecture,vol. 82, pp. 37-48, Jan. 2018.[4] K. Daimi, M. Saed, S. Bone, and John Robb, “Securing Vehicle’sElectronic Control Units,” Twelfth International Conference onNetworking and Services, 2016.[5] V. Marquis et al., “Toward attack-resilient state estimation andcontrol of autonomous cyber-physical systems,” Systems andInformation Engineering Design Symposium (SIEDS), pp. 70-75,2018.[6] D. A. Brown et al. “Automotive Security Best Practices:Recommendations for security and privacy in the era of the nextgeneration car,” McAfee White Paper, Aug. 2016.[7] A. Chattopadhyay and K. Lam, “Autonomous Vehicle: Security byDesign,” Oct 2018, arXiv:1810.00545v1 [Retrieved: 13-05-2020].[8] M. Saed, K. Daimi, and S. Bayan, “A Survey of Autonomous VehicleTechnology and Security,” VEHICULAR 2019.[9] M. S. Ul Alam, “Securing Vehicle Electronic Control Unit (ECU)Communications and Stored Data,” Master of Science Thesis, Schoolof Computing, Queen's University Kingston, Ontario, Canada, Sep.2018.[10] V. L. Thing and J. Wu, “Autonomous Vehicle Security: A Taxonomyof Attacks and Defences,” 2016 IEEE International Conference onInternet of Things (iThings) and IEEE Green Computing andCommunications (GreenCom) and IEEE Cyber, Physical and SocialComputing (CPSCom) and IEEE Smart Data (SmartData), pp. 164170, Dec. 2016.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,“IDAMC: A many-core platform with run-time monitoring formixed-criticality,” 2012 IEEE 14th International Symposium onHigh-Assurance Systems Engineering, pp. 24-31, Oct. 2012, IEEE.[12] G. Dupont, J. Hartog, S. Etalle, and A. Lekidis. (2019). “Networkintrusion detection systems for in-vehicle network.” Technical report,https://arxiv.org/abs/1905.11587 [Retrieved: 13-05-2020][13] S. F. Lokman, A. T. Othman, and M. H. Abu-Bakar, “Intrusiondetection system for automotive Controller Area Network (CAN) bussystem: a review,” EURASIP

components (SWC) interconnected to other SWCs and BSW modules. This layer component-based, which is enhances SWC scalability and re-usability. Figure 3 shows the mapping of the major components of our framework to the AUTOSAR architecture.We propose to add ECU that takes the role of monito

Related Documents:

Cisco 819G-S-K9 Integrated Solutions Router 15.2(4)M6A Cisco 819HG-4G-G-K9 Integrated Solutions Router 15.2(4)M6A Cisco 891 Integrated Solutions Router 15.2(4)M6A Cisco 881 Integrated Solutions Router 15.2(4)M6A Cisco 1905 Integrated Solutions Router 15.2(4)M6A Cisco 1921 Integrated Solutions Router 15.2(4)M6A Cisco 1941 Integrated Solutions .

The weight of a motor vehicle as shown on the vehicle's registration document or, in the case of truck or trailer, the weight of the vehicle plus the maximum load the vehicle is registered to carry as shown on the vehicle's registration document. The MGW, not the designed carrying capacity of the vehicle, will be the weight that

Five vehicle classes were chosen to represent a variety of vehicle weights and engine sizes in the U.S passenger and light-duty truck vehicle fleet. A specific comparator vehicle for each class was chosen to verify that each vehicle model was representative of the class. Vehicle Class / Compa

you can have New Vehicle Protection until 2022. After this time, you cannot buy New Vehicle Protection again for the same vehicle. Is there a time limit to buy New Vehicle Protection? Yes. For brand new vehicles, you have 60 days to buy New Vehicle Protection from when you first register and insure the vehicle. For used vehicles, you have 60 days

3. Determining the major factors that affect the students' attitude towards entrepreneurship at PSUT through three major factors: students' awareness towards entrepreneurship, students' perception towards the effect of entrepreneurship on the individual, and students' perception towards the effect of entrepreneurship on the society.

A POLARIS RANGER is not a toy and can be hazardous to operate. This vehicle handles differently than other vehicles, such as motor cycles and cars. A collision or roll over can occur quickly, even during . before operating the vehicle. Keep this manual with the vehicle. This vehicle is an ADULT VEHICLE ONLY. NEVER operate this vehicle if .

b) Select the year of the vehicle from the list. c) Select the make of the vehicle from the list. d) Select the model of the vehicle from the list. e) Select the submodel of the vehicle from the list. f) Select the engine of the vehicle from the list. After completing the vehicle selection

Manager, Delivery and Collection Fleet Manager Superintendent, Vehicle Operations Manager, Stations and Branches Superintendent, Vehicle Maintenance Supervisor, Vehicle Maintenance Chief of Supplies Vehicle Operations Analyst Supervisor, Vehicle Dispatching Vehicle Operations Maintenance Assistant (VOMA)