Project topics and materials
Get Complete Project Material File(s) Now! »
Attacks: Network Communication
Within an unauthenticated broadcast network, every node may read traffic and send traffic under any identity. This is true for classic IP-based networks by forging the source address, and also for vehicle networks by forging the CAN identifier. This class of attacks is called spoofing. Within our scenario, all communication links are affected if the payload is not secured.
Another basic kind of attacks is to inhibit or drop communication. Dropping network frames can only be done at relaying nodes, i.e., gateways. This requires the gateway itself to be compromised. In contrast, inhibiting genuine communication can be performed on any network node connected to a broadcast medium, simply by provoking collisions during ongoing communication. A modified transceiver chip would be necessary to perform such a kind of attack, as media access is usually handled in hardware. An often overlooked technique on authenticated or encrypted communication are replay attacks. If the attacker is able to intercept and inject messages, a genuine message can be replayed at a later time. Sequence numbers or timestamps provide are countermeasures against this attack, yet require a secure and authentic time to be distributed beforehand.
Man-in-the-middle attacks are a technically more sophisticated form of intrusion.
The original signal is received and dropped, and a modified signal is injected. Under certain circumstances like a compromised certification infrastructure, this attack even works for authenticated and encrypted communication. For IP-based networks there exist tools to redirect traffic by ARP-spoofing Security and Privacy in Automotive On-Board Networks and to hijack the communication. Within the vehicle, devices for a physical man-in-the-middle setup are being sold (variants for CAN and MOST buses exist). They transmit wrong velocity signals to the head unit in order to enable TV output during driving operation, despite the exclusive policy implemented by the manufacturer.
Attacks: Host Based Intrusions
In order to obtain data, or to access resources such as the I/O channels of a device, several intrusion types can lead to success. The modification of the ECU firmware or of the bootloader in memory can make it possible to inject malicious programs. This kind of attack requires physical access to the target system.
The class of runtime attacks is much larger: Specially crafted input is used to divert the control flow of applications. Once injected or reconstructed code is executed, the attacker has gained the same access level as that of the program that is exploited, i.e., a vulnerability is actively used to gain access. If system resources are not specifically protected, as it would be the case for today’s multiuser systems, an attacker can take any kind of action. This involves intrusive attacks such as distracting the driver by influencing the vehicle behavior and showing warning messages, but also stealthier behaviors, such as recording audio from connected microphones or tracking the vehicle’s location.
The class of runtime attacks is of special importance as they can potentially be performed remotely. Techniques and countermeasures used for attacks related to overwriting data on the stack, such as the return address or function pointers, are explained in Section 5.4.1 (p. 93).
Towards A Secure In-Car Architecture
This Section describes the in-vehicle hardware and software architecture of the EVITA FP7 European Project. This thesis was written in parallel to work in the EVITA project, so a number of contributions that go beyond what is described in the thesis, were made to the architecture, protocol design and implementation. This architecture provides a foundation for experiments and higher level solutions developed within this thesis. As part of the EVITA project, an analysis of attack scenarios and security requirements [RWW+09] with regard to typical automotive use cases [KFL+09] has been done. The security architecture is a combination of software and hardware elements [WWZ+10]. While the software manages security functionality and provides automotive applications with security services, such as authenticated or confidential communication, the hardware part provides the trust anchor: a trusted platform for storing key material and Ph.D. Thesis — Hendrik C. Schweppe using cryptographic primitives. This hardware/software co-design assures that cryptographic keys are i) not used unauthorized, i.e., the platform needs to be securely booted for the key to be used, and it can only be employed according to its use-flags, and ii) will never leave the hardware in an unencrypted form, i.e., all cryptographic operations take place in the hardware module. Note: Despite secure boot and key usage control, software that accesses an HSM can still be exploited at runtime.
Table of contents :
Abstract
1 Introduction
1.1 Vehicle Electronics
1.2 Motivation
1.3 Problem Description
1.4 Goals
1.5 Structure of the Thesis
2 State of the Art
2.1 Automotive Security
2.1.1 Vehicle Components and Vulnerabilities
2.1.2 Vehicle Security Concepts
2.1.3 Ongoing Research
2.1.4 Current Practice
2.2 Software Security
2.2.1 Overview and Classification of approaches
2.2.2 Techniques and Methods for Information Flow Tracking .
2.3 Dynamic Application Environments and Platform Security
2.3.1 Application Environments
2.3.2 Example for Closed Application Environments: An App Store
2.3.3 Attacks on iOS Security
2.3.4 Complexity and Cost of Approaches
2.4 Conclusion
3 Environment
3.1 Scenarios
3.1.1 Scenario I: Active Brake (Car2X)
3.1.2 Scenario II: Playing Music
3.1.3 Scenario III: Driver Adaptation
3.2 Attacker Model
3.3 Possible Attack Vectors
3.3.1 Attacks: Network Communication
3.3.2 Attacks: Host Based Intrusions
3.4 Towards A Secure In-Car Architecture
3.4.1 Software Security: The Framework
3.4.2 Communication
3.4.3 Policy Decision
3.5 Hardware: The Hardware Security Modules
3.5.1 Key Usage
3.5.2 The HSM programming interface
3.5.3 Prototype Platform
3.5.4 Performance
3.5.5 Comparison with other Secure Hardware
4 Communication Security
4.1 Key Distribution in Embedded Environments
4.1.1 Asymmetric Usage of Symmetric Keys
4.1.2 Dynamic Key Exchanges
4.1.3 Multi-Criteria Setting of Secure Communication
4.1.4 The Protocol
4.1.5 Multi-Domain deployment
4.1.6 Initial Key Distribution
4.1.7 Maintenance and Part Replacement
4.2 Securing CAN Bus Communication
4.2.1 Technical Background
Ph.D. Thesis — Hendrik C. Schweppe
4.2.2 CAN Transport Protocol
4.2.3 Truncation of Cryptographic Authentication Codes
4.2.4 Implications for CAN bus communication
4.3 Related Work
5 Dynamic Platform Security
5.1 Intrusion Detection and Response
5.1.1 Architecture: Vehicular Network and Host Based Intrusion Detection System
5.2 Distributed and Dynamic Information Flow
5.2.1 Data Flow Tracking
5.2.2 Binary Instrumentation for Taint Tracking
5.2.3 Data Flows: Access Control
5.2.4 Taint Based Security Policy
5.2.5 Example of Tag Propagation
5.2.6 Network Marshalling
5.2.7 Multi-Level Enforcement
5.3 Timing Based Hardware Security
5.3.1 Timed Key Usage at Hardware Module
5.3.2 Requirements for the HSM and Discussion
5.4 Related Work
5.4.1 Exploit Prevention Techniques
5.4.2 Information Flow Control
5.4.3 Current On-Board Security
6 Prototypes and Evaluations
6.1 Analysis of a CAN bus
6.2 Protocol Measurements
6.2.1 Simulating Key Exchanges with TTool
6.2.2 Simulating the Secure Transport Protocol
6.2.3 Implementation as Part of the Framework
6.3 Distributed Dynamic Information Flow Tracking
6.3.1 Performance
6.4 In-Vehicle Prototype
6.4.1 The CAN-Ethernet Gateway Security and Privacy in Automotive On-Board Networks
7 Conclusion and Outlook
7.1 Achievements and Conclusion
7.2 Outlook on Future Research and Development
A R´esum´e ´Etendu — Fran¸cais
B Additional Measurements and Implementation Details
B.1 HSM Performance Measurements
B.1.1 Performance Figures
B.1.2 Overhead of Prototype Implementation
B.2 Key Distribution Implementation
B.2.1 Application Code
B.2.2 Client Framework Code
B.2.3 Server Framework Code
B.2.4 Detailed MSC for Key Distribution
B.3 Secure Storage
B.3.1 Key Access Control
B.3.2 Native Encryption
B.3.3 Secondary Encryption
B.4 Intrusion Detection Sensors
B.5 CAN Ethernet Gateway
B.6 Active Brake Prototype Demonstrator
C Glossary
C.1 Acronyms and Abbreviations
List of Figures
List of Listings
List of Tables
List of Publications
Bibliography
