Analysis of Attack Methods on Car-to-X Communication Using ...

<strong>Analysis</strong> <strong>of</strong> <strong>Attack</strong> <strong>Methods</strong>on Car-to-X CommunicationUsing Practical TestsAnalyse von Angriffsmethoden auf die Car-to-X Kommunikation durch Anwendungpraktischer TestsMaster-Thesis von Henrik SchröderBetreuer: Norbert Bißmeyer M.Sc.April 2013

<strong>Analysis</strong> <strong>of</strong> <strong>Attack</strong> <strong>Methods</strong> on Car-to-X Communication Using Practical TestsAnalyse von Angriffsmethoden auf die Car-to-X Kommunikation durch Anwendung praktischerTestsVorgelegte Master-Thesis von Henrik SchröderBetreuer: Norbert Bißmeyer M.Sc.1. Gutachten: Norbert Bißmeyer MSc.2. Gutachten: Pr<strong>of</strong>. Dr. Michael WaidnerTag der Einreichung:

AbstractWith the introduction <strong>of</strong> Car-to-Car or Car-to-X Communication vehicles become able to exchange locationand mobility data via ad hoc communication. This way, drivers can be warned about potentialdangers on the road and both traffic safety and traffic efficiency can be increased. Since attacks on thissystem could endanger the safety <strong>of</strong> drivers, the security <strong>of</strong> the system plays an important role. In thismaster thesis different attack methods on Car-to-X Communication are analyzed in terms <strong>of</strong> attractivenessfor an attacker and potential impact on the system. Subsequently, the most probable attack methodis considered further. An attacker is assumed that is able to introduce a malware into the on-board system<strong>of</strong> a vehicle. This malware sends out messages with false location and mobility data and thus simulatesa ghost vehicle that performs emergency braking maneuvers. That way warning messages are triggeredin neighboring vehicles which could misguide drivers or even lead to dangerous driving maneuvers. Theattacks are evaluated in both a laboratory environment and with test vehicles on a dedicated test site.Based on the results <strong>of</strong> this work defense mechanisms against such attacks can be refined in future work.1

Erklärung zur Master-ThesisHiermit versichere ich, die vorliegende Master-Thesis ohne Hilfe Dritter nur mit den angegebenenQuellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus Quellenentnommen wurden, sind als solche kenntlich gemacht. Diese Arbeit hat in gleicher oderähnlicher Form noch keiner Prüfungsbehörde vorgelegen.Darmstadt, den 22. April 2013(H. Schröder)3

Contents1 Introduction 71.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.2 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.1 Mobile Ad Hoc Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2.2 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2.3 Vehicular Ad Hoc Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 <strong>Attack</strong>s on Vehicular Ad Hoc Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.3.1 Classification <strong>of</strong> <strong>Attack</strong>ers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211.3.2 Classification <strong>of</strong> <strong>Attack</strong>s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221.4 Risk Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.4.1 PreServe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231.4.2 EVITA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.4.3 ETSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.4.4 simTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241.5 Related Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.5.1 A model <strong>of</strong> a roadside attacker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.5.2 Simulations <strong>of</strong> position forging attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 281.5.3 Defense mechanisms against position forging attacks . . . . . . . . . . . . . . . . . . . 302 <strong>Analysis</strong> <strong>of</strong> <strong>Attack</strong> <strong>Methods</strong> 332.1 <strong>Attack</strong> <strong>Methods</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.2 Assessment Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332.3 Assessment <strong>of</strong> <strong>Attack</strong> <strong>Methods</strong> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 System Model 373.1 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.1.1 EBL application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.1.2 Choosing <strong>of</strong> a victim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.1.3 <strong>Attack</strong> sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 413.1.4 <strong>Attack</strong>er parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454 Evaluation 475 Discussion 516 Conclusion 535

1 IntroductionWith the increasing amount <strong>of</strong> road traffic the security <strong>of</strong> road users has to be ensured. According to theWorld Health Organization, 1.24 million road deaths occurred in 2012 worldwide [27]. Furthermore,efficient traffic flow has to be maintained. One approach that could help to achieve these goals is theintroduction <strong>of</strong> Car-to-Car (C2C) communication. With this technology, all the vehicles taking partin traffic are equipped with radio communication devices that enable the exchange <strong>of</strong> location andmobility data among vehicles. Thus, vehicles become aware <strong>of</strong> neighboring cars and their movement. Bycomparing the received data with its own position, speed and heading a vehicle can check for dangeroustraffic situations that could lead to accidents. As soon as such a dangerous situation is detected the drivercan be informed using visual and acoustic warnings. This way, drivers can be made aware <strong>of</strong> situationsthat require appropriate driving maneuvers and that might lead to accidents when no action is taken.In addition to inter-vehicle communication the more general term Car-to-X (C2X) communication alsoincludes the exchange <strong>of</strong> information between vehicles and road infrastructures. By communicating withtraffic lights vehicles may for example inform drivers about the remaining time <strong>of</strong> a green light phase. Asystem that provides C2X communication is also called a Vehicular Ad Hoc Network (VANET).In the next section the motivation <strong>of</strong> this work is presented. After that basic concepts are introduced onwhich this work is based. In the remaining sections <strong>of</strong> this chapter an overview <strong>of</strong> attacks on VANETs isgiven and the assessments <strong>of</strong> such attacks in various risk analyses are presented. The chapter concludeswith a presentation <strong>of</strong> related work. In Chapter 2 different attack methods, that could be applied byattackers in a VANET, are analyzed. The attack methods are evaluated in terms <strong>of</strong> required effort andpotential impact. In Chapter 3 the implementation <strong>of</strong> the most probable attack method is described. Theresults <strong>of</strong> test runs in which the implemented attacks were carried out are presented in Chapter 4. Aftera discussion <strong>of</strong> the results in Chapter 5 a conclusion <strong>of</strong> this work is given.1.1 MotivationA VANET has the potential <strong>of</strong> a significant increase <strong>of</strong> both, the safety <strong>of</strong> road users and the efficiency<strong>of</strong> traffic flow. However, with the use <strong>of</strong> ad hoc communication, attacks on the systems may becomepossible. Therefore securing the system against such attacks plays an important role. Only if attacks caneffectively be prevented or detected a reliable functioning <strong>of</strong> the C2X communication can be ensured.While many works exist that propose various defense mechanisms only a few works focus on possibleattacker methods. However, only with the knowledge <strong>of</strong> these methods and their possible impact on aVANET, appropriate defense mechanisms can be implemented. Therefore, in this work different attackmethods are analyzed that could be applied by attackers in the system. The outcome <strong>of</strong> the analysis isthe most probable attack method, that is subsequently considered in more deetail. After implementingan exemplary attack in a laboratory environment, the attack is then evaluated using test vehicles that areequipped with prototypic C2X communication devices. By using real systems for the evaluations a betterunderstanding <strong>of</strong> the potential impact <strong>of</strong> the executed attack can be derived. Though the test runs areperformed on a dedicated test site, similar attacks could also occur in a later deployment <strong>of</strong> a VANET. Theresults <strong>of</strong> this work aim to be helpful for the development and refinement <strong>of</strong> defense mechanisms. Byimplementing appropriate countermeasures the considered attacks must be prevented in a real VANET.7

1.2 Basic ConceptsThis section starts by introducing the concept <strong>of</strong> Mobile Ad Hoc Networks (MANET). After that WirelessSensor Networks (WSN) as a subtype <strong>of</strong> a MANET are presented. Finally, the concept <strong>of</strong> a VANET as afurther subtype <strong>of</strong> a MANET is introduced in detail providing the background for further chapters.1.2.1 Mobile Ad Hoc NetworksOver the last decades, MANETs have received a lot <strong>of</strong> attention among researchers. In contrast to wirednetworks, in which connections between nodes are determined by the infrastructure, connections betweennodes in MANETs are made ad hoc. This means that any two nodes <strong>of</strong> the network establish aconnection between each other if they are within their respective radio transmission range. With respectto the communicating nodes in a MANET, two types <strong>of</strong> networks are distinguished. In a single-hopnetwork only direct neighboring nodes can communicate with each other, i.e. every node only communicateswith other nodes that can be reached in a single hop. Usually though, a MANET is assumed tobe a multi-hop network, in which communication is also possible between distant nodes that are furtherapart than the single-hop distance.In a MANET, the individual network nodes are assumed to be mobile whereat the extent <strong>of</strong> mobilityvaries depending on the specific use case <strong>of</strong> the network. Due to this mobility <strong>of</strong> network nodes theset <strong>of</strong> nodes that are connected to each other is subject to constant change. New connections maybecome available or nodes are cut <strong>of</strong>f from the network. This means that the network has to constantlyreconfigure itself in terms <strong>of</strong> network routes or address allocation.The obvious advantage <strong>of</strong> a MANET is that such a network can be established without the need <strong>of</strong> a preexistentinfrastructure. Once network nodes are deployed and are within radio transmission range, theyautomatically set up network routes for example. Furthermore, in the case that a network infrastructurehas been destroyed, a MANET can be used as backup. For example, MANETs are proposed to be usedby emergency response teams after earthquakes or volcanic eruptions where no conventional networkcommunication is possible. Further proposed use cases include military operations since MANETs can beused during hostile battlefield operations where no usable network infrastructure exists.As described in [18] or [25] the evolution <strong>of</strong> MANETs began in the 1970s. In the beginning, deviceswere big and needed considerably more energy than today. Furthermore, the possible data throughputwas small and only simple routing protocols were used. Due to the possible application <strong>of</strong> MANETs inbattlefield operations, the U.S. military performed several projects in the following years to reduce thesize and energy-consumption <strong>of</strong> the used devices. Over the years, new technologies and standards likeIEEE 802.11 for wireless networking have become available and the prices for the needed mobile deviceshave dropped significantly.There are two prominent groups <strong>of</strong> routing protocols used in MANETs [18]. The group <strong>of</strong> reactive routingprotocols only establishes network routes on demand. This implies a certain delay at the beginning<strong>of</strong> a communication between nodes since a network path has to be established first. However, reactiverouting protocols can be very efficient in terms <strong>of</strong> energy consumption since the routing overhead is low.This is especially the case in networks with only little communication.The second group are proactive routing protocols that constantly maintain network routes betweennodes. Thus, the route is available immediately when a communication between two nodes is about tobe initiated. Because <strong>of</strong> the higher amount <strong>of</strong> routing overhead these protocols are rather suitable fornetworks with a lot <strong>of</strong> communication. In the end it always depends on the use case <strong>of</strong> the MANET whichtype <strong>of</strong> routing protocol should be chosen.8

1.2.2 Wireless Sensor NetworksA special type <strong>of</strong> MANET are WSNs. Similar to MANETs, a WSN is a self-organizing network <strong>of</strong> independentnodes that also typically use multi-hop communication. Though, a WSN differs from a MANET inseveral aspects [38] as listed in the following:• Communication: In a MANET communication is mainly done on a point-to-point basis. In a WSN,the nodes do not typically communicate with each other but forward data to a single sink node.Thus, the communication goes from many sources to one sink.• Mobility: Whereas the mobility <strong>of</strong> nodes in a MANET can be very high depending on the use case,the individual sensor nodes in a WSN are not mobile.• Energy: In a WSN energy is a limited resource. Thus, efficient use <strong>of</strong> the available energy isimportant for both hardware and s<strong>of</strong>tware. In MANETs, shortage <strong>of</strong> energy is typically not aproblem because the devices can easily be recharged or have a constant power supply.• Node count: While a WSN with only a few nodes may make sense in some use cases, in generalthe number <strong>of</strong> nodes in a WSN is much higher than in a MANET. This way the coverage <strong>of</strong> largeareas is possible.The main focus <strong>of</strong> applications for WSNs include data collection, monitoring and surveillance <strong>of</strong> certainenvironments [38]. Each node consists <strong>of</strong> the sensing hardware, a processor, memory, the power supplyand a transceiver for wireless communication [40].Depending on the use case, the cheap and smart devices are deployed on the ground or in water, onvehicles or even on humans. The individual nodes then observe or sense specific events and forward thisdata to one sink node. Advances in sensor technology have generated many kinds <strong>of</strong> small, low-powersensors which include acoustic, infrared, magnetic or seismic sensors [4].The data that is collected by the sensor nodes may be processed or aggregated in part by the nodes itselfi.e. in the network. But <strong>of</strong>ten this is only done to reduce the amount <strong>of</strong> data that has to be transmitted.The collected data is then forwarded to a sink node located out <strong>of</strong> the network where further processingtakes place. At the sink node, an administrating instance is able to monitor the network and react to theobserved events.According to [4], modern research <strong>of</strong> WSNs began around 1980. As with MANETs, military projectswere the main driver for early research in the field <strong>of</strong> WSNs. An example for this is the DARPA DistributedSensor Network Project. In this project a WSN was used to track vehicles by using acoustic sensors. Overthe years the energy consumption <strong>of</strong> sensing devices could be decreased while processing power andtransmission range increased. Apart from military purposes, prominent use cases for WSNs includehabitat and environment monitoring or traffic surveillance [2]. The flexibility, easy deployment because<strong>of</strong> the absent infrastructure and the ever-decreasing cost <strong>of</strong> the hardware constantly allow for newlyevolvinguse-cases for WSNs in many different areas. In the following, two exemplary use cases <strong>of</strong> WSNsare described.In [26], the authors describe ExScal, a project in which a WSN <strong>of</strong> more than 1000 nodes was used forthe surveillance <strong>of</strong> an area <strong>of</strong> 1.3 km by 200 m in Florida in 2004. Intruders like people or vehicles couldaccurately be detected, tracked and classified using infrared sensors. In similar deployments WSN couldbe used to effectively protect pipelines or borders at low cost and low human effort.Another exemplary use case <strong>of</strong> a WSN is the SMART system described in [6]. In this system a WSNwas used over a 18 month period to track vital signs <strong>of</strong> patients in an emergency room in Boston. Themotivation <strong>of</strong> this project was that many patients entering an emergency room are not immediatelyseen by a doctor but have to wait for a considerable amount <strong>of</strong> time. The WSN was used to track vitalsigns like electrocardiogram or oxygenation level <strong>of</strong> waiting patients and to generate alarms in case thecondition <strong>of</strong> a patient worsened.9

1.2.3 Vehicular Ad Hoc NetworksA VANET is a special MANET that is established by vehicles and road infrastructure. Before the differentaspects <strong>of</strong> a VANET are described in more detail, this section lists the differences between a VANET anda general MANET according to Schoch [36].• Communication: Several communication patterns are proposed for a VANET. In addition to thepoint-to-point communication found in MANET, these include periodic single-hop broadcast messagesfor position updates as well as event-based multi-hop information dissemination within aspecific area.• Mobility: In a MANET the mobility <strong>of</strong> nodes will usually be similar for all nodes in a specificapplication. In contrast, the mobility <strong>of</strong> vehicles in a VANET varies heavily from zero for a standingvehicle or a road-side unit up to more than 200 km/h for a vehicle on a highway.• Energy: Energy consumption in a VANET is less <strong>of</strong> an issue as in a MANET. Whereas MANET nodescan typically be recharged from time to time, the batteries <strong>of</strong> VANET nodes could constantly berecharged when in operation.• Node density: The node density varies heavily in a VANET. The number <strong>of</strong> neighboring nodeswithin communication range can vary from zero on rural roads up to more than 100 in traffic jamson big highways. In a MANET, node density will <strong>of</strong>ten be similar within the network.• Node count: The number <strong>of</strong> nodes in a VANET will increase in the deployment phase when moreand more vehicles are equipped with C2X communication devices. Eventually, the node count in aVANET will be much higher than in typical MANETs with millions <strong>of</strong> vehicles worldwide.• Node types: In contrast to a MANET, there are various node types taking part in a VANET. Eventhough most <strong>of</strong> the nodes will be private vehicles, also Road-Side-Units (RSU) and public servicevehicles with additional privileges are taking part in a VANET.• Computing power: In consequence <strong>of</strong> the better energy supply in vehicles more powerful equipmentcan be employed in a VANET in comparison to a MANET. Also due to the increasing CPUperformance at decreasing power consumption, computing power will most likely not be an issuein a future VANET.Entities <strong>of</strong> a VANETIn general, the authors <strong>of</strong> [5] distinguish three different domains within a VANET: The in-vehicle domain,the ad hoc domain and the infrastructure domain.The in-vehicle domain refers to the subsystem that is located in each C2X-enabled vehicle and road-sidestation. This system consists <strong>of</strong> one or more Application Units (AU) that run the various VANET applicationsand one On-Board Unit (OBU) that provides C2X communication capabilities. The ad hoc domainstands for C2X-enabled vehicles and possibly RSUs within a geographically limited area. When thesenodes are within single-hop communication distance <strong>of</strong> each other they establish an ad hoc communicationchannel to enable safety or traffic efficiency applications. In special cases multi-hop communicationis also used. An example for this is a warning about a road hazard that has to be disseminated withina certain area. Finally, the infrastructure domain refers to the network infrastructure that is providedby some public authority. It basically provides access to external networks like the Internet via RSUs.Furthermore, this allows for connections to a Traffic Management Center and a Certification Authority(CA). In the following list the different entities <strong>of</strong> a VANET are described.10

• AU: The AU is usually a dedicated device that is embedded into each C2X-enabled vehicle and RSU.On the AU different VANET applications are running like traffic safety applications or navigations<strong>of</strong>tware. To be able to show information to the driver, the AU can be connected to a Human-Machine Interface (HMI). For communicating with other entities the AU uses the communicationcapabilities provided by the OBU.• OBU: The main purpose <strong>of</strong> the OBU is providing access to the wireless communication to the AU.Each OBU has a wireless communication device that is used by the vehicles to exchange informationrelated to road safety and traffic efficiency. Most likely this communication device will use theIEEE 802.11p standard [37]. Additionally, an OBU may be equipped with further communicationdevices e.g. for access to mobile networks. This allows an OBU to communicate with entitieslike the Traffic Management Center even if no connection via a RSU is possible. When withincommunication range, OBUs exchange messages via ad hoc communication. Being connectedto its own internal vehicle network, the OBU has access to location and mobility data which isbroadcasted regularly to nearby vehicles. Also, the OBU is capable <strong>of</strong> routing. Thus, it may forwarddata sent by other nearby OBUs. Finally, the OBU applies security mechanisms e.g. signing andencryption <strong>of</strong> the sent data. The OBU may also be called Communication and Control Unit (CCU).• RSU: A RSU is a fixed communication device that is located near the roads. Similar to OBUs, RSUsare equipped with a wireless communication device that uses the IEEE 802.11p standard. By adhoc communication with nearby OBUs the RSUs can enhance the communication capabilities <strong>of</strong> thevehicles. For example, RSUs may forward data received from a nearby OBU in order to increase itscommunication range. On the other hand RSUs could support safety applications by disseminatinginformation about fixed road hazards or road layouts <strong>of</strong> crossroads. Finally, RSUs may provideInternet access to OBUs allowing them to communicate with a central traffic management center.• Traffic Management Center: According to [20], Traffic Management Centers are operated by publicor commercial institutions. They are responsible for collecting and providing traffic informationin order to optimize the traffic efficiency. Traditionally, the information about traffic flows is gatheredwith cameras or special sensors nearby roads and crossroads. In turn, the Traffic ManagementCenter can influence the traffic flow by controlling variable information signs or the intervals <strong>of</strong>traffic lights. By introducing VANET communications, the capabilities for information gatheringand dissemination <strong>of</strong> the Traffic Management Center could be increased significantly. By receivinganonymized traffic flow data <strong>of</strong> C2X-enabled vehicles the current traffic situation can be analyzedmore precisely and the drivers can better be informed. For example, local route advices could bedelivered via C2X communication to drivers in the relevant geographic area.• CA: A CA could be located at the Traffic Management Center. It is responsible for providing digitalcertificates to vehicles that are taking part in a VANET. This way it is possible for vehicles to validatesignatures <strong>of</strong> received messages. In case an attacker is detected in the system the CA is able torevoke his certificate. By disseminating this information to the vehicles, the attacker is practicallyexcluded from the system. Other vehicles can quickly detect data received from the attacker anddiscard it. More details concerning the security <strong>of</strong> a VANET will be discussed later.ArchitectureThe architectural layers <strong>of</strong> the C2X system running on each Intelligent Transport System (ITS), i.e. vehiclesand RSUs, are depicted in Figure 1.1. As can be seen, only the Applications Layer is implementedon the AU. All the other layers are implemented on the CCU. In the following, an overview <strong>of</strong> their mainresponsibilities is given [10].11

ApplicationsAUMAFASAManagementMFMNMIFacilitiesNFNetwork &TransportINAccessSFSNSISecurityCCUMSFigure 1.1: ITS station reference architecture as standardized by the ETSI [10]• Applications Layer: The applications layer is where the individual VANET applications are located.The European Telecommunications Standards Institute (ETSI) categorizes the applications into thethree groups road safety, traffic efficiency and other applications. An overview <strong>of</strong> the range <strong>of</strong>applications is given in a later section. According to their respective purpose, the applications areassigned with a certain priority which determines among other things their possibilities to use thecommunication channels.• Facilities Layer: The facilities layer provides a range <strong>of</strong> functionalities, that are shared among theapplications running in the Application Layer. For example, it provides access to a HMI. This way,applications may present information or warnings to the driver when required. Furthermore, commoninformation about the respective station is made available to the applications. This includesinformation about the surrounding area e.g. a digital map but also data like the current time andposition or information concerning the currently available communication channels and their capabilities.Finally, this layer supports the management <strong>of</strong> the communication with other stations inthe system. It is ensured that messages are sent in accordance to the requirements <strong>of</strong> the station.Also the repeated sending <strong>of</strong> event-based messages is handled by this layer which can be triggeredby applications.• Network and Transport Layer: This layer basically contains implementations <strong>of</strong> the needed networkand transport protocols. UDP and TCP may be examples for transport protocols among others.As network protocol this may be a special type <strong>of</strong> IPv6 or further protocols specifically designed forVANETs. Different communication patterns that may be used in a VANET will be introduced in thenext section.• Access Layer: The access layer provides physical connections to the various communication channelslike ITS-G5 or 3G. The access to communication mediums is controlled here and the priorities<strong>of</strong> applications and messages are considered during this process.• Management Layer: This layer contains various management functionalities that ensure the correctoperation <strong>of</strong> the ITS station. One group <strong>of</strong> functionalities concerns application management,for example functionality for installing and updating applications. Also application error handlingor detection <strong>of</strong> harmful application behavior is implemented here. Next, this layer is responsible forthe congestion control <strong>of</strong> the communication channels. For this purpose, the priorities <strong>of</strong> messagesmay be changed depending on the current communication load.12

• Security Layer: In the security layer all <strong>of</strong> the security related functionality is located. Besidescontrolling intrusion detection this includes signing and encryption <strong>of</strong> outbound messages as wellas the verification and decryption <strong>of</strong> received messages. Finally, the cryptographic material ismanaged in this layer. The security aspects <strong>of</strong> a VANET are covered in more detail in a separatesection.CommunicationThe communication technology that will most likely be used in a VANET is introduced first. After that thetwo main message types are defined that are most important for traffic safety and efficiency functions inVANETs. Finally, various communication patterns for the typical VANET applications are described.The main communication standard to be used by the core safety applications is IEEE 802.11p [37] definedby the IEEE for both C2C and C2X communication. Based on the family <strong>of</strong> IEEE 802.11 standardsthat are widely used for wireless networking, IEEE 802.11p takes into account VANET-specific requirements.For instance, it allows higher communication ranges and better tolerates the high mobility <strong>of</strong>network nodes. In the Unites States, the frequency spectrum between 5.850 GHz and 5.925 GHz hasbeen allocated by the Federal Communications Commission (FCC) for so-called Dedicated Short-RangeCommunication (DSRC) in vehicular networks. In Europe, the term ITS is more commonly used in thearea <strong>of</strong> vehicular communication. Here, the frequency spectrum between 5.875 GHz and 5.905 GHzhas been allocated for this purpose by the European Commission. Based on these frequency spectrumregulations, the ETSI defined several standards among which ITS-G5A is the core part to be used forsafety applications. A dedicated frequency range assures that safety-related messages are transferred ina timely manner and interferences with other applications using these frequencies are prevented.Apart from IEEE 802.11p, a wide range <strong>of</strong> further communication technologies can be used for nonsafetyapplications. For example, it is supposed to use other protocols <strong>of</strong> the IEEE 802.11 group for mediastreaming. Furthermore, mobile networks like GSM, UMTS or LTE might be used for the communicationbetween vehicles and the traffic management center in case no connection via RSUs is possible. AfterMAC Data Network Data Security Data C2X Payload DataFigure 1.2: General structure <strong>of</strong> a C2X messagedescribing the communication technology, the structure <strong>of</strong> a C2X message is explained. The generalstructure <strong>of</strong> such a message is depicted in Figure 1.2. As can be seen each message consists <strong>of</strong> foursections. The first section contains common data like the length <strong>of</strong> the message and the protocol version.The network data section contains data concerning the routing <strong>of</strong> the message. This includes the locationand mobility data <strong>of</strong> the sender as well as the destination <strong>of</strong> the message. The content <strong>of</strong> the networkdata section is exclusively used by the network layer. The fourth section <strong>of</strong> a C2X message contains theactual payload which is used by the applications layer. This data is set and read by the applicationsrunning on the AU. Among other data, this section again contains the location and mobility data <strong>of</strong>the sender. Finally, the security data section contains data concerning the security. This includes thesignature and certificate for the message. This data is used by the security layer. All <strong>of</strong> the layersintroduced in Section 1.2.3 are operating strictly separated from each other. This means that the data <strong>of</strong>each message section is only used within one architectural layer. Furthermore, no consistency checks <strong>of</strong>data <strong>of</strong> different layers are performed. For example, the locations stored in the network data section andthe payload data section are not checked for consistency.In the next two paragraphs the two main C2X payload data types are defined in more detail. The messagesare called Cooperative Awareness Message (CAM) and Decentralized Environmental NotificationMessage (DENM).13

CAMThe CAM as standardized in [13] is sent periodically by every vehicle taking part in a VANET to informnearby vehicles about its presence and mobility. The message is sent as single-hop broadcast using theITS-G5A network so that all vehicles within radio transmission range get informed. In the following, themost important information contained in a CAM is listed:• StationID• Position• Heading• SpeedFurther defined data fields include for example the length and width <strong>of</strong> the vehicle and the currentacceleration. Depending on the situation, a CAM is sent out with different frequencies between 1 Hzand 10 Hz. Each vehicle stores the data received from nearby vehicles in the so-called neighborhoodtable which stores the data and always holds a up-to-date view <strong>of</strong> the surrounding area. By using theneighborhood table applications can assess the situation on the road to perform use cases like generatinga warning message in case a collision becomes imminent.DENMThe DENM is the second main message type [14]. In contrast to the periodically sent CAM, the sending<strong>of</strong> a DENM is event-triggered. DENMs are mainly used to alert drivers about road hazards. The standardTS 102 637-3 [14] defines 13 events that trigger the sending <strong>of</strong> a DENM, for example road-works ora vehicle performing an emergency brake. Also, DENMs can be used in terms <strong>of</strong> traffic efficiency e.g.warning about traffic jams. The main data fields contained in a DENM are• Event type• Geographic area / position• Detection time• DurationOnce a vehicle detects an event that triggers a DENM it starts transmitting the warning message at acertain frequency. In contrast to a CAM, a DENM should be disseminated to as many vehicles as locatedwithin the geographically relevant area which is defined in the message. Therefore, vehicles mayforward the message upon reception. Furthermore, the sending <strong>of</strong> the warning message can also berelayed to other vehicles in case the originating vehicle has already left the geographically relevant area.The dissemination <strong>of</strong> the DENM either ends at a predefined expiry time or until the end <strong>of</strong> the event isexplicitly announced e.g. when road-works are finished.The characteristic mobility <strong>of</strong> the nodes in a VANET also influences the communication among them.On the one hand the speed <strong>of</strong> participating nodes varies heavily. When two vehicles pass each other athigh speeds and in opposite directions they are only able to communicate during a small timeframe <strong>of</strong> afew seconds. This includes that communication links between neighboring vehicles are cut <strong>of</strong>f regularlyand new connections are established.A further characteristic in a VANET that influences the communication is the varying node density.On rural roads that are only used by a few cars at a time it is likely that there are no vehicles withincommunication range. On the contrary, the number <strong>of</strong> vehicles within range can well exceed 100 intraffic jams on highways. In such a scenario it has to be made sure that the communication channel doesnot get overloaded by too many simultaneously sending vehicles. This could be achieved by reducingthe transmission frequency in such cases.14

This knowledge may be gained by the local sensors but also by received data from other vehicles. Eachtime when new information arrives, it is integrated into the existing knowledge. This way, the vehiclehas always access to the latest data which is also sent out to other vehicles. If for example a traffic jamis detected by several vehicles on a highway, not all <strong>of</strong> the associated messages do need to be forwardedbut only one condensed message.ApplicationsThere is a widespread spectrum <strong>of</strong> applications that may be introduced into a VANET [5, 11, 28, 41].In this section examples <strong>of</strong> possible applications are described using a common classification into thegroups safety, traffic efficiency and others.SafetyThe applications <strong>of</strong> this group aim at directly improving the safety <strong>of</strong> drivers. These applications are amain driver for the development <strong>of</strong> a VANET.One application is the forward/rear collision warning. In today’s road traffic a lot <strong>of</strong> rear-end collisionsoccur. Reasons for such collisions include the distraction <strong>of</strong> drivers in dense traffic or sudden brakemaneuvers combined with low distance between the vehicles. Also, at low visibility the brake intensity<strong>of</strong> vehicles in front may be underestimated by drivers. In a VANET, vehicles are aware <strong>of</strong> the mobilitydata <strong>of</strong> surrounding vehicles and thus are able to detect situations where collisions become possible.In this case the application could warn the driver visually, acoustically or even haptically in order toprevent collisions. Already, there are systems that aim at avoiding collisions with vehicles in the front byusing radar sensors that detect nearby objects. However, if the braking vehicle is not visible because it ishidden by another vehicle or also in bad weather this may not work. By using C2X communication, theeffectiveness <strong>of</strong> such applications will be improved.Similar to the forward/rear collision warning, electronic brake lights (EBL) may help to reducecollisions due to vehicles performing emergency brakings that are not adequately recognized by followingvehicles. Again, vehicles in between could block the sight on the braking vehicle for example. Also, whenemergency-braking is performed, following drivers have to react quicker and may need to brake harderthemselves in order to prevent a collision. The EBL application can be seen as an enhancement <strong>of</strong> theconventional brake lights. Once a vehicle detects a hard braking maneuver <strong>of</strong> its driver it sends out awarning message in order to notify surrounding vehicles about this event. Based on the location andmobility data contained in the message each receiving vehicle is now able to determine whether thebrake maneuver may interfere with its own movement path. In this case the driver can be warned basedon the locally calculated time to a possible imminent collision.Apart from brake maneuvers, collisions may occur due to misbehaving or misjudging driving at intersections.Since in these situations vehicles are driving within low distance to each other, drivers can onlyreact during short timespans in case a vehicle does not comply with the traffic lights or the priority intraffic. Applications that may help to prevent collisions in this case include the left turn assistant or thetraffic signal violation warning / intersection collision warning. Especially in scenarios with densetraffic it is not always easy for drivers to judge when a left turn at an intersection can safely be performedin order not to risk a collision with vehicles driving in the opposite direction. In these cases a left turnassistant could support the driver during these maneuvers. When the application detects a left turn bythe driver, it could evaluate C2X messages received from crossing vehicles and warn the driver in casea collision could occur. Another scenario would be that the application advices the driver beforehandwhether a left turn can safely be performed without interfering with crossing vehicles. Since this couldonly reliably be done if all vehicles are equipped with C2X devices, additional sensors could be usedat intersections to check for crossing traffic. Also the regular transmission <strong>of</strong> the intersection layout bystationary RSUs could help to increase the precision <strong>of</strong> this application.16

In case the signaling phases <strong>of</strong> traffic lights are also transmitted, it becomes possible to warn driverswhen they are about to violate a red light. Additionally, in case the traffic light violation is not preventedon time, nearby vehicles could be informed similar to the emergency braking warning.Traffic EfficiencyApart from preventing collisions, the transmission <strong>of</strong> signaling phases could also help to increasetraffic efficiency as well as driving experience. With an application called Green Light Optimal SpeedAdvisory (GLOSA) vehicles are enabled to provide speed advisories to their drivers based on the receivedsignaling phase data and their own position and speed. Thus, the likelihood <strong>of</strong> reaching the intersectionduring a phase <strong>of</strong> a green traffic light can significantly be increased. Apart from increasing the possibletraffic flow, stops due to red lights are minimized which also increases the driving experience for thedriver. For this purpose, additionally the remaining time <strong>of</strong> the current green and red light phases couldbe presented to the driver allowing him to achieve a smoother and more relaxed driving.With an increase in traffic volume an efficient traffic flow control will further gain importance. Alreadytoday navigational systems are able to display information about traffic jams or road works todrivers and consider this information while finding the best route. In a future VANET system the accuracy<strong>of</strong> this information could be significantly increased by dynamically updating the information usingmobility data from vehicles. When this mobility data is processed in traffic management centers additionallydynamic traffic signs can be updated accordingly or route guidance information can directly besent to vehicles on a certain route.Finally, a parking spot locator application could help drivers to find the nearest parking spot in theirvicinity. For this purpose information about free parking capacities <strong>of</strong> parking garages or locations <strong>of</strong>free parking spots in a city can be used.OthersMany different applications belong to this group. Although safety and efficiency applications are moreimportant there are also applications providing less use but that are still improving the driving experience.It is believed that these applications could help during the deployment phase <strong>of</strong> a VANET byproviding benefit to the first users. As long as the percentage <strong>of</strong> vehicles equipped with C2X devices islow the safety applications will not yield a significant benefit. Thus, the technology could be rejected bypossible users e.g. due to the additional cost. An <strong>of</strong>ten named application in the literature is the possibleInternet access in vehicles. This indeed would be possible if RSUs act as access points. However, itis questionable if the relevance <strong>of</strong> this will still be as high as today given the fast evolution <strong>of</strong> mobilenetworks that already enable Internet access on smart phones for example. Maybe RSUs could providefree access in order to increase the attractiveness <strong>of</strong> the system. Furthermore, payment services maybecome possible to be performed via C2X communication. This way, toll collection could be automaticallybe performed. Further examples where this could be used are parking garages or gas stations.Finally, remote diagnostic services or information about nearby points <strong>of</strong> interest are further possibleapplications.SecurityThe safety <strong>of</strong> drivers within a VANET can be threatened by attacks on the system. For this reason thesecurity plays an important rule in such a system. In this section, first general definitions <strong>of</strong> security goalsare given and their roles in a VANET are stated. After that the main security mechanisms are presentedthat should be included in a VANET in order to achieve the defined security goals.The definitions <strong>of</strong> the general security goals are based on [9]. The discussions <strong>of</strong> these security goalsand the consequences concerning a VANET are based on the respective elaborations in [16], [20], [31]and [36].17

• Authenticity: Authenticity refers to the genuineness and trustworthiness <strong>of</strong> an object or a subject.The authenticity can be verified with an unique identity and characteristic features. The verification<strong>of</strong> authenticity is referred to as authentication. A user could for example use a password to provehis identity. Furthermore, authentication is very important for communication in networks. Byusing authentication techniques, a receiver <strong>of</strong> a message is able to determine whether a messageoriginates from the reported sender.In a VANET, authenticity is one <strong>of</strong> the most important security goals. Only entitled nodes are allowedto participate in the C2X communication. Since vehicles have to rely on the received data,they have to authenticate the senders <strong>of</strong> each received message. This way it can be determined ifthe sender is a valid participant <strong>of</strong> the system. Furthermore, it is important to be able to definedifferent roles in a VANET. Emergency vehicles for example could be able to preempt traffic lightsin case <strong>of</strong> an emergency. It has to be determined whether a vehicle that requests such an actionis entitled to do so. This process is also referred to as authorization. An other example whereauthenticity needs to be determined are s<strong>of</strong>tware updates for the on-board applications. Withoutauthentication it would not be possible to decide whether a new s<strong>of</strong>tware originates from atrustworthy source or if a s<strong>of</strong>tware may be malware.• Integrity: Within a system that provides integrity, it is not possible to alter data without the rightto do so. Deletion or addition <strong>of</strong> data also counts as alteration in this case. This definition impliesthat it has to be specified, who is allowed to change which data. In order to provide data integrityone could make unauthorized alteration <strong>of</strong> data impossible. In systems where this is not possibleit has to be able to detect each unauthorized data alteration afterwards.The integrity <strong>of</strong> sent data has to be ensured in a VANET. This guarantees that attackers are not ableto change the contents <strong>of</strong> a sent C2X message. This is important because messages are <strong>of</strong>ten forwardedby various participants before reaching their destination. If the integrity is not guaranteed,an attacker could modify the content <strong>of</strong> received messages before forwarding them. Apart fromthe intentional alteration <strong>of</strong> data also non-intentional data alteration has to be considered. Due totechnical defects or s<strong>of</strong>tware faults this can not fully be prevented. Thus, there have to exist mechanismsthat detect this unintentional data alteration afterwards. Cryptographic hash functions arean example for this.• Confidentiality: The confidentiality ensures that no unauthorized gain <strong>of</strong> information is possible.This guarantees that information only reaches participants that are entitled to access it. Similarto integrity, this implies a definition <strong>of</strong> data access rights for each participant. In principle, confidentialitycan be achieved using various techniques <strong>of</strong> encryption. As long as only authorizedparticipants possess credentials that are needed to access the encrypted data, this makes sure thatthe confidentiality <strong>of</strong> a sent message is provided.Requirements regarding confidentiality are application specific in a VANET. Most traffic safety andefficiency applications do not require confidentiality or even not want it. Examples for this are thetransmission <strong>of</strong> CAMs to nearby vehicles or messages warning about road hazards. For this datathere are no requirements regarding confidentiality because this information is to be made knownto all <strong>of</strong> the affected vehicles. Other applications like Internet access in cars have to be securedusing confidentiality.• Availability: In a system that provides availability, it is not possible to hinder authorized andauthenticated users to perform a certain action. Note, that such a hindrance can also be inducedby permitted actions. Thus, it can not always be determined, whether the hindrance was caused onpurpose or not. For example, if one user’s access <strong>of</strong> a shared resource increases, this could reducethe possible access to that resource for other users.Many <strong>of</strong> the security relevant VANET applications are based on time-critical communication withother vehicles. To provide a fault-free operation <strong>of</strong> these applications, the availability <strong>of</strong> the system18

has to be made sure at all times. As for the communication, various redundant communicationchannels could be introduced in order to be able to tolerate the failure <strong>of</strong> one channel. For instance,an attacker could make a communication channel useless with a jamming attack.• Non-repudiation: The security goal non-repudiation refers to the fact that participants <strong>of</strong> a systemcannot deny their actions afterwards. In other words, after a certain action by a participant <strong>of</strong>a system it should be possible for a third party to pro<strong>of</strong> that he or she indeed has performedthis action. In general, non-repudiation plays an important role whenever legal transactions areperformed e.g. e-business. For billing for resource usage in multi user systems the non-repudiationis a primary requirement.In a communication system like a VANET non-repudiation is especially important for the actions<strong>of</strong> sending and receiving <strong>of</strong> messages. Given that non-repudiation is provided, it can always bedetermined which information a participant had at a certain time. This may be helpful during theinvestigation <strong>of</strong> an accident for example in order to determine who caused the accident. However,it depends on the definition <strong>of</strong> the privacy policy whether this will be possible in a VANET.In order to achieve the listed security goals the following security mechanisms are proposed to be usedin a VANET.• Electronic Signatures: As described in the previous list, nodes have to be able to clearly identifythe sender <strong>of</strong> a received message. This can be achieved by using electronic signatures. An electronicsignature is the electronic counterpart <strong>of</strong> a handwritten signature. For this, they are commonly usedin many applications like e-business. Additionally, there are legal requirements that make the use<strong>of</strong> electronic signatures necessary. Besides for encryption, the well known RSA-algorithm can beused for signing. Each participant holds a pair <strong>of</strong> corresponding keys, one is private and the otheris public. The public key is stored in a publicly accessible directory. The sender can now derivea signature <strong>of</strong> a message by encrypting the hash value <strong>of</strong> the message with his private key. Onreception <strong>of</strong> a message the receiver can now use the public key from the public directory to decryptthe signature data and thus verify the signature.By using electronic signatures it is possible to clearly associate a message with its sender whichprovides authenticity. Additionally, changes to the original data is detected upon verification sothat integrity also is given. As long as the private keys are kept secret by their owners, nonrepudiationis also achieved since only the sender knows the private key that was used to sign amessage.• Certificates: As described, receivers <strong>of</strong> a message need to obtain the public key <strong>of</strong> the supposedsender in order to verify a signature. In order to make sure that the obtained public key reallybelongs to the sender, certificates are used. The CA is responsible for the issuing <strong>of</strong> these certificatesto network nodes and for the management <strong>of</strong> the certificates. The issued certificates are in turnsigned with the private key <strong>of</strong> the CA. Thus, users only need the public key <strong>of</strong> the CA to be able toverify a received certificate what in turn allows them to clearly authenticate the sender <strong>of</strong> receivedmessages. In a VANET the public key <strong>of</strong> the CA can be stored in the vehicles at production time inform <strong>of</strong> a root certificate.Apart from verifying signatures, certificates can also be used to exclude vehicles from taking partin the network communication. If for example an attacker was able to compromise the on-boardsystem <strong>of</strong> a vehicle and is then able to execute attacks by sending wrong messages it should bepossible to exclude such compromised vehicles from the network. Furthermore, technical malfunctionswhich could lead to the sending <strong>of</strong> wrong data may make such exclusions necessary. For thatreason, the CA can revoke the certificate <strong>of</strong> such vehicles in order to prevent further damage tothe VANET. The information about such revocations could be distributed by CRLs which basically19

contain the information which certificates are no longer valid. In order to keep the amount <strong>of</strong> revocationinformation small, various approaches exist. For example, one could limit the lifespan <strong>of</strong>all <strong>of</strong> the certificates and regularly issue new certificates to authorized vehicles. If a compromisedvehicle then is detected, it does not get new certificates. Additionally, the CRL does only have tocontain those certificates that have been revoked during their predefined lifespan. This way, theneeded bandwidth for distributing the revocation information can be significantly reduced.PrivacyBesides security, the privacy <strong>of</strong> participants in a VANET is an important topic. In a system that providesprivacy, the user is able to control how his personal data is used and who has access to it. Nowadays,the privacy plays an increasingly important role in many fields. Especially in systems like a VANETwhere data is processed electronically it is <strong>of</strong>ten difficult for the users to control, what personal data ismade available to whom. On the one hand, privacy protection is required by law. In Germany, personalinformation can only be collected with the agreement <strong>of</strong> the user and can only be used for its intendedpurpose. The authors <strong>of</strong> [24] further elaborate on the legal situation in Germany. In recent years, endusers are becoming more aware <strong>of</strong> concerns regarding their privacy. A study cited in [20] showed thattraffic information systems are seen as a threat for one’s privacy by about one quarter <strong>of</strong> the participantsin France and Germany. As a consequence, users might not accept systems like a VANET in case it doesnot provide mechanisms that adequately protect their privacy.In a VANET, it is mainly the location and mobility data <strong>of</strong> vehicles that could be used to violate theprivacy <strong>of</strong> drivers. If it would be possible to link the identifier to a certain vehicle, the received data couldbe used to derive detailed movement patterns <strong>of</strong> the vehicles. Furthermore, these movement patternscould even be linked to certain persons or addresses by analyzing frequent destinations for example.Specific examples how such movement patterns could be used are described by Dötzer et al. in [8]. Inorder to provide privacy in a VANET it has to be impossible to link a given identifier to a vehicle. For thisreason pseudonyms [9] will be used in a VANET. Based on one long-term certificate for every vehicle,the CA issues short-term certificates which can be used as pseudonyms during the communication withother vehicles. In this concept, only the CA is able to link a given short-term certificate to a specificvehicle. Vehicles themselves are in turn not able to identify the other vehicles permanently since theyonly receive information based on pseudonymous short term certificates that are changed on a regularbasis. However, by using pseudonyms, the temporary tracking <strong>of</strong> vehicles is still possible. For example,if vehicles are tracked permanently, it becomes possible to match two different certificates by evaluatingdata including speed and heading under consideration <strong>of</strong> boundaries for changes in acceleration andheading for example.Another approach that has been discussed is the use <strong>of</strong> group signatures. In this concept a certificateis shared between various vehicles so that it becomes impossible to link a signature to one single vehicle.However, this makes it also harder if not impossible to detect misbehaving vehicles according to [30].Furthermore, group signatures are computationally more expensive and thus may not be suitable for aVANET [31].A common problem with pseudonymity is that data from multiple sources could be correlated wherebydata might be derived that more severely infringes the privacy <strong>of</strong> the users [8]. In a VANET, collectedlocation data could be matched for example with data from security cameras to link the location data toa specific vehicle.1.3 <strong>Attack</strong>s on Vehicular Ad Hoc NetworksSince the security <strong>of</strong> VANETs is a crucial aspect <strong>of</strong> the system many analyses <strong>of</strong> possible attacker typesand attack types have been made [1, 29, 31]. This section first gives a general overview <strong>of</strong> attacks onVANETs. Subsequently, a classification <strong>of</strong> attacks and attackers in a VANET is presented.20

1.3.1 Classification <strong>of</strong> <strong>Attack</strong>ersIn this section, an overview over different attacker types that may appear in a VANET is provided.Depending on the intentions, technical equipment and knowledge the amount <strong>of</strong> harm caused by theattacker can vary. Various works have done a classification <strong>of</strong> possible attacker types in a VANET[22, 29, 31]. For this thesis, attacker types are classified according to the following four dimensions.Only the male form is used when referring to the attacker. Obviously an attacker can also be female.• Internal/External: An internal attacker is in possession <strong>of</strong> the cryptographic material what allowshim to generate messages that are considered to be valid by other participants <strong>of</strong> the network. Anexternal attacker on the other hand is not able to take part in the network protocols. The externalattacker is seen as an intruder by the other internal nodes <strong>of</strong> the network.• Malicious/Rational: An attacker that aims at causing harm to the network is called malicious. Forexample, the attacker could try to provoke accidents or traffic jams by sending forged messages.If, on the other hand, the attacker aims at achieving pr<strong>of</strong>it he is called a rational attacker. Apartfrom monetary pr<strong>of</strong>it, the goal <strong>of</strong> this type <strong>of</strong> attacker could be to reroute other participants <strong>of</strong> thenetwork in order to have less traffic in his surrounding.• Active/Passive: A passive attacker is limited to eavesdropping the network traffic and extractinginformation from received messages. Goals <strong>of</strong> this attacker type might include the derivation <strong>of</strong>movement patterns. In addition to the ability to gather information about network nodes, an activeattacker is able to actively take part in the network, i.e. sending <strong>of</strong> self generated messages. Thus,he could influence the behavior <strong>of</strong> other nodes to his advantage.• Stationary/Mobile: If the attacker does not change his position he is denoted stationary attacker.An example for this is a stationary attacker at the roadside that uses a laptop to communicate withthe nodes <strong>of</strong> the network. A mobile attacker on the other hand is typically a driving vehicle. Asshown in later sections, it is more complicated for other nodes to detect a mobile attacker.After having defined the attack dimensions, three common attacker types are described in accordanceto [22].• Road-side attacker: This type <strong>of</strong> attacker is assumed to be located at a stationary location by theroad. He uses a laptop to send and receive messages and usually has malicious intentions. Theimpact <strong>of</strong> such an attacker is especially high in case he managed to extract cryptographic material<strong>of</strong> a valid node so that he becomes an internal attacker. By transmitting messages with forgedvalues he could provoke vehicles to brake and thus cause harm to the network.• Driver with vehicle: A driver is participating in the network with his own car and uses its OBU tocommunicate with other devices <strong>of</strong> the network. Thus, he is an internal and mobile attacker. Onecould assume that a driver with sufficient knowledge succeeds in manipulating his own OBU. Thiscould enable him to manipulate sent messages or generate additional messages. One type <strong>of</strong> attackcarried out by this attacker could be to create the impression <strong>of</strong> a traffic jam on his road section tomislead other vehicles. This way the attacker would have less traffic on his own route.• Infrastructure-based attacker: In contrast to the previous attacker types, this attacker is passive.He collects the network traffic from participating nodes and thus is able to derive movementpatterns <strong>of</strong> the nodes in the network. To be able to collect large amounts <strong>of</strong> data he needs theknowledge to gain access to the infrastructure <strong>of</strong> the network. An infrastructure-based attackermay be aiming at achieving financial pr<strong>of</strong>it by selling the obtained information to interested parties.21

1.3.2 Classification <strong>of</strong> <strong>Attack</strong>sIn [1] the authors have established a model <strong>of</strong> possible attacks on a VANET. They grouped VANET applicationsinto four groups: car to car, car to infrastructure, car to home and routing based. Since the mainfocus <strong>of</strong> this thesis lies on the first group only attacks <strong>of</strong> that group are presented.For attacks on car to car traffic applications the authors identified two main attack goals: Disseminatefalse messages and disturb system. Each <strong>of</strong> these goals can be achieved in different ways that aredescribed in the following sections.Disseminate false messagesAs for the dissemination <strong>of</strong> false messages, three attack types can be distinguished: Generating newmessages, replaying messages, and modifying messages. One way in which all <strong>of</strong> these attack goals canbe achieved is by breaking the cryptographic system. In this case the attacker could generate arbitrarymessages that would be considered as valid by the other vehicles. Further ways <strong>of</strong> achieving this goalare discussed in the following paragraphs:• Generate new messages: Apart from attacking the cryptographic system an attacker could try tobecome part <strong>of</strong> the network and then inject generated messages. In order to become part <strong>of</strong> thenetwork the attacker needs to obtain valid identifiers in order for the other vehicles to consider hima valid node. For example the attacker could extract valid identifiers from a stolen car. Once theattacker possesses valid identifiers he could then directly inject his generated messages that wouldbe considered as valid by other vehicles. This is probably the most severe attack since the attackercan send as many messages as he likes with arbitrary content. In case the attacker is able to obtainseveral identifiers the well-known Sybil <strong>Attack</strong> [7] becomes possible. In a Sybil <strong>Attack</strong> the attackeris able to pretend being several nodes by changing the respective identifier used when sending amessage. This can have severe impact on the network. In a VANET the attacker would be able tosimulate several cars and thus simulate whole traffic situations that would be considered valid byother vehicles. For example he could simulate a traffic jam in order to redirect other vehicles andobtain a free road for himself.• Replay messages: Another way <strong>of</strong> disseminating false messages is to replay captured messages.By listening to the communication channel and capturing messages the attacker can then resendi.e. replay them again. Since these messages have been generated by vehicles with valid identifiersthese messages are already valid. One can distinguish two types <strong>of</strong> replay attacks - time-basedand location-based. In the first case the attacker captures messages and retransmits them at alater time. This can be prevented by including a timestamp in each message that is checked bythe receiving node. In the second case the attacker uses an alternative network to route capturedmessage to another part <strong>of</strong> the network where he injects the messages into the VANET. Dependingon the time needed to reroute the messages even timestamps in messages could not prevent this.This attack is also known as wormhole attack [17]. Furthermore, the attacker could combine thetime-based and location-based replay attacks.• Modify messages: As for modifying messages the attacker would again capture valid messages,modify their content and then resend them. In order for the modified messages to be consideredvalid the attacker would have to break the integrity protection <strong>of</strong> the messages. Since messagesare sent out using broadcast in the general case nodes would receive the message twice - once thecorrect message and once the modified message.From these three methods to disseminate false messages, generating new messages is the most severe.Here the attacker is able to send as many messages as he wants with arbitrary content.22

Disturb systemThe aim <strong>of</strong> this group <strong>of</strong> attacks is to hinder the system from functioning properly. The authors distinguishfour types <strong>of</strong> attacks in this group.• Incapacitation <strong>of</strong> network nodes: First, an attacker could be able to shut down network nodesremotely by exploiting security flaws for example. This way he could disable the whole network inhis vicinity.• Suppress communication: Another way to disturb the system is to render one or all <strong>of</strong> the usedcommunication channels useless. A prominent attack to do this is jamming. Here, the attackerkeeps sending on the communication frequency thus preventing access to the channel for othernodes. Apart from jamming the channel used for communication between nodes the attacker alsocould jam the GPS frequencies so that vehicles would no longer be able to determine their position.• Network misbehavior: These attacks aim at disturbing the routing <strong>of</strong> messages. For example anattacker could choose not to forward messages properly or just forward certain messages. Executedby a single attacker the impact <strong>of</strong> such an attack will be rather low depending on the networktopology and the used communication pattern. The impact could be increased in case severalattackers perform this attack coordinated.• Application layer misbehavior: Finally, the attacker could try to overload one or several nodes<strong>of</strong> the network on the application layer. Here the attacker would keep sending messages at highfrequency to the node under attack so that it becomes overloaded processing them. This way, thenormal behavior <strong>of</strong> the node can be restricted severely. In the worst case the node is no longer ableto participate in the normal communication.As described, attacks <strong>of</strong> this group aim at reducing the availability <strong>of</strong> the system. In the worst case thesystem is shut down in certain areas. Therefore, it is concluded that the dissemination <strong>of</strong> false messagesis the most severe group <strong>of</strong> attacks that is possible in a VANET.1.4 Risk AnalysesSeveral works have already performed risk analyses evaluating the various threats that are existent ina VANET. By assessing the potential impact and likelihood <strong>of</strong> exploitation the risk <strong>of</strong> each threat canbe derived. Subsequently, a number <strong>of</strong> countermeasures can be identified, that are needed in order tomitigate or prevent the possible exploitation <strong>of</strong> the threats. By presenting the relevant information fromthe various risk analyses it will be shown that the injection <strong>of</strong> messages with wrong position informationi.e. position forging is commonly considered to be a severe threat in a VANET.1.4.1 PreServeIn [39], the authors evaluated several risk analyses and joined the threats grouped by the threatenedsecurity goal. The threats were then assessed and assigned to one <strong>of</strong> the following classes <strong>of</strong> severity:• Minor: Threats with low possible impact and likelihood.• Major: Threats with high possible impact and likelihood.• Critical: Threats with very high possible impact and likelihood.23

The identified threats including their assigned severity classes can be seen in Table 1.1. Threats on theavailability <strong>of</strong> the system may in the worst case render the system and its application non-functioning.This means that the benefit that is usually provided by the VANET applications is lost for the driversduring a possible attack. For example, by jamming <strong>of</strong> the communication channels or performing a DoSattack the transmission <strong>of</strong> warning messages can be suppressed by an attacker. By performing a selectivejamming attack the attacker could even decide which messages he suppresses and thus focus on a specificvehicle or message type during his attack. Although this clearly is an undesirable condition in a VANET,the attacker’s capabilities are limited to suppressing the communication <strong>of</strong> valid vehicles.As for the group <strong>of</strong> threats concerning integrity, the attacker is able to actively influence the behavior<strong>of</strong> the attacked vehicles. In case such manipulation is not detected by the valid vehicles, they wouldconsider the wrong data to be valid and possibly take wrong actions based on the received data. Byintegrating malware into the on-board system <strong>of</strong> a vehicle, the attacker would even be able to generatefalse messages that would be considered valid by receiving vehicles. This way it is possible for theattacker to actively simulate certain traffic conditions. For example the attacker could send out falsewarning messages which could mislead other vehicles into dangerous driving maneuvers. Also, he couldsimulate traffic jams in order to reroute other vehicles and get a free road for himself.The remaining threats aim at violating the confidentiality, privacy and accountability / non-repudiation<strong>of</strong> drivers. For example, by gaining access to the sensitive data <strong>of</strong> the CA, an attacker might be able tolink pseudonyms to its owners in order to derive movement patterns. Threats <strong>of</strong> the group accountability/ non-repudiation present mostly legal problems. By tampering with the certificates managed by the CAan attacker could obfuscate own traffic violations for example. Although threats <strong>of</strong> these groups alsorepresent severe intrusions into the system the safety <strong>of</strong> drivers is not endangered.1.4.2 EVITAThe EVITA project aimed at designing a C2X architecture with a focus on security. Not only should the incardevices and networks be guarded against unauthorized access but also the external interfaces like thecommunication with other vehicles. During the project the security requirements <strong>of</strong> such a system weregathered and different threats identified. These threats and security requirements were published in[32]. Each threat was assessed in terms <strong>of</strong> various categories and then assigned to one <strong>of</strong> five groups forthe needed attack potential ranging from Basic to Beyond High. The assessment <strong>of</strong> the threat <strong>of</strong> injectionfake messages into the communication system is shown in Table 1.2. As can be seen it is considerablyeasy for an attacker to perform such an attack and only basic attack potential is needed. Therefore it islikely to encounter such attacks in a future VANET.1.4.3 ETSIThe ETSI performed an extensive risk analysis in order to identify appropriate countermeasures that willhave to be introduced into a VANET [12]. First, for each <strong>of</strong> the required security goals the correspondingthreats are identified. After that risks are derived for both, vehicles and RSUs. The threat <strong>of</strong> positionforging belongs to the group Modification and deletion <strong>of</strong> transmitted information. Its impact is rated ashigh and its risk rating is established as critical.1.4.4 simTDA risk analysis for the simTD project has been done in [24]. Position forging can be seen as part <strong>of</strong> thethreat manipulation <strong>of</strong> transmissions. Especially for malicious and scientific attackers this is regarded asa very attractive attack with a high impact on the system.24

Number Threat Security Goal Severity1.1 Jamming <strong>of</strong> signals Availability Major1.2 Denial-<strong>of</strong>-Service <strong>of</strong> V2X communications Availability Critical1.3 Denial-<strong>of</strong>-Service <strong>of</strong> on-board units and internal buses Availability Minor1.4 System infection with malware Availability Critical2.1 Manipulation <strong>of</strong> the routing table, LDM or application Integrity Criticalbehavior <strong>of</strong> other ITS station2.2 Manipulation and Corruption <strong>of</strong> relayed data en route Integrity Major2.3 Sensor (data) manipulation Integrity Major2.4 Integration <strong>of</strong> malware Integrity Critical2.5 Access to cryptographic private key material and credentials Integrity Major2.6 Manipulation <strong>of</strong> communication recording system Integrity Minor2.7 Manipulation <strong>of</strong> backend databases Integrity Major3.1 Eavesdropping <strong>of</strong> privacy relevant data Confidentiality Critical3.2 Interception and eavesdropping <strong>of</strong> confidential SW Confidentiality Major4.1 Collect privacy sensitive data Privacy Major4.2 Resolution <strong>of</strong> pseudonyms Privacy Major4.3 Integration <strong>of</strong> malware Privacy Minor5.1 Manipulation <strong>of</strong> data in the ITS Central Station Accountability / CriticalNon-repudiation5.2 Access to key material and certificates Accountability / MinorNon-repudiation5.3 Repudiation <strong>of</strong> message transmission and receipt Accountability /Non-repudiationMajorTable 1.1: Different threats in a VANET, the respective threatened security goal and assessed severity asidentified in [39].1.5 Related WorkIn this section other works are presented that consider position forging attacks. First, a model <strong>of</strong> anattacker that performs position forging attacks is introduced. In a next step results <strong>of</strong> simulations <strong>of</strong> suchattacks are presented. Finally, approaches are introduced that can be used to detect position forgingattacks and thus mitigate their impact.1.5.1 A model <strong>of</strong> a roadside attackerIn [22] a model <strong>of</strong> an attacker is established that performs position forging attacks in a VANET. In abasic VANET model the attacker is categorized in terms <strong>of</strong> intention, type and four attack classes arepresented that could be performed by position forging. As for the system model a basic VANET withoutcertificates is assumed in which the vehicles communicate using only single-hop communication ona single channel. Furthermore, it is assumed that consistency checks and plausibility checks can beperformed upon reception <strong>of</strong> a message. In the most basic assumption messages with a timestamp in thefuture are discarded as well as messages the are too old. As for the included position it is checked atleast whether the position lies within the communication radius <strong>of</strong> the receiver.Based on this system model three general threats are identified: Distribution <strong>of</strong> wrong or forged messages,disturbance or unavailability <strong>of</strong> the communication system and tracking and pr<strong>of</strong>iling <strong>of</strong> vehiclesor vehicle drivers.25

CategoryElapsed timeExpertiseKnowledgeOpportunityEquipmentRequiredattack potentialAssessmentNot more than one week.Pr<strong>of</strong>icient: Familiar with the security behavior <strong>of</strong> the product or system type.Public: Knowledge that is publicly available.Unnecessary: No risk <strong>of</strong> being detected during the access.Specialized: Acquirable without undue effort.BasicTable 1.2: Assessment <strong>of</strong> the threat <strong>of</strong> injecting false messages into the communication system. [32]The following three types <strong>of</strong> attackers are assumed:• Road-side attacker: The attacker uses a compromised communication system or a laptop to distributeforged messages. It is assumed that this attacker’s intention is to harm the system or to gainfinancial benefit.• Driver: This attacker forges positions to obtain free roads for himself. A vehicle with a faultycommunication system also falls into this category.• Infrastructure-based attacker: This type <strong>of</strong> attacker aims at gaining access to the network inorder to collect mobility data. This way he could derive traffic patterns.A risk analysis leads to the assumption that the roadside attacker is seen as posing the highest riskto the system. This type <strong>of</strong> attacker is located near the road or on a bridge and might use a laptop tointroduce wrong safety messages into the system. By doing so he aims at misleading vehicles into wrongdriving maneuvers trying to maximize the damage done to the system. The following four categories <strong>of</strong>position forging attacks are identified.511532413534242(a) Using a single node ID(b) Using two different node IDsFigure 1.3: Random position forging. Numbers and shapes indicate sequence and node ID <strong>of</strong> the forgedposition respectively.261. Forge single positions: This type <strong>of</strong> attack is assumed to be the most basic a roadside attackercould perform. By always using the same node ID the attacker forges random positions not takinginto account the consistency <strong>of</strong> subsequent positions or the road layout.2. Forge multiple positions with different node IDs: In contrast to the first category, here theattacker changes the node ID for each forged message that he transmits. It is assumed that theattacker also makes sure that subsequent positions do not overlap.

3. Forge movement path <strong>of</strong> a single node: When forging a movement path the attacker makessure that subsequently sent out positions represent a consistent movement path <strong>of</strong> a vehicle. Thismeans that the attacker has to choose positions according to a vehicle’s boundaries with respect tochanges in acceleration, heading and speed.4. Forge multiple movement paths with different node IDs: Finally, the attacker could forge paths<strong>of</strong> multiple vehicles at the same time. In this case the attacker is able to simulate more complextraffic situations like traffic jams which could mislead other drivers.5 4 3 2 11 2 3 4 51 2 3 4 5(a) Using a single node ID(b) Using two node IDsFigure 1.4: Movement path forging. Numbers and shapes indicate sequence and node ID <strong>of</strong> the forgedposition respectively.Apart from attack category attacks are additionally distinguished by the type <strong>of</strong> position material that theattacker has access to as well as the scope <strong>of</strong> the attacks. As for the position material it is distinguishedbetween static and dynamic material. Static refers to positions that are guessed or calculated using theattacker’s position not taking into account the current traffic situation. Replayed positions from othervehicles are also counted to this category.As for the scope <strong>of</strong> the attacks it is distinguished between unlimited and bounded. In the former case,the attacker does not take into account the distance between his own position and the forged positions.In the latter case, the attacker only forges positions that do not exceed a certain distance to his ownposition.For the assessment <strong>of</strong> the presented attacks combinations within the named dimensions are consideredand the needed effort to perform the attack is assessed as well as its success probability. For attacksaiming at influencing event-driven applications an attack that uses a single ID, static position materialand bounded scope is considered as the most probable. Event-driven applications only need to accept onewrong message in order to possibly display wrong warning messages. As long as the forged positions areconsidered valid i.e. are on the road the success probability <strong>of</strong> such attacks is given. The main problem isseen in the inconsistency between subsequent positions. If only vehicles check for such inconsistencies,these attacks could be detected quite easily. This also does not change in case the attacker uses multiplenode IDs. The motivation <strong>of</strong> an attacker performing such attacks could be rather low e.g. just for fun.<strong>Attack</strong>s that simulate one or more movement paths are seen as having a significantly higher successprobability. This is because in the ideal case other vehicles would not detect any inconsistencies in thesubsequently received positions. Furthermore, if the attacker is able to dynamically forge positions inaccordance to the current traffic situations, this further increases the possible impact <strong>of</strong> such attacks.With attacks that simulate movement paths it becomes possible to also influence cooperative awarenessapplications. That is, applications that evaluate several subsequent messages in contrast to only onesingle message. With increasing number <strong>of</strong> simulated paths a linearly increasing effort is assumed mainly27

due to the necessity <strong>of</strong> consistency <strong>of</strong> the simulated paths with each other as well as with real vehicles.But on the other hand the attack abilities are also considered to increase. A significant attraction <strong>of</strong> suchattacks is thus stated since whole traffic situations like traffic jams could be simulated. For this reasonattackers are assumed to be pr<strong>of</strong>it-oriented or malicious.Using a laptop with wireless communication capabilities is assumed as the easiest way for an attackerto introduce false messages into the system. However, depending on the actual communication protocolsin use, a significant effort has to be made by the attacker to comply with these protocols. Otherwise hewould not be accepted as a valid communication partner and thus not be able to perform his attacks. Inour system model it is assumed that the attacker is able to manipulate the on-board system <strong>of</strong> a vehicleto accept his wrong messages. Clearly, the manipulation <strong>of</strong> the existent communication equipment mayalso need significant knowledge by the attacker. On the other hand one can not eliminate the probability<strong>of</strong> implementation flaws or security holes that may allow an attacker to access the on-board system insuch a way. Once the attacker is able to introduce his messages into the on-board system <strong>of</strong> the vehicle,the communication system would behave according to the needed communication protocol but usingthe wrong data produced by the attacker.When successfully manipulating an on-board system in the described way also the credentials as wellas embedded certificates would be used by the compromised vehicle to sign the attacker’s messages.In contrast to the presented work, in this work therefore a VANET is assumed in which certificatesare indeed used during the communication. By doing so, using the classification <strong>of</strong> attack types onlyattacks with a single ID can be performed. More specifically an attack is assumed that simulates a singlemovement path using a single node ID. A more detailed description <strong>of</strong> the attacker model used in thiswork can be found in Chapter 3.1.5.2 Simulations <strong>of</strong> position forging attacksIn a next step works will be presented that have performed position forging attacks in simulation environmentsin order to evaluate the impact <strong>of</strong> such attacks on the behavior <strong>of</strong> other drivers and trafficflow.In [15] the previously described categorization <strong>of</strong> attacks is used to simulate either random positionsor consistent movement paths. As simulated road scenario a highway <strong>of</strong> 10 km in length and withmultiple lanes in both directions is used with 150 vehicles present in the simulations. In order to assessthe impact <strong>of</strong> the attacks on the traffic flow mainly the the number <strong>of</strong> packet collisions as well as theaverage speed <strong>of</strong> vehicles are used as metrics. Several simulation runs were performed with increasingnumber <strong>of</strong> attackers <strong>of</strong> one to 20 and each time the number <strong>of</strong> used faked IDs was increased from one t<strong>of</strong>ive.In simulations without attackers present the amount <strong>of</strong> packet collisions is stated as being approximately5 %. For each simulated number <strong>of</strong> attackers, the amount <strong>of</strong> packet collisions increases significantlyfrom about 10 % with one simulated node ID to about 60 % with two simulated node IDs.With further increasing number <strong>of</strong> simulated node IDs the amount <strong>of</strong> packet collisions did then onlyincrease slightly more. These progressions are very similar in case the attackers simulated movementpaths instead <strong>of</strong> random node positions.As for the impact <strong>of</strong> random position forging on the average speed <strong>of</strong> vehicles the speed decreasesfrom values between 45 km/h and 65 km/h for one simulated node ID down to values between 10 km/hand 35 km/h for 5 simulated node IDs depending on the number <strong>of</strong> attackers. Again, for path forgingsimilar progressions can be seen with an average vehicle speed <strong>of</strong> 52 km/h to 75 km/h for one simulatednode ID decreasing down to values between 21 km/h and 39 km/h for five simulated node IDs.First <strong>of</strong> all, the usefulness <strong>of</strong> packet collisions as a metric to evaluate position forging attacks is questionabledue to the fact that for packet collisions it is irrelevant which data is present in the sent messages.Also, the increase in packet collisions should be obvious since more messages are sent with an increasein number <strong>of</strong> attackers and simulated node IDs. Also, the similar results for forged positions and forged28

movement patch with respect to packet collisions can be explained with the fact that the amount <strong>of</strong>packet collisions is independent from the actual data. However, the results show that the availability <strong>of</strong>the C2X communication channel can be decreased significantly by such attacks.As for the results concerning the average vehicle speed it is not described how drivers react whentraffic congestions are simulated by an attacker. It is supposed that in the presented work it has beenassumed that drivers regard all the received messages containing wrong data as valid and react accordingly.In reality it is thinkable though that drivers recognize false warning messages and only slow downfor a short period.Also in [3] simulations <strong>of</strong> position forging attacks are performed. In this work it is evaluated to whatextend traffic can be slowed down with these attacks in dependence <strong>of</strong> rate <strong>of</strong> vehicles that are equippedwith C2X devices and thus receive the warning messages. The following three attack scenarios areconsidered:1. Single-lane Road: In this scenario a stationary attacker sends faked warning messages simulatinga hazard on a single lane road. It is assumed that vehicles without C2X equipment are not able toovertake vehicles slowing down because <strong>of</strong> warning messages.2. Multi-lane Highway: Here, the attacker is driving himself and again is sending out warning messagesabout a road hazard in his vicinity. In this case fast drivers are able to overtake vehicles thatare slowing down.3. Sybil <strong>Attack</strong>: In this scenario, the attacker uses various node IDs for the sent out warning messagesin order to simulate a traffic congestion on a multi-lane highway. Again, faster vehicles mayovertake vehicles that are slowing down.In contrast to [15], here two different driver types are distinguished with respect to how they reactupon reception <strong>of</strong> a warning message and compare the results <strong>of</strong> respective simulation runs. In thefirst case a driver reduces his speed down to 8 m/s and keeps this speed until the end <strong>of</strong> the simulatedarea. In the second case the speed is also reduced to 8 m/s but only for a distance <strong>of</strong> 250 m. It isstated that in a realistic scenario drivers as well would increase speed again once they realize that thereceived warning message was wrong. Clearly, only vehicles equipped with C2X devices are reacting tothe warning messages. By slowing down they may then in turn slow down other vehicles without C2Xdevices.In case <strong>of</strong> the first scenario <strong>of</strong> a single-lane road the results show a clear dependency <strong>of</strong> the assumedbehavior <strong>of</strong> warned drivers. With 20 % vehicles equipped with C2X devices the mean travel time <strong>of</strong> vehiclesalready increases by 7 % for temporary speed reduction up to 18 % for permanent speed reduction.These values increase with increasing rate <strong>of</strong> equipped vehicles obviously reaching its maximum in caseall the vehicles are equipped. When all <strong>of</strong> the vehicles are equipped with C2X devices traffic delay isincreased for more than 13 % with temporary speed reduction and more than 23 % with permanentspeed reduction.The second and the third scenario show similar results. Since in both scenarios it is assumed that notwarned vehicles can overtake vehicles slowing down the vehicles without C2X devices are almost not affectedand thus a linear increase in travel time can be observed with increasing percentage <strong>of</strong> equippedvehicles. In case all <strong>of</strong> the vehicles react to the wrong messages the mean travel time is increased byabout 30 % when reducing speed temporary and by about 70 % when reducing speed permanently. Thissignificant difference between the two respective driver behavior models can be seen in all <strong>of</strong> the performedsimulation runs.In conclusion the results show that the impact <strong>of</strong> position forging attacks depends heavily on thebehavior <strong>of</strong> the drivers that receive those messages. Thus it is hard to precisely assess the impact <strong>of</strong> such29

attacks in simulations. This is due to the fact that every driver in a real situation might react slightlydifferently which is hard to transfer into a realistic simulation model.Also, it can be seen that the traffic situation considerably influences the impact <strong>of</strong> such attacks. As theresults <strong>of</strong> the second and third scenario show, the impact <strong>of</strong> a position forging attack is much lower incase vehicles that were not warned are able to just overtake vehicles slowing down on a highway. Thus,it would be more attractive for attackers to perform such attacks in areas with dense traffic like cities.Here, many vehicles may be affected in case just a single vehicle reacts to a wrong warning message.As a result, also with a relatively low rate <strong>of</strong> equipped vehicles position forging attacks may have a highimpact on the traffic flow in such areas.1.5.3 Defense mechanisms against position forging attacksAfter having introduced a model <strong>of</strong> a roadside attacker and presenting results <strong>of</strong> simulations that evaluatedcorresponding attacks, in the following, approaches are introduced to detect such attacks.Minimum Distance MovedIn [33] and [21] an approach called Minimum Distance Moved (MDM) is presented for the detection<strong>of</strong> stationary position forging attackers as described in Section 1.5.1. The approach makes use <strong>of</strong> thefact that the communication range <strong>of</strong> vehicles is limited. By additionally taking into account its ownmovement, a vehicle can thus determine whether another vehicle with a certain node ID must havemoved between the sending <strong>of</strong> two messages. An exemplary situation is depicted in Figure 1.5. Here, theshown vehicle received two messages from the same node ID at times t1 and t2. Since the transmissionradiuses <strong>of</strong> these two points in time overlap, it is still possible that the messages were sent by a stationaryattacker that is located within the overlapping area <strong>of</strong> the two radiuses. In case the vehicle receivesanother message from that node ID when its transmission radius does not overlap with r1 the receivercan be sure that the messages were not sent by a stationary attacker. While this approach works well toprevent position forging attacks from stationary attackers, there is also a drawback. In order to trust eachother, the two vehicles have to drive within their respective communication range for a certain time. Thismeans that vehicles might falsely discard warnings received from recently new detected vehicles. Also,the attacker could increase his transmission range with additional equipment. In this case, the attackercould be assumed moving because the other vehicles assume a smaller communication range.To mitigate these shortcomings two improvements <strong>of</strong> the approach are presented. The first improvementmakes use <strong>of</strong> transitive trust and aims at reducing the average evaluation time needed to determinewhether a certain vehicle can be trusted. In this approach, vehicles inform their neighbors which vehiclesr2r1t1t2Figure 1.5: Minimum Distance Moved: Vehicle positions at reception times t1 and t2 <strong>of</strong> two messagesfrom the same nodeID and respective transmission radiuses.30

are trustworthy. Vehicles that receive such information will in turn only trust this information in casethey already trust the sender. By doing this, vehicles can directly trust newly detected neighbors in somesituations, reducing the average evaluation time. An example for this is a situation <strong>of</strong> two vehicles Aand B driving behind one another (A in front) on a highway that are trusting each other. When now aslightly faster vehicle C is overtaking from behind and is trusted by vehicle B, vehicle A will get informedthat vehicle C is trustworthy.The second improvement aims at detecting attackers that were somehow able to increase their communicationrange in order to appear as a moving vehicle. To be able to detect this, a regular exchange<strong>of</strong> neighbor information with other vehicles nearby has to be done. This way each vehicle knows whichother vehicles can be seen by a certain neighbor. In case a vehicle receives a message with a position thatexceeds its communication range this is an indication for a forged position. Thus, the vehicle can theninform its neighbors about this. When such a situation is detected, all vehicles increase the distance thesuspicious node has to move before it is assumed to be a moving vehicle.The described approach is only aimed at securing cooperative awareness applications from attacks.Applications with event-triggered warning messages, like a warning about a broken-down vehicle, cannot be secured using this approach. One could suppose that it is more attractive for an attacker tosimulate event-triggered warnings anyway since no path forging should be necessary.An other shortcoming <strong>of</strong> the presented approach is that an attacker could just perform his attackswhile driving a vehicle. When starting an attack, the attacker could first simulate valid positions nearhis own position for some time in order to be trusted by his neighbors. Then, he could start his attackswhich would probably not be detected by the victims. However, the attacker is limited to victims thatdrive in the same direction as himself since he needs to stay within communication range with his victimfor some time in order to be trusted by the victim.Finally, the presented improvements transitive trust and the exchange <strong>of</strong> neighboring informationonly work effectively in case the node density is high enough. Thus, they might not work during thedeployment phase or on rural roads with low traffic.Radar-Pro<strong>of</strong>ed PositionThe approach <strong>of</strong> proving positions by using local Radar systems is presented in [34]. The local radarsensor is used in order to check the correctness <strong>of</strong> positioning data <strong>of</strong> received C2X messages. When aC2X message is received from a nearby vehicle, the distance and direction to that vehicle are calculatedbased on the contained data. Then, these values are compared with the data measured by the local radarsensor. This approach is only applicable if the other vehicle is in direct line <strong>of</strong> sight since the radar sensormeasures the distance to the next obstacle. Furthermore, it is restricted to vehicles that are relativelynear since the maximum detection range <strong>of</strong> the radar sensor is limited.Sudden Appearance WarningIn [34], an approach is described that warns about suddenly appearing vehicles. For this approachthe first received message from a neighbor is evaluated. Under normal circumstances this message willcontain a position at the edge <strong>of</strong> the transmission range <strong>of</strong> the own vehicle. If the first message receivedfrom a neighboring car contains a position directly in front <strong>of</strong> the own vehicle, this can be seen as anindication for a forged position. However, also under normal conditions appearances <strong>of</strong> near vehiclesmay occur in case the C2X communication range is reduced due to obstacles for example. Thus, a certainrange <strong>of</strong> tolerance should be applied or the results could be verified using further approaches.31

2 <strong>Analysis</strong> <strong>of</strong> <strong>Attack</strong> <strong>Methods</strong>As seen in Section 1.4, the dissemination <strong>of</strong> messages with false location and mobility data i.e. positionforging is commonly considered to pose the highest risk to a VANET. That is why only those attacksare further examined in this chapter. First, different methods are considered how an attacker could puthimself into a position that would allow him to inject false messages. After that, criteria are introducedthat can be used to analyze these methods mainly in terms <strong>of</strong> attacker effort. Finally, the analysis <strong>of</strong>the attack methods is done using the defined criteria. This way a notion is established <strong>of</strong> which attackmethods are to what extent feasible and attractive for an attacker.2.1 <strong>Attack</strong> <strong>Methods</strong>In this section the different methods are explained that could be used by an attacker in order to injectfalse messages into the system.• Modify CCU s<strong>of</strong>tware: One method that would enable an attacker to inject false messages wouldbe to manipulate the s<strong>of</strong>tware that is executed on the CCU. For this reason the attacker could forexample use a CCU from an old or stolen car. In case the compromised CCU still holds a set <strong>of</strong> validcryptographic credentials (i.e. keys and certificates) the attacker could try to inject messages intothe network layer <strong>of</strong> the CCU. Thus, the attacker could send out messages with false data withinthe C2X payload data section and the network data section.• Modify AU s<strong>of</strong>tware: In this method the attacker manipulates the AU so that arbitrary messagescan be created and forwarded to the facilities layer <strong>of</strong> the communication stack running on theCCU. On the one hand the attacker could try to change one <strong>of</strong> the applications using reverseengineering. On the other hand the attacker could inject a malware into the AU that would thenexecute the attacks. This method would allow an attacker to send out messages with false datawithin the C2X payload data section.• Use Laptop: In this method the attacker would not manipulate any devices <strong>of</strong> the C2X system butinstead only use a laptop in order to inject arbitrary messages. Therefore the attacker needs to beable to send and receive messages on the same frequencies that are used in the VANET. In order toensure that the laptop generated messages are accepted by other vehicles the attacker needs to getaccess to valid certificates. As in the first method the attacker could set messages with false datawithin the C2X payload data section and the network data section.2.2 Assessment CriteriaIn the following the criteria is listed that are used in Section 2.3 to assess the attack methods introducedin Section 2.1. The criteria is based on [32]. Using these criteria a comparison <strong>of</strong> the attack methods interms <strong>of</strong> attractiveness for the attacker is performed.• Time: This denotes the time that is required by the attacker to analyze the system environmentand implement the attack. In contrast <strong>of</strong> estimations <strong>of</strong> the needed time the different methods arecompared to each other and assigned an assessment from medium to high.• Knowledge: This denotes the knowledge <strong>of</strong> the system that the attacker must have in order tosuccessfully implement the attack.33

• Access: This is the extent to which the attacker needs access to the system under attack. In case <strong>of</strong>manipulations this includes the extend <strong>of</strong> the needed manipulation.• Potential impact: This criterion denotes the amount <strong>of</strong> potential impact on the system i.e. whichattacks become possible with the respective attack method.2.3 Assessment <strong>of</strong> <strong>Attack</strong> <strong>Methods</strong>Modify CCU s<strong>of</strong>tware Modify AU s<strong>of</strong>tware Use LaptopTime high medium very highKnowledge very high high very highAccess high high highPotential impact very high high very highTable 2.1: Different attack methods and their assessment in terms <strong>of</strong> various criteria.The assessments <strong>of</strong> the different attack methods using the introduced criteria are shown in Table 2.1.The following paragraphs elaborate on these assessments.1. Manipulate CCUAs described in Section 1.2.3, the CCU implements the C2X communication functionality. This istypically done using low level programming languages because <strong>of</strong> high performance requirements. Anattacker that wants to manipulate the CCU for his attacks therefore needs to analyze these implementationsin order to be able to inject own messages. Furthermore, it is possible that the management layerruns watchdog modules to prevent such intrusions. If this is the case an attacker additionally needs tocircumvent these functions. In case the attacker needs to manipulate further layers the required timeincreases accordingly. In comparison with other attack methods the time needed by the attacker toimplement such modifications <strong>of</strong> the CCU s<strong>of</strong>tware is therefore rated as high.The amount <strong>of</strong> knowledge required by the attacker is rated as very high in accordance to the effortfor CCU manipulation. The attacker needs to have deep insights into the implementations <strong>of</strong> the variouslayers within the CCU. The attacker will need knowledge about the implemented security mechanismsthat try to prevent unauthorized CCU s<strong>of</strong>tware modifications.In terms <strong>of</strong> the required access needed to implement the attack the attacker first needs a CCU that hecan use for the attack. For this the attacker could use his own car or use a stolen one. With a stolen carthe long term certificate could not be tracked back to the attacker. The CCU <strong>of</strong> the stolen car also has avalid certificate that the attacker can then use until it is revoked. Once the attacker is in possession <strong>of</strong>a CCU with valid certificates he needs to manipulate the s<strong>of</strong>tware <strong>of</strong> the CCU in order to send his falsemessages. The amount <strong>of</strong> access needed is rated as high.As soon as the attacker was able to find a way to inject own messages into the network layer <strong>of</strong> theCCU he will be able to change the data <strong>of</strong> the C2X payload data section and the network data section <strong>of</strong>sent out messages. This would allow the attacker to perform his attacks even if for example the securitylayer performs consistency checks <strong>of</strong> network layer and application layer position data. In the generalcase, the security layer only uses one certificate for all <strong>of</strong> the sent out messages. In the system that isused for this work the certificate <strong>of</strong> messages is not used to determine the sender <strong>of</strong> a message. Thus,the attacker is able to perform attacks <strong>of</strong> all <strong>of</strong> the attack categories introduced in Section 1.5.1. In casesuch a check <strong>of</strong> the certificate would be done the attacker would be limited to attacks using only onenode ID. In conclusion, the potential impact <strong>of</strong> this attack method is rated as very high.34

2. Manipulate AUWhen compared to manipulating a CCU, it is assumed that less time to implement the attack is neededwith this method. This is due to the fact that implementation <strong>of</strong> the applications will maybe done withuser-oriented programming languages to help third parties to develop own applications. The requiredtime for analyzing the behavior is thus assumed to be shorter. The attacker could use higher levelprogramming tools during his attack. Therefore the required time for this attack method is assessed asmedium.The required knowledge by an attack to perform this method is assessed as high. It is assumed thatless hardware-related and detailed knowledge is needed compared to the CCU manipulation. This isbecause the applications running in the application layer will probably use user oriented methods to sendand receive messages which may be defined in a public API. Still, the attacker will need considerableknowledge about how new applications can be installed on the AU. If functionality <strong>of</strong> the managementlayer supervises processes like installation <strong>of</strong> new s<strong>of</strong>tware or the behavior <strong>of</strong> applications the attackerwill need knowledge about this.Similar to the modification <strong>of</strong> CCU s<strong>of</strong>tware, the attacker first needs to get access to a functioning pair<strong>of</strong> AU and CCU with valid certificates. Thus, the attacker may again need to steal these devices from avalid vehicle. When having access to the devices the attacker only needs access to the application layer<strong>of</strong> the AU. Since it is probably harder to modify existing applications by reverse engineering them, itcould be more attractive for the attacker to implement an own bundle that performs the attacks andthen introduce it into the application layer. Maybe the attacker could exploit existing functionality forinstalling new applications. Although no access to the CCU is needed. Nevertheless, the amount <strong>of</strong>access needed for this method is still rated as high as the AU has to be manipulated.The potential impact <strong>of</strong> this attack method is rated as high. However, in this method the attacker isnot able to modify the CCU s<strong>of</strong>tware (i.e. data <strong>of</strong> the facilities layer, network layer or security layer). Theattacker is restricted to possible boundaries in terms <strong>of</strong> maximum send frequency that are specified forall applications. In the system assumed for this work no consistency checks <strong>of</strong> network and applicationlayer data are done. Furthermore, the consistency between the node ID set in the application layer dataand the certificate <strong>of</strong> the message is not checked. This means that the attacker can perform attacks <strong>of</strong> all<strong>of</strong> the four attack categories. With a consistency check <strong>of</strong> the node ID the attacker would be limited toattacks using a single node ID. In case the positions set by the application layer and the network layerwould be checked for consistency, all <strong>of</strong> the attacks could be detected.3. Use LaptopWhen using a laptop to perform attacks the attacker does not use existing devices <strong>of</strong> vehicles orRSUs that implement certain functionality. Therefore the attacker has to implement almost all <strong>of</strong> thefunctionality <strong>of</strong> the CCU and additionally the functionality <strong>of</strong> the AU. Therefore he would have to performan extensive study <strong>of</strong> the specifications and documentations in order to gain the required knowledge.Since the attacker does not use a CCU with a valid certificate the attacker additionally needs to extracta certificate from a CCU. This requires a lot <strong>of</strong> time. In conclusion, the required time for this methodis rated as very high. For similar reasons the knowledge required by the attacker is rated as very high.He will need to have extensive knowledge <strong>of</strong> the used communication protocols. In order to be able toextract certificates he needs to know the applied methods that are used to protect these.In this method no access to existing devices is needed to inject false messages into the VANET. Still, therequired access is assessed as high. This is because the attacker needs to get access to valid certificates.It is assumed that the attacker needs extensive access to a security subsystem <strong>of</strong> a CCU for extracting it.Once the attacker is in possession <strong>of</strong> one or more valid certificates he only needs a laptop that is able tocommunicate on the same frequency as vehicles and RSU <strong>of</strong> the VANET.It is assumed that the attacker somehow found a way to extract a valid certificate from a CCU. Once heknows how to do this, he will be able to extract the certificates from multiple CCUs. The attacker couldarbitrarily use different certificates for his sent out messages. This way, even if the consistency <strong>of</strong> the35

node ID and the certificate is checked the attacker could perform attacks with multiple node IDs. Sincethe attacker is able to set data <strong>of</strong> the application layer as well as the network layer consistency checks<strong>of</strong> this data would not be able to detect the attacks. In the system assumed for this work the attacker isable to perform attacks from all <strong>of</strong> the four attack categories. The potential impact <strong>of</strong> this attack methodis rated as very high.ConclusionOne can see that for the system assumed for this work all <strong>of</strong> the presented attack methods enable anattacker to perform attacks <strong>of</strong> all <strong>of</strong> the four attack methods introduced in Section 1.5.1. As a consequencean attacker would probably choose to manipulate the s<strong>of</strong>tware <strong>of</strong> the AU since this requires theleast amount <strong>of</strong> effort in terms <strong>of</strong> time and knowledge. If a system is assumed that applies consistencychecks <strong>of</strong> the application layer data and the network layer data the manipulation <strong>of</strong> the s<strong>of</strong>tware <strong>of</strong> theAU would no be sufficient to perform any <strong>of</strong> the attacks. This is because the attacker is not able to setthe data <strong>of</strong> the network layer. Hence, the attacker would have to manipulate the CCU s<strong>of</strong>tware <strong>of</strong> use alaptop for his attacks. For the remainder <strong>of</strong> this work it is therefore assumed that an attacker would tryto manipulate the AU in order to send false messages.36

3 System ModelAs seen in Chapter 2, it is the easiest for an attacker to manipulate the AU in order to be able to performposition forging attacks. Considering the different applications that could be attacked, the group <strong>of</strong>safety applications is attractive for an attacker since the attacker may be able to influence the drivingbehavior <strong>of</strong> other vehicles. In this work an attacker is implemented that attacks the EBL application [11].In Section 3.1 the application layer based EBL attacker concept is described in detail. Subsequently, inSection 3.2, the implementation <strong>of</strong> the attack is explained.3.1 ConceptApplicationsMalwareAUMAFASAManagementMFMNMIFacilitiesNFNetwork &TransportINAccessSFSNSISecurityCCUMSFigure 3.1: ITS station architecture with malware introduced into the application layerIn the concept it is assumed that the attacker is able to introduce a malicious application into the AUthat performs the attacks while the station is operated. Figure 3.1 shows the layer structure <strong>of</strong> a stationwith the introduced malware. Once the malware is successfully integrated it is able to use the servicesprovided by the facilities layer to send and receive messages.It is assumed that the attacker uses a vehicle with valid certificates stored in the security layer. Thismeans that the malicious messages are signed with a valid certificate and therefore will be consideredas valid by receiving vehicles. The attacker aims to fake braking maneuvers in order to trigger a victimvehicle to display a false warning to the driver. As described in Section 1.5.1 the most simplistic approachwould be to just send out single DENMs with varying positions that each indicate an emergency brakingmaneuver. However, the success probability <strong>of</strong> this approach is limited. First, it is not made sure thatthe faked braking maneuvers lie in the driving path <strong>of</strong> other vehicles. Second, the sent out messagesdo not represent a consistent movement path. This means that other vehicles could easily detect thesewrong messages by performing basic consistency checks <strong>of</strong> the received positions. Due to these reasonsthe attacker sends out both CAMs and DENMs that represent a consistent movement path including anemergency braking maneuver. This way it is much more difficult for other vehicles to detect the attacks.Furthermore, the attacker is able to suppress the regularly sent out CAMs that contain the real position<strong>of</strong> the attacker vehicle. Additionally, for each attack a certain victim is selected. By processing data37

available in the neighborhood table the malware evaluates the movement <strong>of</strong> nearby vehicles and thensimulates a braking maneuver directly in front <strong>of</strong> the most attractive victim.As described in Section 1.2.3, the different architectural layers are strictly separated from each other.Since the attacker’s malware is running within the Applications Layer, it is only able to set the data <strong>of</strong> thecorresponding C2X payload data section <strong>of</strong> sent out messages. As a consequence, sent out messages withfaked positions within the C2X payload data section still contain the real position <strong>of</strong> the attacker withinthe network data section <strong>of</strong> the messages. This data is set when the message is processed by the networklayer implemented on the CCU. However, since the assumed system does not perform consistency checks<strong>of</strong> the data <strong>of</strong> different message sections, these inconsistencies are not detected. The application underattack will exclusively use the data within the C2X payload data section and therefore process the falsedata set by the attacker’s malware.In Section 3.1.1 the functioning <strong>of</strong> the application under attack is described. After that, the process<strong>of</strong> choosing the most attractive victim having several neighbors is shown in Section 3.1.2. Finally, thesimulated driving maneuver is described in Section 3.1.3 and an overview <strong>of</strong> the attacker parameters isgiven in Section 3.1.4.3.1.1 EBL application„Panic Braking“αFigure 3.2: Illustration <strong>of</strong> the EBL application. When the blue car receives a warning message from a hardbraking car within its relevance sector (outlined as blue triangle <strong>of</strong> length l and angle α) itshows a warning to the driver.The EBL application is used as the target <strong>of</strong> the attacks. The functioning <strong>of</strong> the application is illustratedin Figure 3.2 and the main parameters are listed in Table 3.1. The EBL application <strong>of</strong> the blue victimvehicle evaluates all incoming DENMs that represent a braking maneuver. When such a message isreceived, it is first checked whether the event lies within the geographically relevant sector <strong>of</strong> the vehicle.This sector in front <strong>of</strong> the vehicle is outlined in blue in Figure 3.2. By default, the relevance sector hasan angle <strong>of</strong> 90 ◦ and a length <strong>of</strong> 400 m. If the event occurred within this sector the heading differencebetween the own car and the braking car is calculated. Only if the heading difference is 45 ◦ or less theevent is considered as relevant. By performing this check, DENMs from braking cars on crossing roads orcars driving in the opposite direction are ignored. Apart from the heading, the intensity <strong>of</strong> the brakingmaneuver is also taken into consideration. Only considerable hard braking vehicles with a minimum38l

absolute intensity <strong>of</strong> 3.92 m/s 2 are relevant to the EBL application. Finally, the speed <strong>of</strong> the own vehiclehas to be at least 9 m/s. This prevents slow or standing vehicles from displaying warnings.If all <strong>of</strong> these conditions are met a message is shown to the driver. The EBL application distinguishesbetween an information and a warning for low and high degree <strong>of</strong> danger, respectively. Alongside withthe warning message also a warning tone is generated in order to catch the attention <strong>of</strong> the driver. Thedegree <strong>of</strong> danger which determines the type <strong>of</strong> displayed information or warning to the driver is in turndetermined by the so-called time to crash (TTC) value which represents the time until a collision wouldhappen if the driver does not react, i.e. start braking. The TTC value is calculated as shown in Equation3.1.t tc bo = dist bov b − v o(3.1)The variable v b and v o are the speeds <strong>of</strong> the braking car and the own car and the parameter dist bodenotes the distance between the two cars. If t tc bo has a value <strong>of</strong> at least 5 s the information is displayedand if t tc bo is smaller than 5 s the warning is shown together with the warning tone.In addition to showing a notification to the driver upon reception <strong>of</strong> the DENM, the EBL applicationalso starts a tracking <strong>of</strong> the braking car. This means that from this moment on all further CAMs andDENMs from the tracked node are used to regularly update the TTC value. In case the driver <strong>of</strong> the owncar does not slow down and the TTC value decreases under the threshold <strong>of</strong> 5 s, an additional warningis displayed. This way, the driver is informed that the danger <strong>of</strong> a collision has risen and that immediateaction should be taken.Name Unit ValueLength <strong>of</strong> relevance sector m 400Angle <strong>of</strong> relevance sector◦90Maximum heading difference◦45Threshold for brake intensity m/s 2 3.92Threshold for vehicle speed m/s 9TTC threshold for warning type s 5Table 3.1: Main parameters <strong>of</strong> the EBL application.3.1.2 Choosing <strong>of</strong> a victimThe process <strong>of</strong> choosing a victim for an attack is shown in Figure 3.3. The objective <strong>of</strong> the victim selectionsequence is to maximize the damage that is done to the attacked station. In the first step the location andmobility data <strong>of</strong> all vehicles within single-hop communication range is retrieved from the neighborhoodtable. If the neighborhood table is empty no victim is in range for an attack and thus the process iscancelled. Otherwise the retrieved list <strong>of</strong> vehicles is filtered. As described in Section 3.1.1, vehiclesslower than 9 m/s do not display any EBL information or warning to the driver. Therefore these vehiclesare discarded from the list <strong>of</strong> potential victims. In the next step, for each vehicle in the list its remainingtime within the attacker’s communication range is calculated based on the current location and speed <strong>of</strong>both, the attacker and the victim. This way it is possible to discard vehicles that are probably leaving thecommunication range shortly and would therefore not display a warning to the driver because the attackcould not be fully executed. If no vehicles are present after the filtering, the process is canceled. In thiscase the process will be started again from time to time so that an attack is started once a potential victimis available. Otherwise, at least one vehicle is suitable for an attack an appropriate attack is started afterthe selection process is finished. If more than one potential victim is available they are considered usingthe following four preferences one after the other. This is done in order to perform an attack with themost potential damage.39

Request vehicles fromneighborhood tableNo vehicles inneighborhood tableNo attack possibleAt least one vehicle inneighborhood tableDiscard slow vehiclesDiscard vehicles leavingcommunication rangeNo vehiclesremainingAt least onevehicle remainingAt least oneconvoy present<strong>Attack</strong> biggestconvoyNo convoypresentStraight drivingvehicle present<strong>Attack</strong> straightdriving vehicleNo straight drivingvehicle presentFast vehiclepresent<strong>Attack</strong> fastestvehicleNo fastvehicle present<strong>Attack</strong> longest notattacked vehicleFigure 3.3: Process <strong>of</strong> choosing a victim to attack.40

ConvoysThe first preference concerns convoys. The notion <strong>of</strong> a convoy is that at least two vehicles are drivingin parallel e.g. on a highway or behind one another so that their relevance sectors, as introduced inSection 3.1.1, are overlapping. By attacking a vehicle <strong>of</strong> such a convoy the faked emergency brakingis relevant to several vehicles that all display a warning to their drivers at the same time. Thus, thepotential damage <strong>of</strong> a single attack is multiplied by the number <strong>of</strong> vehicles in the convoy. If at least oneconvoy is detected by the attacker, further preferences are not checked and an attack on the convoy withthe highest number <strong>of</strong> vehicles is started.Heading historyIf no convoys are detected, the past headings <strong>of</strong> potential victims are considered. The intention hereis to attack a vehicle that is driving on a straight path because this increases the success probability <strong>of</strong>the attack. When attacking a straight driving vehicle the faked emergency braking will probably fullybe performed within the relevance sector <strong>of</strong> the victim which leads to a driver warning. If the victimunder attack is driving through a possibly sharp curve it is likely that the faked maneuver is not in therelevance sector <strong>of</strong> the victim during the attack. This is reducing the probability <strong>of</strong> a driver warning. Asdescribed in Section 3.2, the module VictimTracker <strong>of</strong> the implementation keeps track <strong>of</strong> the headings<strong>of</strong> all neighbors in range. It is assumed that a vehicle that is driving on a straight path remains on thisstraight path for at least some minimum time. If such a vehicle is found in the list <strong>of</strong> neighbors it isselected as the next victim to attack and the selection process is terminated.SpeedIn case neither a convoy nor a straight driving vehicle are detected among the potential victims,vehicles are evaluated in terms <strong>of</strong> their current speed. This is done because it is assumed that an attackon a fast vehicle has a higher potential damage than an attack on a slow vehicle. In this work vehiclesare classified into fast vehicles with speeds above 120 km/h and slow vehicles with speeds <strong>of</strong> 120 km/hand below. If at least one <strong>of</strong> the neighboring vehicles is considered as fast, the fastest <strong>of</strong> these vehicles ischosen as the next victim to attack.Last attack timeIf no victim has been chosen yet, the times <strong>of</strong> the last performed attacks are considered. For thispurpose the node IDs <strong>of</strong> each attacked victim along with a timestamp are stored by the attacker. Thisway it can be evaluated whether a potential victim has already been attacked lately and how muchtime has passed since the last attack on a victim. By evaluating those stored attack times a victimis preferred that has not been attacked before. The idea behind this is that the driver <strong>of</strong> an alreadyattacked vehicle may meanwhile have realized that the warning was faked and may not react to furtherfaked notifications. If all <strong>of</strong> the available victims have already been attacked the victim that has not beenattacked for the longest time span is selected again.3.1.3 <strong>Attack</strong> sequenceIn this section the sequence <strong>of</strong> a single attack is described in detail. By setting the payload data <strong>of</strong>sent out CAMs and DENMs, the attacker that remains stationary by the road fakes a ghost vehicle thatperforms the following sequence which consists <strong>of</strong> three stages:• Stage 1: The ghost vehicle drives in front <strong>of</strong> the victim.• Stage 2: The ghost vehicle simulates an emergency braking maneuver.• Stage 3: Waiting that the victim passes the ghost vehicle.41

Figure 3.4: Beginning <strong>of</strong> the attack. The road side attacker in the red vehicle fakes a ghost vehicle (brightred) that is driving in front <strong>of</strong> the victim (blue) at half <strong>of</strong> the victim’s speed.The beginning <strong>of</strong> an attack (beginning <strong>of</strong> stage 1) is depicted in Figure 3.4. By setting the location andmobility data in his sent CAMs, the attacker fakes a ghost vehicle that is driving in front <strong>of</strong> the victim.During this first stage <strong>of</strong> the attack, no braking is simulated yet. The purpose <strong>of</strong> this stage <strong>of</strong> the attackis to simulate a plausible movement so that the victim accepts the ghost vehicle as a valid neighbor. Theduration <strong>of</strong> this attack stage is determined by the parameter preDENTimespan. The initial distance d initbetween the victim and the ghost vehicle depends on the victim’s speed v v and its parameters initialTTCand preDENTimespan and is calculated as shown in Equation 3.2.d init = (v v − v g ) ∗ (initialT T C + preDEN T imespan) (3.2)The speed <strong>of</strong> the ghost vehicle v g is initially set to half <strong>of</strong> the victim’s speed. Thus, the initial distancecan also be expressed as in Equation 3.3.d init = 1 2 ∗ v v ∗ (initialT T C + preDEN T imespan) (3.3)Figure 3.5: Beginning <strong>of</strong> stage 2 <strong>of</strong> the attack. The attacker (red) starts simulating the emergency braking<strong>of</strong> the ghost vehicle (bright red).The beginning <strong>of</strong> stage 2 is shown in Figure 3.5. The distance that the victim has traveled up to nowcan be calculated with Equation 3.4.d preDEN = v v ∗ preDEN T imespan (3.4)The distance between the victim and the ghost vehicle at this time is calculated with Equation 3.5.d DEN = 1 2 ∗ v v ∗ initialT T C (3.5)42

At this point <strong>of</strong> the attack, the simulation <strong>of</strong> the emergency braking <strong>of</strong> the ghost vehicle starts. Theattacker sends out a DENM <strong>of</strong> the type “panic braking” and the following CAMs also contain the mobilitydata <strong>of</strong> a braking vehicle. The intensity <strong>of</strong> the simulated braking maneuver is set by the parameterbrakeIntensity. The duration and the distance <strong>of</strong> the braking maneuver can be calculated with equations3.6 and 3.7.v gt b =(3.6)brakeIntensit yd brake = 1 2 ∗ brakeIntensit y ∗ t2 b(3.7)Because <strong>of</strong> the described value for d init , upon reception <strong>of</strong> the DENM the victim calculates the timeto crash value exactly as set by the parameter initialTTC. Depending on this value, a warning or aninformation about the braking ghost vehicle is displayed to the victim’s driver. In Figure 3.6 the end <strong>of</strong>Figure 3.6: Beginning <strong>of</strong> stage 3 <strong>of</strong> the attack. The ghost vehicle (bright red) is now simulated as standingat a fixed position until the victim (blue) passes it.the braking <strong>of</strong> the ghost vehicle is shown. From this point on, the ghost vehicle is simulated as standingat the shown position until the end <strong>of</strong> the attack. This way, from the view <strong>of</strong> the victim, the danger <strong>of</strong>a crash persists and the driver <strong>of</strong> the victim car is repeatedly warned. If the parameter initialTTC is sethigher than the warning threshold, the victim constantly updates the time to crash value and switchesfrom an information to a warning once the value falls below the warning threshold. Finally, Figure 3.7Figure 3.7: End <strong>of</strong> the attack. The victim car (blue) passes the ghost vehicle (bright red).shows the end <strong>of</strong> the attack when the victim passes the ghost vehicle. The total distance that the victimtraveled during the attack and the duration <strong>of</strong> the attack are calculated with equations 3.8 and 3.9.d sum = d preDEN + d DEN + d brake (3.8)43

t sum = d sumv v(3.9)Since from now on the ghost vehicle is behind the victim, it is no longer relevant to the victim. Fromthis point on, no more warnings are displayed to the driver <strong>of</strong> the victim. The attacker is now choosingthe next victim to attack. In Table 3.2, the values <strong>of</strong> the attack sequence for different victim speeds areshown.v v (m/s) v v (km/h) d init (m) d preDEN (m) d DEN (m) t b (s) d brake (m) d sum (m) t sum (s)8.33 30 20.83 4.17 16.67 0.56 1.16 26.16 3.1416.67 60 41.67 8.33 33.33 1.11 4.63 54.63 3.2825 90 62.5 12.5 50 1.67 10.42 85.42 3.4233.33 120 83.33 16.67 66.67 2.22 18.52 118.52 3.5641.67 150 104.17 20.83 83.33 2.78 28.94 153.94 3.6950 180 125 25 100 3.33 41.67 191.67 3.83Table 3.2: Values <strong>of</strong> the attack sequence for different speeds.3.1.4 <strong>Attack</strong>er parametersName Unit Type Default valueanalyzeHdgTimespan s double 1.0assumedCommRadius m integer 500brakeIntensity m/s 2 double 7.5c2xMsgFrequency Hz double 10.0initialTTC s double 4.0max<strong>Attack</strong>Duration s double 4.0preDENTimespan s double 1.0sendCAMs – boolean trueTable 3.3: Parameters <strong>of</strong> the attacker bundle.The parameters <strong>of</strong> the attacker implementation are shown in Table 3.3. The following list gives a shortdescription for each <strong>of</strong> the parameters.44• analyzeHdgTimespan: The length <strong>of</strong> the timespan during which the headings <strong>of</strong> the neighbors areanalyzed. Each time a new victim is chosen, the headings during the last analyzeHdgTimespanseconds are considered.• assumedCommRadius: The assumed communication radius for C2X communication. Neighborswith a distance higher than assumedCommRadius are not considered during the selection <strong>of</strong> avictim. This parameter is also used to calculate the timespan <strong>of</strong> possible communication with apotential victim. Apart from the parameter setting, this depends on the victim’s and attacker’sposition, speed and heading.• brakeIntensity: The absolute brake intensity that is used for the simulated emergency braking <strong>of</strong>the ghost vehicle.• c2xMsgFrequency: The frequency at which CAMs are sent out by the attacker if the parametersendCAMS is set to true.

• initialTTC: The time to crash when the ghost vehicle starts braking and sends out the DENM. Thisparameter also affects the initial distance between the victim and the ghost vehicle.• max<strong>Attack</strong>Duration: The maximum duration <strong>of</strong> an attack. After max<strong>Attack</strong>Duration seconds theattack is cancelled and a new attack is started.• preDENTimespan: The duration <strong>of</strong> simulated driving before the faked brake maneuver is started.This parameter also affects the initial distance between the victim and the ghost vehicle.• sendCAMs: If set to true, the attacker sends CAMs and DENMs during his attacks. Otherwise, onlyDENMs are sent.3.2 ImplementationEBL<strong>Attack</strong>er<strong>Attack</strong>ExecutorMessageGeneratorVapiDataReceiverVictimChooserVictimTrackerFigure 3.8: Main components with associations between themIn this section the implementation <strong>of</strong> the attacker bundle is described. The main components and theirassociations can be seen in Figure 3.8. In the following the responsibilities <strong>of</strong> each <strong>of</strong> the componentsare described.• EBL<strong>Attack</strong>er: This is the main entry <strong>of</strong> the attacker implementation. It instantiates further classesand sets up the parameters <strong>of</strong> the bundle. By implementing an interface, this class serves as aconnection to the outer OBU framework. Among others, the interface defines methods that arecalled when the implementation is started or stopped or when parameters are changed. Alsoconnections to other needed components are managed by this component. Apart from componentsfor receiving own vehicle data and data about neighboring vehicles a component for sending outC2X messages and another one for creating log messages are used.• VapiDataReceiver: The VapiDataReceiver is responsible for receiving updates <strong>of</strong> the own vehicledata. Each time an update is received this data is forwarded to the VictimChooser.• VictimTracker: The VictimTracker runs in a separate thread and regularly evaluates the mobilitydata <strong>of</strong> nearby vehicles. For each neighbor it keeps a history <strong>of</strong> the last heading values. This datais used by the class VictimChooser during the selection <strong>of</strong> the next victim to attack.• VictimChooser: The VictimChooser implements the choosing <strong>of</strong> a victim for an attack as describedin Section 3.1.2. Each time a new victim is requested, the list <strong>of</strong> available neighbors is filtereddiscarding neighbors that are too slow or leave the communication range too soon. After that,each vehicle is evaluated in terms <strong>of</strong> likelihood <strong>of</strong> success <strong>of</strong> the attack and potential damage.Finally, the most attractive victim is returned.45

• <strong>Attack</strong>Executor: The main loop <strong>of</strong> the attacker implementation is located in this component. Itis responsible for actually performing the attacks. Therefore, depending on the victim’s locationand mobility data, the data <strong>of</strong> the ghost vehicle is calculated and updated throughout an attack.Regularly, the data to be sent out is passed on to the MessageGenerator. Once an attack is finisheda new victim is requested from VictimChooser.• MessageGenerator: The MessageGenerator holds a connection to the send service in order to sendout CAMs and DENMs. When called with the current ghost vehicle’s mobility data, the correspondingmessage is generated and passed on to the send service.The interaction between these components during an attack is depicted in Figure 3.9. The <strong>Attack</strong>-Executor is started in regular intervals depending on the configured message frequency. The depictedsequence starts with the invocation <strong>of</strong> the <strong>Attack</strong>Executor just after the prior attack has been terminated.Since at this point the <strong>Attack</strong>Executor has no assigned victim, it requests the next victim to attack fromthe VictimChooser by calling its method getNextVictim(). Now the VictimChooser starts the sequencefor determining the next victim to attack. During this sequence it also requests the heading histories<strong>of</strong> the neighbors by calling getHeadingHistories() <strong>of</strong> the VictimTracker. As denoted in Figure 3.9, theVictimTracker is running constantly in its own thread and tracks the headings <strong>of</strong> neighboring vehicles.In the default setting, the heading values <strong>of</strong> the last 10 seconds are stored for each neighbor. WhengetHeadingHistories() is called, the list <strong>of</strong> neighbors is returned along with their past heading values. Usingthis heading data the VictimChooser goes on with determining the most prominent victim to attack.This process is described in detail in Section 3.1.2. If no vehicle is available for an attack, the methodgetNextVictim() returns null. Otherwise, the location and mobility data <strong>of</strong> the chosen victim is returned tothe <strong>Attack</strong>Executor. The <strong>Attack</strong>Executor now calculates the initial location and mobility data <strong>of</strong> the ghostvehicle and starts the attack. As long as the attack is running, the program flow stays in the depictedwhile loop. Throughout the attack, the position and speed <strong>of</strong> the ghost vehicle is updated according tothe attack sequence described in Section 3.1.3. In each iteration the vehicle data <strong>of</strong> the ghost vehicleis given to the MessageGenerator that constructs and sends out the corresponding message. Once theattack is finished the depicted sequence starts again.MessageGenerator<strong>Attack</strong>ExecutorVictimChooserVictimTrackergetNextVictim()getHeadingHistories()whilesendMessage()Figure 3.9: Interaction between components during an attack.46

4 EvaluationIn order to evaluate the presented attacks several test runs were performed on a dedicated test track.In this chapter the results <strong>of</strong> three test runs with different settings are presented. The setup <strong>of</strong> the firstdFigure 4.1: Setup <strong>of</strong> test run 1: Victim and attacker are driving behind one another at variable distance d.test run is shown in Figure 4.1. The victim vehicle drove on a straight road at a certain speed and theattacker vehicle followed. The attacker varied the distance d to the victim in order to simulate a passingvictim vehicle. The test run lasted 230 s and the results are shown in Figure 4.2. In this test run all <strong>of</strong> theattacker’s parameters were set to their default values as shown in Table 3.3. The distance between theattacker and the victim is depicted by the red line. In the beginning the vehicles drove at close distance toeach other. Then the attacker slowed down and increased the distance. Once he left the communicationradius <strong>of</strong> the victim he sped up again to reenter the communication radius. When within communicationradius the attacker constantly performed attacks on the victim. During these time spans the blue lineindicates the distance between the victim and the faked ghost vehicle. Since by default, the parameterinitialTTC is set to 4 s, warning messages should be generated by the victim vehicle upon reception <strong>of</strong> thecorresponding DENM. Green crosses in the diagram indicate points in time when the victim car showedsuch a warning message to its driver. As can be seen, the warning messages at 19.6 s and 175 s wereeach generated in response to the first <strong>of</strong> a series <strong>of</strong> subsequent attacks. The marked timespan from170 s to 220 s is shown again in more detail in Figure 4.3. During this timespan the attacker constantlyperformed attacks on the victim. Each peak <strong>of</strong> the blue line indicates the start <strong>of</strong> an attack since thedistance between the victim and the ghost vehicle is constantly decreasing throughout an attack. Duringthe timespan from 170 s to about 195 s the victim was driving at a speed <strong>of</strong> 45 km/h which resulted inan initial distance <strong>of</strong> about 30 m between the victim and the ghost vehicle. Here, attacks had an averageDistance (m)600500400300200100Distance to attacker vehicleDistance to ghost vehicleShown warning messages00 50 100 150 200 250Time (s)Figure 4.2: Results <strong>of</strong> test run 1. The outlined section from 170 s to 220 s is shown again in Figure 4.3.47

Distance (m)14012010080604020Distance to attacker vehicleDistance to ghost vehicleShown warning messages0170 180 190 200 210 220Time (s)Figure 4.3: Part <strong>of</strong> the results <strong>of</strong> test run 1 shown in more detail.duration <strong>of</strong> 3.5 s and included 12 messages sent by the attacker. After 200 s into the test run the vehicleincreased its speed up to 70 km/h resulting in higher initial distances up to 50 m between the victimand the ghost vehicle. Due to the higher speed the attack duration only increased slightly up to 3.55 son average. For some test runs the attacker’s parameters were varied. An example is test run 2 shownin Figure 4.4. Here, the parameter initialTTC was set to 7 s which should lead to informations shownby the attacked vehicle. Again, victim and attacker were driving behind one another on a straight roadas depicted in Figure 4.1. From about 20 s on, the attacker increased his speed in order to enter thecommunication range <strong>of</strong> the victim. The first attack was started at 47 s into the test run. At this timethe distance between the attacker and the victim was 270 m. From this point on, the vehicles remainedwithin communication range and attacks were performed constantly until the end <strong>of</strong> the test run. Dueto the higher value <strong>of</strong> initialTTC, the total distance needed for one attack was higher. Up to 80 s into thetest run the victim was driving at a speed <strong>of</strong> 70 km/h up to 85 km/h. During this timespan the initialdistance between victim and ghost vehicle ranged from 75 m to 95 m. The average attack duration was5 s with 16 messages sent per attack. From 80 s on, the victim drove at a lower speed ranging between40 km/h and 50 km/h. As can also be seen in the figure, the initial distance between victim and ghostvehicle was considerably lower with values between 42 m and 55 m. As expected, in this test run aninformation was triggered due to the higher initialTTC value. But as in the previous test run only one<strong>of</strong> the first attacks <strong>of</strong> a series <strong>of</strong> attacks was successful. None <strong>of</strong> the subsequent attacks led to anotherwarning message. In test run 3 a scenario with two victim vehicles was evaluated. The setup <strong>of</strong> thistest run is shown in Figure 4.5. The two victims drove side by side on a straight road and the attackerfollowed them which could be the case on a multi lane highway. The distance between the two victimswas low enough so that their relevance sectors (cf. Section 3.1.1) overlapped. This way an attack on oneDistance (m)700600500400300200100Distance to attacker vehicleDistance to ghost vehicleShown warning messages00 20 40 60 80 100 120Time (s)Figure 4.4: Results <strong>of</strong> test run 2.48

dFigure 4.5: Setup <strong>of</strong> test run 3: The two victims are driving side by side and the attacker follows at variabledistance d.<strong>of</strong> the victims could trigger a warning message in both vehicles. The attacker’s parameters were all setto their default values again. The victim cars drove at a speed <strong>of</strong> 55 km/h resulting in attack durations<strong>of</strong> 3.5 s with 12 messages sent by the attacker. The initial distance between the ghost vehicle and thevictims averages to 36 m. This time, instead <strong>of</strong> showing the distance to the ghost vehicle, green andpink crosses in Figure 4.6 indicate the starting times <strong>of</strong> attacks on victim one and two respectively. Asexpected, the vehicles are attacked in an alternating sequence with two exceptions. The blue squares andcircles indicate shown warning messages for victim one and two respectively. One can see that indeedwarning messages were shown at the same time by both victims which means that they were triggeredby the same attack. As in the previously described test runs the success rate <strong>of</strong> the performed attackswas rather low with only two <strong>of</strong> 20 attacks leading to shown warning messages. However, in this testrun for the first time two attacks <strong>of</strong> the same attack series were successful.Distance (m)4504003503002502001501005000 20 40 60 80 100 120Time (s)Distance to attacker vehicleShown warnings victim 1Shown warnings victim 2<strong>Attack</strong>s on victim 1<strong>Attack</strong>s on victim 2Figure 4.6: Results <strong>of</strong> test run 3.49

5 DiscussionThe previous chapters described how a manipulation <strong>of</strong> an AU enables an attacker to execute positionforging attacks that lead to wrong warnings in the attacked vehicles. Depending on the parametersettings only 3.5 to 5 seconds and not more than 16 forged messages are necessary in order to triggera warning message in a vehicle under attack. This means that these attacks could be executed in manyreal traffic situations even when the victim is only within communication range <strong>of</strong> the attacker for afew seconds. Furthermore, it has been shown that the attacker is able to influence the type <strong>of</strong> triggeredwarning/information by adjusting the attack parameters appropriately.In this work attacks were aimed to trigger EBL warnings about hard braking vehicles in front <strong>of</strong> thevictim. Similarly to the applied method, attacks on further applications should be possible since theyalso exclusively rely on the data stored in the application layer section <strong>of</strong> the messages.As for the different attack methods presented in Section 2.1, it has been shown that already the method<strong>of</strong> least effort for the attacker enables him to perform such potent attacks. Other attack methods requiremore effort and thus may be less attractive for an attacker. However, the other methods may be harderto detect.As can be seen in Chapter 4, the success ratio <strong>of</strong> the executed attacks was relatively low. In most <strong>of</strong>the test runs only the first <strong>of</strong> a series <strong>of</strong> subsequent attacks lead to a warning in the vehicle under attack.Log files that were generated during the test runs indicate that indeed no DENMs were received by thevictims during attacks that did not lead to warning messages. Since all <strong>of</strong> the sent DENMs used the samenode ID and event ID it is possible that a congestion control mechanism discarded those messages atthe sender. In real traffic situations this congestion control would prevent that a multi hop message isprocessed more that once when received from different vehicles. In further work this behavior could beevaluated in more detail.Although not all <strong>of</strong> the executed attacks lead to warnings in the attacked vehicles it has still beenshown that the applied attacks are possible. Thus, appropriate countermeasures have to be implementedin order to prevent these attacks in a real VANET. Otherwise the trust <strong>of</strong> users in the system woulddecrease what in turn could lead to a rejection <strong>of</strong> C2X systems.In this work the same node ID was used for all <strong>of</strong> the executed attacks. As a consequence the attackercould not simulate several ghost vehicles at the same time. In Chapter 2 it has been shown that thechanging <strong>of</strong> the node ID, that is stored in the application layer section <strong>of</strong> messages, is theoreticallypossible. By doing this, the simulation <strong>of</strong> several ghost vehicles i.e. Sybil <strong>Attack</strong>s would become possible.The attacker could simulate more complex traffic situations which probably further increase the impact<strong>of</strong> his attack.In the model used in this work the attacker takes into account the location and movement <strong>of</strong> neighboringvehicles in order to choose the most attractive victim for the next attack. However, once an attack isstarted, no further evaluation <strong>of</strong> the victim’s movement is done. If the victim changes its direction duringthe attack for example due to a turn in the road this could lead to a failed attack. Thus, the performedattacks could be improved by adjusting the driving path <strong>of</strong> the ghost vehicle to the victim’s trajectoryduring an attack. Furthermore, an attack could be canceled prematurely when the victim decreases itsspeed under the threshold for showing a warning. The road layout is also not taken into considerationwhen determining the position <strong>of</strong> the ghost vehicle. In our model it is possible that the ghost vehicle issimulated beside the road or that it leaves the road during an attack when there is a turn in the road.This means that the performed attacks could be detected by other vehicles when positions <strong>of</strong> neighborsare checked for validity. In terms <strong>of</strong> plausible road positions <strong>of</strong> the ghost vehicle the attacks presented inthis work are optimized for straight driving vehicles on straight roads.51

Apart from the validity <strong>of</strong> single positions, the consistency <strong>of</strong> subsequent positions <strong>of</strong> the ghost vehicleis not checked by the vehicles under attack. At the start <strong>of</strong> an attack the ghost vehicle’s position issimulated as being directly in front <strong>of</strong> the vehicle under attack. Such sudden appearances <strong>of</strong> vehiclesmay also occur during normal system behavior. Still, they are rather unusual and could indicate asimulated vehicle. Furthermore, in this work the same node ID was used for each attack. This results inposition jumps <strong>of</strong> that node ID between two attacks which in the general case will not be valid positionchanges. Again, these position jumps would lead to a reduced trust in that node ID when evaluating itfor plausible behavior.One approach to overcome the described detection mechanisms would be to further improve thesimulated behavior <strong>of</strong> the ghost vehicle. In the model <strong>of</strong> this work the movement <strong>of</strong> the ghost vehiclewas only plausible during an attack. It should be possible for the attacker to fake a ghost vehicle thatsimulates consistent driving behavior not only during but also between two subsequent attacks. If adriving attacker is assumed, the ghost vehicle could be simulated as driving in front <strong>of</strong> the real position<strong>of</strong> the attacker as long as no attack is performed. When then a slower vehicle, that is driving in thesame direction in front <strong>of</strong> the attacker, enters the communication range an attack could be started.The attacker could simulate a consistent overtaking maneuver so that the ghost vehicle is now driving infront <strong>of</strong> the victim. Now the actual attack could be started by simulating the braking maneuver. Once theattack is finished the ghost vehicle would slow down again until it reaches its previous position in front<strong>of</strong> the real attacker vehicle. By executing attacks in this way other vehicles would receive consistentdriving behavior from the ghost vehicle all the time which would make the detection <strong>of</strong> such attacksmuch harder. However, this approach also would decrease the attack possibilities <strong>of</strong> the attacker. Thisis due to the fact that less attacks could be performed because the ghost vehicle could not reach therequired starting position on time when only consistent behavior is used.The attack method <strong>of</strong> manipulating a vehicle’s AU in order to send forged messages only allows settingdata in the application layer section in CAMs and DENMs. The data <strong>of</strong> the network layer section isadded by the network layer implementation running on the CCU. The system that is used in this work,each layer is considered separately. In order to prevent an attacker from introducing false locationand mobility data into the application layer section <strong>of</strong> CAMs or DENMs cross-layer checks could beintroduced into the sending station. These checks could be executed when a message is processedby the network layer before being sent out. The location and mobility data <strong>of</strong> the application layercould be compared with data obtained from the internal vehicle network. Now, only if the differencebetween corresponding data values lie within acceptable ranges, the application layer data is consideredto be valid and the message is actually sent. Thus, in a system that applies such cross-layer checksthe manipulation <strong>of</strong> the AU would not be sufficient for an attacker to execute position forging attacks.Messages containing wrong data in the application layer would be detected and discarded.Apart from cross-checking the data <strong>of</strong> the different layers another approach to detect such attackswould be to take into consideration the signature <strong>of</strong> messages. If only the node ID, set in the applicationlayer section <strong>of</strong> a CAM or a DENM, is used to detect position jumps it would be sufficient for an attackerto manipulate the AU which allows him to alter the data <strong>of</strong> the application layer. As described, theattacker is then able to use different node IDs for each attack for example. However, all <strong>of</strong> the sentmessages are signed using the same private key. In order to improve the detection rate <strong>of</strong> such attacksthe validity <strong>of</strong> the used node ID could be checked using the signature <strong>of</strong> the message.52

6 ConclusionThe goal <strong>of</strong> this work is to analyze attack methods in a VANET and to measure their potential impact onthe system. After introducing the concept <strong>of</strong> a VANET an overview <strong>of</strong> possible attacks in these systemshas been given. Risk analyses <strong>of</strong> related works have shown that position forging attacks are one <strong>of</strong> themost severe attacks. Therefore, the core <strong>of</strong> this work focuses on this type <strong>of</strong> attack.In Chapter 2 different attack methods were analyzed that enable an attacker to perform positionforging attacks. The attack methods were evaluated in terms <strong>of</strong> required effort as well as the potentialimpact on the system. It has been shown that the manipulation <strong>of</strong> the AU is the most prominent attackmethod to attackers since other attack methods require considerably more time and effort while notincreasing the potential impact <strong>of</strong> attacks. By applying this method, an attacker is able to inject amalware into the AU <strong>of</strong> a on-board system. The malware in turn is permitted to send forged messagesthat contain false location and mobility data within the application payload <strong>of</strong> C2X messages. Thisway, attacks on various VANET applications become possible. In this work the EBL application has beenchosen as a target for the experimental application level attacks. The EBL function is seen as one <strong>of</strong>the most important applications in a VANET according to the ETSI. This application aims at preventingcollisions by warning drivers about hard braking maneuvers <strong>of</strong> vehicles driving ahead. However, whenan attacker is able to arbitrarily trigger false warning messages, this could mislead vehicles into possiblydangerous driving maneuvers. Furthermore, false warning messages will reduce the trust <strong>of</strong> users in thesystem.In Chapter 3 a concept <strong>of</strong> the described attack type is presented. For each EBL attack the attackerchooses the most attractive victim in terms <strong>of</strong> potential impact. By manipulating the location and mobilitydata <strong>of</strong> sent CAMs and DENMs the attacker starts simulating a ghost vehicle driving in front <strong>of</strong> the victim.At the right point in time, the ghost vehicle simulates an emergency braking maneuver. Consequently,an imminent collision <strong>of</strong> the victim and the ghost vehicle is faked. The goal <strong>of</strong> the attacker is to triggera driver warning on the victim’s display that could affect the behavior <strong>of</strong> the driver which may possiblylead to dangerous situations.By using a prototypic C2X communication system, the described attack has been implemented andtested in a laboratory environment. Additionally, the attack has been evaluated on a dedicated testsite with three vehicles that were equipped with C2X devices. According to the results presented inChapter 4, the application level attacks could be carried out successfully. In all <strong>of</strong> the performed testruns false driver warnings were triggered in the attacked vehicles. Based on the presented results furtherworks can implement and refine mechanisms that help to prevent such attacks in a real VANET.53

List <strong>of</strong> Figures1.1 ITS station reference architecture as standardized by the ETSI [10] . . . . . . . . . . . . . . 121.2 General structure <strong>of</strong> a C2X message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.3 Random position forging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261.4 Movement path forging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.5 Defense mechanism Minimum Distance Moved . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.1 ITS station architecture with malware introduced into the application layer . . . . . . . . . 373.2 Illustration <strong>of</strong> the EBL application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3 Process <strong>of</strong> choosing a victim to attack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 403.4 Beginning <strong>of</strong> an attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.5 Beginning <strong>of</strong> stage 2 <strong>of</strong> an attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.6 Beginning <strong>of</strong> stage 3 <strong>of</strong> an attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.7 End <strong>of</strong> an attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433.8 Main components with associations between them . . . . . . . . . . . . . . . . . . . . . . . . . 453.9 Interaction between components during an attack. . . . . . . . . . . . . . . . . . . . . . . . . . 464.1 Setup <strong>of</strong> test run 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2 Results <strong>of</strong> test run 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.3 Part <strong>of</strong> the results <strong>of</strong> test run 1 shown in more detail. . . . . . . . . . . . . . . . . . . . . . . . 484.4 Results <strong>of</strong> test run 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.5 Setup <strong>of</strong> test run 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494.6 Results <strong>of</strong> test run 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4955

List <strong>of</strong> Tables1.1 Different threats in a VANET, the respective threatened security goal and assessed severityas identified in [39]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251.2 Assessment <strong>of</strong> the threat <strong>of</strong> injecting false messages into the communication system. [32] 262.1 Different attack methods and their assessment in terms <strong>of</strong> various criteria. . . . . . . . . . . 343.1 Main parameters <strong>of</strong> the EBL application. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.2 Values <strong>of</strong> the attack sequence for different speeds. . . . . . . . . . . . . . . . . . . . . . . . . . 443.3 Parameters <strong>of</strong> the attacker bundle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4457

Bibliography[1] Amer Aijaz, Bernd Bochow, Florian Dötzer, Andreas Festag, Matthias Gerlach, Rainer Kroh, andTim Leinmüller. <strong>Attack</strong>s on Inter-Vehicle Communication Systems - An <strong>Analysis</strong>. In Proceedings <strong>of</strong>Workshop on Intelligent Transportation (WIT 2006), 2006.[2] Jan Beutel, Kay Römer, Matthias Ringwald, and Matthias Woehrle. Deployment Techniques for SensorNetworks. In Gianluigi Ferrari, editor, Sensor Networks, Signals and Communication Technology,pages 219–248. Springer Berlin Heidelberg, 2009.[3] Norbert Bißmeyer, Björn Schünemann, Ilja Radusch, and Christian Schmidt. Simulation <strong>of</strong> attacksand corresponding driver behavior in vehicular ad hoc networks with VSimRTI. In Proceedings <strong>of</strong>the 4th International ICST Conference on Simulation Tools and Techniques, SIMUTools ’11, pages162–167, ICST, Brussels, Belgium, 2011. ICST (Institute for Computer Sciences, Social-Informaticsand Telecommunications Engineering).[4] Chee-Yee Chong and S.P. Kumar. Sensor networks: evolution, opportunities, and challenges. Proceedings<strong>of</strong> the IEEE, 91(8):1247 – 1256, august 2003.[5] Car 2 Car Communication Consortium. C2C CC manifesto. http://www.car-2-car.org, 2007.[6] Dorothy Curtis, Esteban Pino, Thomas Stair, and Lucila Ohno-Machado. Adding the Human Element:Experience with a Wireless Patient Monitoring System. In Elena Gaura, Michael Allen, LewisGirod, James Brusey, and Ge<strong>of</strong>frey Challen, editors, Wireless Sensor Networks, pages 259–277.Springer US, 2010.[7] John R Douceur. The sybil attack. In Peer-to-peer Systems, pages 251–260. Springer, 2002.[8] Florian Dötzer. Privacy issues in vehicular ad hoc networks. In Privacy Enhancing Technologies,pages 197–209. Springer, 2006.[9] Claudia Eckert. IT-Sicherheit: Konzepte-Verfahren-Protokolle. Oldenbourg Verlag, 2009.[10] ETSI EN 302 665. Intelligent Transport Systems (ITS); Communications Architecture V1.1.1. Technicalspecification, ETSI, 2010.[11] ETSI TR 102 638. Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set <strong>of</strong>Applications; Definitions V. 1.1.1. Technical report, ETSI, 2009.[12] ETSI TR 102 893. Intelligent Transport Systems (ITS); Security; Threat, Vulnerability and Risk<strong>Analysis</strong> V1.1.1. Technical specification, ETSI, march 2010.[13] ETSI TS 102 637-2. Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set<strong>of</strong> Applications; Part 2: Specification <strong>of</strong> Cooperative Awareness Basic Service V1.2.1. Technicalspecification, ETSI, 2011.[14] ETSI TS 102 637-3. Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set<strong>of</strong> Applications; Part 3: Specifications <strong>of</strong> Decentralized Environmental Notification Basic ServiceV1.1.1. Technical specification, ETSI, 2010.59

[15] Jyoti Grover, Manoj Singh Gaur, and Vijay Laxmi. Position forging attacks in Vehicular Ad Hoc Networks:Implementation, impact and detection. In Wireless Communications and Mobile ComputingConference (IWCMC), 2011 7th International, pages 701 –706, july 2011.[16] H. Hartenstein and K. Laberteaux. VANET: vehicular applications and inter-networking technologies,volume 1. John Wiley and Sons Ltd, 2010.[17] Yih-Chun Hu, A. Perrig, and D.B. Johnson. Wormhole attacks in wireless networks. Selected Areasin Communications, IEEE Journal on, 24(2):370–380, 2006.[18] Frank Kargl. Sicherheit in Mobilen Ad hoc Netzwerken. Dissertation, Universität Ulm, October 2003.[19] T. Kosch, C.J. Adler, S. Eichler, C. Schroth, and M. Strassberger. The scalability problem <strong>of</strong> vehicularad hoc networks and how to solve it. Wireless Communications, IEEE, 13(5):22–28, 2006.[20] Timo Kosch, Christoph Schroth, Markus Strassberger, and Marc Bechler. Automotive Internetworking.John Wiley and Sons Ltd, 2012.[21] Tim Leinmüller, Robert K. Schmidt, and Albert Held. Cooperative position verification - defendingagainst roadside attackers 2.0. In Proceedings <strong>of</strong> 17th ITS World Congress, 2010.[22] Tim Leinmüller, Robert K. Schmidt, Elmar Schoch, Albert Held, and Günter Schäfer. Modelingroadside attacker behavior in vanets. In Proceedings <strong>of</strong> 3rd IEEE Workshop on Automotive Networkingand Applications (AutoNet), Nov 2008.[23] Christian Maihöfer, Tim Leinmüller, and Elmar Schoch. Abiding geocast: time–stable geocast for adhoc networks. In Proceedings <strong>of</strong> the 2nd ACM international workshop on Vehicular ad hoc networks(VANET ’05), pages 20–29, New York, NY, USA, 2005. ACM Press.[24] M. Mattheß et al. simTD - D21.5 - Spezifikation der IT-Sicherheitslösung. Technical report, simTD,2009.[25] Prasant Mohapatra and Srikanth V. Krishnamurthy, editors. Ad Hoc Networks. Springer, 2005.[26] Vinayak Naik and Anish Arora. Exscal: Dealing with scale. In Elena Gaura, Michael Allen, LewisGirod, James Brusey, and Ge<strong>of</strong>frey Challen, editors, Wireless Sensor Networks, pages 223–244.Springer US, 2010.[27] World Health Organization. Global status report on road safety 2013. http://www.who.int/violence_injury_prevention/road_safety_status/2013/en/index.html, 2013.[28] Christian Paßmann et al. simTD - D11.1 - Beschreibung der C2X-Funktionen. Technical report,simTD, 2009.[29] Panos Papadimitratos, Virgil Gligor, and Jean-Pierre Hubaux. Securing vehicular communications- assumptions, requirements, and principles. In Workshop on Embedded Security in Cars (ESCAR),pages 5–14, Nov 2006.[30] Bryan Parno and Adrian Perrig. Challenges in securing vehicular networks. In Workshop on HotTopics in Networks (HotNets-IV), pages 1–6, 2005.[31] Maxim Raya and Jean-Pierre Hubaux. Securing vehicular ad hoc networks. Journal <strong>of</strong> ComputerSecurity, Volume 15(1):39–68, Jan 2007.[32] A. Ruddle et al. EVITA - D2.3 - Security requirements for automotive on-board networks based ondark-side scenarios. Technical report, EVITA, 2009.60

[33] Robert Schmidt, Tim Leinmüller, and Albert Held. Defending against roadside attackers. In Proceedings<strong>of</strong> 16th World Congress on Intelligent Transport Systems, 2009.[34] Robert K. Schmidt, Tim Leinmueller, Elmar Schoch, Albert Held, and Guenter Schaefer. Vehiclebehavior analysis to enhance security in vanets. In Proceedings <strong>of</strong> the 4th IEEE Vehicle-to-VehicleCommunications Workshop (V2VCOM2008), 2008.[35] E. Schoch, F. Kargl, M. Weber, and T. Leinmuller. Communication patterns in VANETs. CommunicationsMagazine, IEEE, 46(11):119 –125, november 2008.[36] Elmar Schoch. Secure Communication in Inter-Vehicle Networks. Dissertation, Universität Ulm,October 2009.[37] IEEE Computer Society. 802.11p IEEE Standard for Information technology - Telecommunicationsand information exchange between systems - Local and metropolitan area networks - Specificrequirements; Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)Specifications; Amendment 6: Wireless Access in Vehicular Environments. Technical report, IEEE,june 2010.[38] Kazem Sohraby, Daniel Minoli, and Taieb Znati. Wireless Sensor Networks: Technology, Protocols,and Applications. John Wiley and Sons Ltd, 2007.[39] Jan Peter Stotz et al. Deliverable 1.1 - security requirements <strong>of</strong> vehicle security architecture. Technicalreport, PRESERVE, june 2011.[40] M. Tubaishat and S. Madria. Sensor networks: an overview. Potentials, IEEE, 22(2):20 – 23,april-may 2003.[41] Vehicle Safety Communications Project (VSC). Task 3 final report: Identify intelligent vehicle safetyapplications. Technical report, U.S. Department <strong>of</strong> Transportation, march 2005.61