# Fivadmi: A Framework for In-Vehicle Anomaly Detection by Monitoring and Isolation +
## 3 FIVADMI: A Framework for Improving In-Vehicle Isolation and Resilience
### 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 executing 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 TrustedComputing Group (TCG) [56] specifications, is a dedicated processor to secure hardware. In this work, we explore how to apply TEE as execution environments for ECUs to ensure isolated and secure communications between ECUs. **Side Channel Attack Monitor (SCAM)**: TEEs remain vulnerable to side channel attacks [42; 58]. This component focuses on the runtime detection of side channel attacks (e.g., SGX interface based attacks) that are relevant in a vehicular context. Through the monitoring of Hardware Performance Counters, this component flags suspicions rowhammer and cache and covert side channel attacks. **Monitoring and Certification Manager (MCM)**: This component performs real-time monitoring of security properties related to IVN components (e.g., ECUs) to detect security threats. It applies hybrid techniques (including frequency-based and statistical-based 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 state of ECUs. To implement the architecture, FIVADMI adopts the AUTomotive Open System AR-chitecture (AUTOSAR) open standard. The AUTOSAR consortium was formed by major automotive OEMs like BMW, Ford, and Daimler Chrysler to standardize the automotive software architecture and framework, thereby facilitating scalability, reusability and interoperability 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_. Figure 4: Reference Architecture of FIVADMI. **Basic Software Layer (BSW)**: this layer provides core system functionalities. As shown in Figure 6, this layer has 3 sub-layers, (i) _Micro-controller Abstraction Layer (MCAL)_--contains internal drivers modules that access the micro-controller and internal peripherals directly, (ii) _ECU Abstraction Layer (ECUAL)_--interfaces the drivers of the MCAL and offers an API for accessing peripherals and external devices, thus making higher software layers independent of the hardware layout, and (iii) _Services Layer (SL)_--provides top level services (e.g., operating system, communication, management, and memory services) to application software components. **Run-Time Environment (RTE)**: this layer provides communication services to application software, acting as a bridge between applications and the BSW layer. **Application Layer**: this layer mainly consists of Software Components (SWC) interconnected 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.