Project topics and materials
Get Complete Project Material File(s) Now! »
Asset protection and data security
Asset protection is a set of preventive techniques generally based on cryptographic primitives whose goal is to protect confidentiality and integrity and authenticity of data assets, software assets, and data flows. Depending on the attacker model and threat, some of these protection mechanisms can be more relevant than others. Previous works have already identified the main security functions and components to be deployed depending on the security need. Wolf et al. [131] identify core security technologies and relevant security mechanisms for critical vehicular applications Kleberger et al. [74] focus in particular on in-vehicle network. Studnia et al. [123] presented the main threats, challenges and security tendencies in deploying security components in automotive systems. The EVITA project[2] have also identified main security needs and mechanisms based on which three Hardware Security Modules (HSM) components have been defined to be integrated in ECUs with different security needs. In this section we highlights the main tendencies.
First, in order to protect ECUs from executing attack payloads, the integrity of the executed firmware should be guaranteed. The validation of ECU code is generally done via firmware integrity checks, secure boot mechanisms [19, 96]. Protecting the confidentiality of the ECU’s firmware for intellectual property reasons is also necessary [30, 84]. Additionally, secure software update procedures of ECUs (over UDS or over-the-air), preventing chip tuning, preventing the unauthorized change of the mileage, or assembling non-original parts are necessary to ensure firmware integrity during the vehicle lifetime.
Second, protection of data storage and data flows is necessary in order to thwart privacy violations. Generally symmetric and asymmetric cryptographic techniques for data encryption (like AES1, ECC2) are used. Encryption keys have also to be secured, generally in secure storage techniques like tamper-proof memories. However, one constraint is the managemen of cryptographic keys. The systems have to implement protocols to distribute and generate keys. In particular, when deploying certificates, the deployment of public key infrastructure (PKI) that can distribute and manage keys is a must.
In-vehicle security mechanisms are presented more in details in section 2.5. In chapter 4, in order to protect the CAN-bus from an attacker with direct physical access, we investigate obfuscation strategies over the identifier field of the CAN frame.
Policy enforcement and run-time protections
In addition to the above-mentioned protection mechanisms, which define a security policy, there are also other mechanisms whose role is to reinforce this policy during run-time. 1Advanced Encryption Standard 2Elliptic Curve Cryptography At the software level, well-known solutions like intrusion detection systems based on functions-calls [130], system-calls [53], and Control-Flow-Graph and Control-Flow-Integrity [10] can be deployed. Schweppe al. [115] and Bouard et al. [23] proposed a security framework with taint tracking tools that allows to dynamically monitor data flows within and between ECUs to enforce security and privacy of data assets.
At the network architecture level, network firewalls that can monitor legitimate frames in sub-networks, and routing frames between them. Network intrusion detection systems also can monitor the behavior of specific nodes and frames. These techniques are presented more in details in section 2.5. In chapter5, in order to monitor the behavior of the CAN network frames exchanged between multiple network nodes, we propose a prediction-based intrusion detection system trained with machine learning techniques.
Threat Analysis and Risk Assessment
To be truly effective, the security mechanisms in cars must be specified with an overall vision of the system and at an early design phase. For this purpose, the defense-in-depth strategy is generally advocated. It consists of multiplying security mechanisms to protect the overall system. In practice, this means deploying security mechanisms (complementary and/or redundant) at several levels of the system, instead of merely protecting its entry points. This implies a step during the design phase, where security engineers come-up with different ways the system could be compromised in order to build strategies to protect against intrusions namely a Threat Assessment and Risk Analysis step (TARA).
In this context, one of the first initiatives to integrate the TARA step into the design phase of the vehicle was proposed by the SAE International1 that published in 2016 the “Cybersecurity Guidebook for Cyber-Physical Automotive Systems” SAEJ3061 [32]. Additionally, an on-going effort is put into a new standard ISO/SAE-21434 [7] that is expected to become the major standard for cybersecurity engineering in the automotive domain. A final version is presumed to be published by early 2020. Meanwhile, the SAEJ3061 guidebook provides high-level guidance, best practices, tools and methods to integrate cybersecurity into the existing development process of an organization. More precisely, it divides the vehicle life-cycle into concept-phase, product development, production, operation and service. In the concept-phase the goal is to define cybersecurity goals and strategy that ultimately should be translated into detailed technical requirements to be pushed into product development. The proposed steps to be followed during the concept phase (see figure 2.4) are centered around the main step that is the “Threat analysis and risk assessment”. The goal of a TARA step is to identify threats, estimate their potential and based on the risk they present formulate security requirements to be implemented.
Table of contents :
List of Figures
List of Tables
List of Abbreviations
1 Introduction
1.1 Context: security of connected vehicles
1.2 The automotive industry challenges
1.3 Motivation and goals
1.4 Contributions
1.4.1 Formal modeling approach for automatic attack tree generation
1.4.2 CAN identifier randomization strategy
1.4.3 Prediction-based intrusion detection system
1.5 Outline
2 State of the Art
2.1 Introduction
2.2 Cyber-physical architecture of connected cars
2.2.1 Sensors
2.2.2 Actuators
2.2.3 Electronic Control Units
2.2.4 Communication interfaces
2.2.4.1 In-vehicle shared communication buses
2.2.4.2 Diagnostics interface
2.2.4.3 Communication with the outside world
2.2.5 Overall architecture
2.2.6 Aftermarket and diagnostics Devices
2.3 Vulnerabilities and threats survey
2.3.1 Vulnerabilities and attack vectors
2.3.1.1 Direct physical access
2.3.1.2 Indirect physical access
2.3.1.3 Wireless access
2.3.2 Threats
2.3.2.1 Security violations
2.3.2.2 Attacker motivation
2.4 Countermeasures and Security methodologies
2.4.1 Countermeasures
2.4.1.1 Architecture
2.4.1.2 Asset protection and data security
2.4.1.3 Policy enforcement and run-time protections
2.4.2 Threat Analysis and Risk Assessment
2.5 In-Vehicule Secure Communication survey
2.5.1 Controller Area Network Overview
2.5.2 CAN Weaknesses
2.5.2.1 Denial-of-Service
2.5.2.2 Reverse engineering
2.5.2.3 Fuzzing attack
2.5.2.4 Impersonation attack
2.5.2.5 Exhaustion attack
2.5.3 Protection mechanisms
2.5.3.1 Payload protection
2.5.3.2 Identifier protection
2.5.3.3 Intrusion Detection and Prevention Systems
2.5.4 Advantages and disadvantages
2.6 Conclusion
3 Risk analysis and Attack tree generation
3.1 Introduction
3.2 Attack trees
3.2.1 Presentation and formal definition
3.2.2 Attack tree generation problem
3.2.2.1 Attack trees in the automotive domain
3.2.2.2 Attack tree generation in other application domains
3.3 A case study: speed acquisition and display system
3.3.1 Description
3.3.2 Goal of the attacker: forge displayed vehicle speed
3.4 Cyber-physical architecture formal model
3.4.1 Data
3.4.2 Communication mediums
3.4.3 Hardware components
3.4.4 Service components
3.4.5 Attacker
3.4.6 Architecture
3.4.7 Security properties
3.4.8 Case-study formal model
3.5 Graph transformation system
3.5.1 Definition
3.5.2 Labeled transition system
3.5.3 Tool support: GROOVE
3.5.4 Case-study graph transformation system
3.6 Attack tree transformation
3.6.1 Attack graph generation
3.6.2 Attack tree generation:
3.6.3 Case-study generation of attacks
3.7 Security analysis and Countermeasure
3.7.1 Security analysis
3.7.2 Countermeasures:
3.8 Conclusion
4 Identifier Randomization: an Efficient Protection against CAN-bus Attacks
4.1 Introduction
4.2 General formalism of ID-based protection
4.3 Evaluation metrics
4.3.1 Reverse-engineering attack
4.3.2 Replay and injection attacks
4.4 Proposed solutions
4.4.1 The IA-CAN Approach
4.4.2 Equal Intervals
4.4.3 Frequency Intervals
4.4.4 Dynamic Intervals
4.4.5 Arithmetic Masking
4.5 Comparison
4.6 Conclusion
5 On-board Intrusion Detection and Prevention system
5.1 Introduction
5.2 Machine learning algorithms
5.2.1 Learning strategy
5.2.2 Parametric and non-parametric models
5.3 Principle and problem formulation
5.3.1 Signal types
5.3.2 Intrusion detection principle
5.3.3 Mathematical formulation
5.3.4 Real-valued signal
5.3.5 Categorical signal
5.4 Validation metrics
5.4.1 Regression metrics for real-valued signals:
5.4.2 Classification metrics for categorical signals:
5.5 Supervised learning algorithms
5.5.1 K-Nearest Neighbor
5.5.1.1 KNN for regression
5.5.1.2 KNN for classification
5.5.2 Decision tree
5.5.2.1 Regression Trees
5.5.2.2 Classification Trees
5.5.3 Artificial Neural Network
5.5.3.1 MLP for Regression
5.5.3.2 MLP for Classification
5.6 Data collection and feature engineering
5.6.1 Experimental set-up
5.6.2 Data collection
5.6.3 Feature engineering
5.7 Experimental validation and discussion
5.7.1 Predicting a real-valued signal
5.7.1.1 Speed signal
5.7.1.2 Capturing nominal behavior of the speed signal
5.7.2 Predicting a categorical signal
5.7.2.1 Brake lights command signal
5.7.2.2 Capturing nominal behavior of the brake-lights-command signal
5.7.3 Unification of detection rule
5.8 Evaluation against attacks
5.8.1 Simulation of attacks
5.8.2 Attacks against real-valued signal
5.8.2.1 Random speed injection attack
5.8.2.2 Speed offset injection attack
5.8.2.3 Speed Denial of service (signal drop) attack
5.8.3 Attacks against categorical signal
5.8.3.1 Random command injection attack
5.8.3.2 Inverse command injection attack
5.8.3.3 Denial of service (force to 0) attack
5.9 Alerts handling
5.9.1 Prevention mechanism
5.9.2 False positives reduction strategy
5.10 Conclusion and discussion
6 Conclusion
6.1 Summary
6.2 Perspectives and future research directions
6.2.1 On risk assessment
6.2.2 On in-vehicle secure communications
Appendices
Transforamtion rules
Entropy computations
Bibliography
