GRADUATION PROJECT

Security Framework for Mobile Vehicular Ad-hoc Networks

Student: Alexandru George TEFNESCU

Scientific Coordinators: Prof. Dr. Ing. Valentin CRISTEA Sl. Dr. Ing. Ciprian DOBRE

July 2010

Alexandru George tefnescu Security Framework for Mobile VANETs

ABSTRACT Vehicular Ad-Hoc Networks (VANET) represent a particular type of wireless ad-hoc networks, formed with short range wireless communication devices, each one representing a vehicle on the road or a static device. Vehicular networks are likely to become the most relevant form of mobile ad-hoc networks in the future, although security for such networks represents a key point that is still under development. One of the most important aspects from the theoretical point of view is that in VANETs, better communication efficiency can be achieved by sacrificing security and vice versa. The objective of this project is to prove that vulnerabilities of VANETs can be eliminated. Therefore, we developed an antivirus system using a real-life Linux based smart-phone, Openmoko. The smart-phone has no security what so ever and another important aspect is that the application can be implemented using open-source options like Python and Linux bash scripting. The main reason for that is rapid prototyping nature of Python combined with Linux bash scripting. The starting point of the project is represented by a series of viruses that use the smartphone's API and that execute simple commands like making a call, send an SMS, and so on, without the user's knowledge. With the implementation of the antivirus, the obtained results demonstrate that several vulnerabilities of this smart-phone can be stopped with an userspace application although the viruses are background processes. Initiatives to create safer and more efficient driving conditions have recently begun to draw strong support in the computer-science domain. Also, significant developments have taken place over the past years in the area of vehicular communication system. It is well understood that the community that security and protection of private user information are a prerequisite for the deployment of the technology. The long term goal of this project is to understand what it takes to build a VANET protocol that leaves as little spaces as possible for misbehavior and abuse, and at the same time, does not affect the smart-phone's optimal functionality while using the application. The obtained results demonstrate that the importance of this project is that many attacks can be stopped before they can harm the integrity of the smart-phone. Also, another long term goal of the project is to show how vital security issues are in the context of VANET networking. Therefore, with this project we made the first step towards building a security protocol for VANETs.

Alexandru George tefnescu Security Framework for Mobile VANETs TABLE OF CONTENTS
1 Introduction 2 State of the art 3 Security Models 3.1 Attacks on VANETs ............................................................................... 3.1.1 Threat models that are used in security aspects of VANETs ...... 3.1.2 Attackers model ..................................................................... 3.1.3 Basic attacks ........................................................................... 3.1.4 Complex attacks......................................................................... 3.1.5 Other attacks.............................................................................. 3.2 Challenges............................................................................................... 3.2.1 Network scale and dynamics...................................................... 3.2.2 Privacy, trust, cost and gradual deployment.............................. 3.3 How to secure VANETs............................................................................ 3.3.1 Requirements............................................................................. 3.3.2 Security toolbox......................................................................... 3.3.3 Basic safety messaging protocol................................................ 3.3.4 Secure aggregation mechanisms............................................... 3.3.5 Security analysis........................................................................ 3.3.6 Implementation issues............................................................... 4 Security Frameworks for VANETs 4.1 Introduction............................................................................................. 4.2 Communication Model............................................................................. 4.2.1 Multi-domain and highly volatile environment ........................... 4.2.2 Frequent broadcast communication........................................... 4.3 Architecture............................................................................................. 4.3.1 System Requirements................................................................ 4.3.2 Cryptographic support............................................................... 4.3.3 Hardware Security Model........................................................... 4.3.4 Revocation................................................................................. 4.3.5. Secure communication............................................................. 4.3.5.1 Secure Beaconing......................................................... 4.3.5.2 Secure Neighbor discovery........................................... 4.3.5.3 Secure Geocast............................................................ 4.3.5.4 Pseudonym Handling.................................................... 4.3.6 In vehicle security...................................................................... 4.4 Design principles..................................................................................... 4.4.1 Vehicular Public Key Infrastructure and Authentication............. 4.5 Privacy and Trust..................................................................................... 4.5.1 Authorities and Privacy enhancing mechanisms........................ 4.5.2 Trusted Components.................................................................. 4.5.3 Revocation Game....................................................................... 4.5.4 Cryptographic mix-zones and mix-networks.............................. 4.5.5 Related mobile and wireless networking technologies............... 4.5.6 Faulty nodes............................................................................... 5 8 9 10 10 11 12 13 13 15 15 16 17 17 17 19 19 21 22 23 23 24 25 25 26 26 27 28 28 29 30 30 30 30 31 32 33 34 34 34 35 36 37 38

Alexandru George tefnescu Security Framework for Mobile VANETs

5 Implementation details 5.1 Openmoko............................................................................................. 5.1.1 Phone specifications................................................................. 5.1.2 Open source distributions......................................................... 5.2 Solutions to attacks............................................................................... 5.2.1 Attack scenarios....................................................................... 5.2.2 Solution architecture.............................................................. 5.2.3 Solution implementation........................................................ 5.2.3.1 Parser module............................................................. 5.2.3.2 Finding the script module............................................ 5.2.3.3 Stopping the script module ........................................ 5.2.3.4 Eliminating the virus module...................................... 5.2.3.5 Main module............................................................... 5.2.3.6 Main menu.................................................................. 5.2.3.7 Viruses........................................................................ 5.2.3.8 Running the application and stopping the viruses...... 6 Results 7 Conclusions and future work 8 References 40 40 41 42 44 44 45 46 47 48 49 50 51 52 53 53 56 60 61

Alexandru George tefnescu Security Framework for Mobile VANETs 1 INTRODUCTION In the last years an important domain the computer science has been the implementation of secure communication between vehicles. And this goal can be achieved with the use of Vehicular Ad-Hoc Networks (VANETs) that are a form of Mobile ad-hoc networks used to provide communications among nearby vehicles and between vehicles and nearby fixed equipment, usually described as roadside equipment. The main goal of VANET is providing safety and comfort for passengers. To this end a special electronic device will be placed inside each vehicle which will provide Ad-Hoc Network connectivity for the passengers. This network tends to operate without any infrastructure or legacy client and server communication. Each vehicle equipped with VANET device will be a node in the Ad-Hoc network and can receive and relay others messages through the wireless network. Collision warning, road sign alarms and in-place traffic view will give the driver essential tools to decide the best path along the way. There are also multimedia and internet connectivity facilities for passengers, all provided within the wireless coverage of each car. Vehicular Ad-hoc Networks are expected to implement variety of wireless technologies such as Dedicated Short Range Communications (DSRC) which is a type of WiFi. Other candidate wireless technologies are Cellular, Satellite, and WiMAX. Vehicular Ad-hoc Networks can be viewed as component of the Intelligent Transportation Systems (ITS). Developing applications and protocols for VANETs poses unique security challenges, induced by the devices being used, the high speed and sporadic connectivity of the vehicles and the high relevance of their geographic position. Such a network has several advantages because it provides access to information for users and also a form of communication between the users, but also some very important disadvantages that are also discussed in this project. Until recently, road vehicles were the realm of mechanical engineers, but the the impressive progress by the electronic domain, vehicles are becoming a simple form of computers on wheels and the connection between them is becoming a network on wheels. The main idea behind this project is to help manufacturers that are about to make a big step in the computer industry and also in the car industry. The long term goal is to create a form of communication between vehicles that helps the person driving the car. Initiatives of analyzing the costs of such a major step have been substantial in the past years and one of the most important aspects of the deployment of such a network is the strong analysis of the security aspect. Using VANETs vehicles will increase their awareness of the environment and therefore contributing to a safer and more efficient traffic. 5

Alexandru George tefnescu Security Framework for Mobile VANETs When talking about the security aspect of VANETs we encounter some major problems that are discussed in this paper. The first problem would be that there is a permanent transfer of messages and if the network is attacked, also a permanent transfer of threats and attacks. Secondly, we take into consideration the main purpose of a VANET which is the creation of efficient traffic conditions. Road side units, trust components, privacy and many aspects have to be discussed in this project in order to create a complete picture of this problem regarding VANETs. Attackers can become an important part in VANETs if the security aspect of these type of network is not analyzed correctly. The goal of this paper is to avoid the situations like in those in Figure 1a and 1b, in which the attacker becomes more important due to the information he sends to the other participants of the VANET.

Figure 1a. Overview of common security problems in VANETs

Figure 1b. A specific problem in VANETs

Alexandru George tefnescu Security Framework for Mobile VANETs Furthermore, additional aspects like entertainment and solving daily problems with the help of VANETs can become an important part of this type of networks. Considering the tremendous benefits expected from communication between vehicles, it is expected that vehicular communication can become the most relevant form of ad-hoc networks in the IT world. Challenges in the implementation and deployment of VANETs are difficult to resolve and the most crucial is the security aspect that we discuss in this project. Securing vehicular communication is our main concern in this paper, proving that given attacks can be resolved using simple algorithms. In this project we focus on the implementation of some attacks and an antivirus for a device with all required hardware components to be a VANET device. In order to achieve our goal, we used a Linux-based smartphone, Openmoko. The results of the project demonstrate that besides the vulnerabilities of VANET networks in general, the vulnerabilities of the smart-phone also have to be taken into consideration. Solutions to specific problems are implemented in the antivirus developed and the document is organized as follows: In section 2 we present the state of the art. In this chapter we review and analyze several related papers focused on the subject of securing vehicular networks In section 3 we present the security models. In this chapter we present the generalized security model, the attacks, the challenges and also the theoretical solutions to VANET problems. In section 4 we present the theoretical aspects of SeVeCom. The concept behind SeVeCom is secure vehicular communication. In this chapter we present the communication model, the architecture of the network and important aspects like privacy and trust. Besides all of these aspects, we try to analyze the implementation of theoretical solutions in VANETs. In section 5 we present the implementation details of the project. We describe the attacks on the phone and also the algorithm used to stop these attacks. An important part of this chapter is given by the architecture of the antivirus, that can be adapted on other smartphones. In section 6 we describe the results of the project. In section 7 we present the conclusions and future work.

Alexandru George tefnescu Security Framework for Mobile VANETs 2 STATE OF THE ART As discussed in the Introduction section, VANET represents an emerging research area in which both academia and the industry have so far largely overlooked the subject of security in VANETs, postponing it to later phases of research and development. Security in VANETs has been discussed in papers like [1] in which the author implements attacks and discovers weaknesses in the VANET security layer. The research on VANET security is just starting, with few pioneer papers so far. Raya and Hubaux describe in [2] security aspects that have to be taken into consideration while talking about VANETs. Further more, in [3] other aspects related to those in [2] are discussed besides the introduction in the MAC layer of VANETs. Also, privacy for smart vehicles is discussed in [4] while secure aggregation in VANETs is discussed in [5]. Research plays an important role in the integration of these types of networks in real life, therefore papers like [6] written by Eichler and Eberspacher discuss an general overview of car to car communication (c2c comm). Challenges of this domain are described in the chapters of this paper, while security of particular VANETs is discussed in [7] by Hubaux and Raya. Some recent papers like [7] and [8] focus on the particular VANET security subjects and make a complete overview of the architecture that could be used in the implementation of such networks. Also, as a complement to papers [7] and [8], papers [9] and [10] by Gerlach and Baliga offer a different perspective to the implementation of security models in car to car communication. SeVeCom security framework is described in [11], [12] and [13] by authors like Raya and Papadimitratos that are pioneers in the VANET research domain. Architecture, vulnerabilities, challenges and cryptographic support are discussed in these papers in a detailed way that is meant to offer a more practical view on the problems that can occur. Furthermore, [15] is a paper based on the architecture for secure and private communications and in [16] the author, Raya, discusses algorithms that could represent the foundation of a real implementation regarding VANETs. Authorities and certificates are discussed in the papers [17], [18] and [19]. Some commercial products already make use of vehicular communication without taking the security aspect into account. For example, insurance companies install black boxes (similar to the Event Data Recorders in this paper) in cars to collect their usage data (e.g., traveled distance) and to calculate insurance costs accordingly.

Alexandru George tefnescu Security Framework for Mobile VANETs 3 SECURITY MODELS The goal of VANET is safer transportation and more comfort for the passengers, thus a special electronic device will be placed inside each vehicle which will provide Ad-Hoc Network connectivity for the passengers. This network tends to operate without any infra-structure or legacy client and server communication as demonstrated in [2] and [3]. Each vehicle equipped with VANET device will be a node in the AdHoc network and can receive and transmit others messages through the wireless network. Collision warning, road sign alarms and in-place traffic view will give the driver essential tools to decide the best path along the way. Security of inter-vehicular communication has been ignored so far by the research community mostly of the complexity the problem can reach in just a few assumptions. The main idea of the security issue besides trust is allowing each car to constitute a local communication area around itself. In this way, each car can exchange vital signs with the neighboring vehicles. Security in VANETs can be improved only after experiencing and issuing models as discussed in [1]. First of all, the attacker must be identified and the main principles that guide his attack and for this reason we use basic assumptions about the attacker based on what we can observe as damage from the attack.

Figure 2. Overview of VANET security

Alexandru George tefnescu Security Framework for Mobile VANETs 3.1 ATTACKS ON VANETS

3.1.1 Threat models that are used in security aspects of VANETs

In this section is described the security model of VANETs and the presumed threats that face this type of network. The main goal is general classification, although it is almost impossible to identify all the attacks and threats facing the performance of VANETs. First of all it is necessary to identify the threats that exist in VANET's and the way those threats can affect the performance and the integrity of the network. Describing threats and certain attacks can be of real use when thinking about the practical and theoretical solutions of these problems. Therefore we categorize security threats into three groups according to the application type that they target according to previous works like [2], [3] and [4]. 3.1.1.1 Attacks on safety-related applications The main goal of VANETs is to provide a safer way for people to drive, a more secure one and also a more comfortable one. As the security of people lives is the more important aspect of this issue it is extremely important that threats on safety-related applications must be the main of the research of security aspects. 3.1.1.2 Attacks on payment-based applications Another goal of vehicular ad-hoc networks is to provide features so that payment can be done much easier for cars in such a network. This includes payment of service, insurance and can probably lead to a series of financial frauds from part of the attacker. 3.1.1.3 Attacks on privacy One important question in the implementation of VANETs is the problem of privacy. Using smart devices while driving can lead to a series of problems regarding the privacy of the ones using those devices in the VANET. The most common name for this is the Big Brother Phenomenon. This kind of threat can result in financial damage, accidents and many other forms of problems.

10

Alexandru George tefnescu Security Framework for Mobile VANETs

3.1.2 Attackers model

To be able to solve the problems that can occur in such networks it is very important to classify the main types of attackers in such a network. Therefore we define four dimensions in which the attackers can be classified, analyzing the way they attack the network, their main purpose and the damage they create in VANETs. This has been discussed also in related work like [1], [2] and [5]. 3.1.2.1 Insider vs. Outsider Inside attacker is an active part in the VANET, an authenticated member of the network that can freely communicate with the other members. In most cases he possesses an authenticated public key that is used for authentication. On the other hand, the outside attacker once is inside the network is considered to be an intruder, and thus has a limited access to the network. Using limited access for the outsider can be a turning point in security aspects for VANETs because of the fact that the attackers privileges are restraint to a certain point. 3.1.2.2 Malicious vs. Rational A malicious attacker seeks no personal benefits from the attack and his only goal is to attack the good functionality of the network and the security of the members. On the other hand, a rational attacker seeks personal benefit, thus acting to increase his personal and mostly financial benefit. Attacks like financial fraud or personal information theft are most common for ration attackers. 3.1.2.3 Active vs. Passive An active attacker uses packets of signals for the attack while a passive attacker only eavesdrops on the communication between the members of the VANET. 3.1.2.4 Local vs. Extended A limited attacker in scope is a local one, while an extended attacker controls several entities that are across the network. Using this important distinction, attacks like privacy-violating and/or wormhole attacks can be stopped or prevented.

11

Alexandru George tefnescu Security Framework for Mobile VANETs

3.1.3 Basic attacks

Considering the theoretical model of the Attacker, it is important to classify in a general way the possible attacks that influence the security and/or performance of the VANET. Using modern technology, we consider only the type of attacks that can be made with inter-vehicular communication. The most important attacks were discussed in related works like [1], [2] and [3]. 3.1.3.1 Bogus information Attackers that use this type of attacks are insiders, rational and active. The above classification of the attackers can lead to solutions after analyzing the problem. The bogus information attack is the diffuse of wrong information in the network, mostly affecting the behavior of the drivers except the attacker. 3.1.3.2 Cheating with sensor information Attackers that use this type of attacks are insiders, rational active and local. They use this type of attack to alter their perceived position, speed, direction and other important information. This type of attack is mostly used to escape liability, notability in case of an accident. 3.1.3.3 ID disclosure Also known as The Big Brother Phenomenon, it's used to track the location of other vehicles. A global observer can monitor trajectories of targeted vehicles and use this data for a range of purposes. The attacker is passive; therefore his only motivation is to eavesdrop on the other traffic participants. The information the attacker gains can be used instantly or for other purposes. 3.1.3.4 Denial of Service The attacker is malicious, active and local. He may want to bring down the VANET or even cause an accident. Some important examples are channel jamming and aggressive injection of dummy messages. 3.1.3.5 Masquerading The attacker actively pretends to be another vehicle by using false identities and can be motivated by malicious or rational objectives.

12

Alexandru George tefnescu Security Framework for Mobile VANETs

3.1.4 Complex attacks

We consider only the attacks penetrated against messages rather than vehicles, as the physical security of vehicle electronics is out of the scope is this paper. The attacks in this section are more elaborated combinations or variants of the Basic Attacks and it has been discussed in related work [1], [2] and [4]. 3.1.4.1 Hidden vehicle Hidden vehicle attack is the perfect example of cheating about the positioning of the vehicle. The main purpose of this type of attack is being invisible to the other vehicles of the network. Using safety messages and the safety message protocol, a vehicle broadcasting warning will listen for feedback from its neighbors and stop its broadcast if realizes at least one of these neighbors is better positioned. 3.1.4.2 Tunnel The attacker may exploit the temporary loss of positioning information when vehicles loose the GPS signal (in tunnels mostly). The attacker can inject false data once the vehicle leaves the tunnel. This type of attack can be stopped with an independent positioning check once the vehicle leaves the tunnel. 3.1.4.3 Bus telegraph The wormhole attack consists in tunneling packets between two remote nodes. Therefore, in VANETs an attacker that controls at least two distinct nodes of the network remote from each other and a high speed communication between them can tunnel packets broadcasted in one location to another. 3.1.4.4 Wormwhole This is a developed form of the bogus information attack. Similarly to the social phenomenon of information spreading and its en-route modification, this attack consists in adding incremental errors to the information at each hop.

3.1.5 Other attacks

These types of attacks are mostly variants of the attacks presented in sections 3.1.3, 3.1.4. 13

Alexandru George tefnescu Security Framework for Mobile VANETs 3.1.5.1 Jamming The attacker deliberately generates interfering transmissions that prevent communication within their reception range. As the network coverage area can be well-defined, at least locally, jamming is a low-effort exploit opportunity. As the figure illustrates, an attacker can relatively easily, without compromising cryptographic mechanisms and with limited transmission power, partition the vehicular network. 3.1.5.2 Forgery The correctness and timely receipt of application data is a major vulnerability. The most important aspect of this type of attack is the rapid contamination of large portions of the network coverage area with false information where a single attacker forges and transmits false hazard information, which are taken up by all vehicles in both traffic streams. 3.1.5.3 In-transit Traffic Tampering Any node acting as a relay can disrupt communications of other nodes: it can drop or corrupt messages, or meaningfully modify messages. In this way, the reception of valuable or even critical traffic notifications or safety messages can be manipulated. Moreover, attackers can replay messages. In fact, tampering with in-transit messages may be simpler and more powerful than forgery attacks. 3.1.5.4 Impersonation Message fabrication, alteration, and replay can also be used towards impersonation. Arguably, the source of messages, identified at each layer of the stack, may be of secondary importance. Often, it is not the source but the content (e.g., hazard warning) and the attributes of the message (freshness, locality, relevance to the receiver) that count the most. However, an impersonator can be a real threat to the performance of the VANET and the safety and/or security of the vehicles using the network. 3.1.5.5 Privacy violating With vehicular networks deployed, the collection of vehicle specific information from overheard vehicular communications will become particularly easy. Then inferences on the drivers personal data could be made, and thus violate the privacy. The vulnerability lies in the periodic and frequent vehicular network traffic: safety and traffic management messages, context-aware data access (e.g., maps, ferryboat schedules), transaction-based communications (e.g., automated payments, car diagnostics), or other control messages (e.g., over-the-air registration with 14

Alexandru George tefnescu Security Framework for Mobile VANETs local highway authorities). In all such occasions, messages will include, by default, information (e.g., time, location, vehicle identifier, technical description, trip details) that could precisely identify the originating node (vehicle) as well as the drivers actions and preferences. 3.1.5.6 On-board tampering Beyond abuse of the communication protocols, the attacker may select to tinker with data (e.g., velocity, location, status of vehicle parts) at their source, tampering with the on-board sensing and other hardware. In fact, it may be simpler to replace or by-pass the real-time clock or the wiring of a sensor, rather than modifying the binary code implementation of the data collection and communication protocols.

3.2 CHALLENGES As seen in the previous chapters one of the most important aspects of VANETs is the consistency in the security area. Therefore, after a closer look at the attacker's model and also at the most important types of attacks, we can think at some general and theoretical ways to prevent or solve these attacks. The security of vehicular communication is one of the most important components of the successful launch of this technology. Discussed in related works like [5], [6], [7] security provides a large scale of challenges.

3.2.1 Network scale and dynamics

VANETs will be the largest real-life instance of a self-organized adhoc network if implemented correctly. Thus, its size will be of millions of nodes that each has certain properties and can be divided in categories: like authorities, normal cars, service providers, attackers, etc. The main problem for such a large-scale network is the scalability, mostly because these types of problems should be solved in a way transparent to the driver (the normal node in such a network). Besides scalability issues, one of the most important aspects that have to be taken in consideration is the dynamics of such a network. For example, let us just imagine 10 cars driving at different speeds crossing each other on the highway. Different speeds lead to an almost instant way of communication between the two cars.

15

Alexandru George tefnescu Security Framework for Mobile VANETs

3.2.2 Privacy, trust, cost and gradual deployment

Most of the important attacks target the different forms of privacy that a normal user of the VANET has. Thus, one of the major consumer concerns about this type of communication is the potential influence on privacy. People are usually skeptical about the exchange of information from persons the already know, but from strangers on a highway. Although there are solutions that can offer the possibility of providing the driver and the vehicle anonymity, this may negatively affect the liability of the network. Another key element in a security system is trust. This is particularly emphasized in vehicular networks because of the high liability required from safety applications. Because of the large number of independent network members and the presence of human factor, it is highly probable that misbehavior will arise. Another important factor is that consumers because highly concerned about their privacy. Drives do not make an exception; therefore the level of trust in vehicles as well as service providers will be low. Also, besides drivers and service providers there will be a considerable presence of governmental authorities in such network. Because of the skepticism of most members in such network, the trust in these authorities will be only partial. Cost is another important aspect in the deployment of intervehicular communications. The first cost that we encounter in the deployment of such network is the introduction of new communication standards for vehicular communication that will require manufacturers to install new hardware modules on all vehicles, thus increasing the cost of the consumers. Also, another cost is the one for the inter-vehicular communication: mostly it the communication is based on text messages through GSM service. Another important cost is the permanent technical support for the hardware installed on the roads. Last important cost is for the infrastructure that will allow vehicles to access online authorities as part of security services. The time span of inter-vehicular communication until it reaches considerable penetration is around a decade. This means that only a small proportion of vehicles will contain the enhanced features of inter-vehicular communication over the next couple of years. The gradual deployment is an important factor that has to be taken in consideration also from the security point of view.

16

Alexandru George tefnescu Security Framework for Mobile VANETs 3.3 HOW TO SECURE VANETS In this section we propose a set of security solutions to be deployed in VANETs. We attempt to consider all the possible options but take into account both the current state of the art and the long-term viability of these networks. As discussed in [7] and [8], in this section we present some solutions proposed until now about securing the vehicular communication.

3.3.1 Requirements

Authentication: vehicle reactions to events should be based on legitimate messages. Therefore we need to authenticate the senders of these messages. Verification of data consistency: the legitimacy of messages also encompasses their consistency with similar ones, because the sender can be legitimate while the message contains false data Availability: even assuming a robust communication channel, some attacks can bring down a network. It is very important to point out that the network cannot be brought down, and if the VANET is brought down it can be restored through another way. Non-repudiation: drivers causing accidents should be reliably identified Privacy: people are increasingly wary of The Big Brother Phenomenon and also about the privacy of such networks. Real time constraints: At the very high speeds typical in VANETs, strict time constraints should be respected

3.3.2 Security toolbox

In this section we discuss the most common solutions in the use of VANETs. The solutions presented are both hardware and software. The main problem is that solving some aspects of the inter-vehicular communication, we most surely come across another set of problems like overhead, secure positioning and others.

17

Alexandru George tefnescu Security Framework for Mobile VANETs 3.3.2.1 Electronic License Plates (ELP) ELPs are unique cryptographically verifiable numbers that will be used as equivalents of traditional license plates. The advantage of ELPs is that will automate the paper-based document of checkup of vehicles. These types of license plates may be issued by governmental transportation authorities. Hence, the authorities should have the crosscertification agreements that will allow them to verify the ELPs issued by the other authorities. 3.3.2.2 Vehicular PKI A public key infrastructure, also known as PKI is the typical architecture used for networks where the presence of online authorities is not always guaranteed. Given the properties of large scale and initially low penetration of vehicular communications infrastructure, a PKI is a good choice for enabling inter-vehicular communication. There are some problems that can occur while using this type of architecture, although it seems very convenient for VANETs. The first problem is the key distribution; another problem is the certificate revocation by which the CA invalidates some private/public keys pairs due to their discovery by an attacker. 3.3.2.3 Event data recording (EDR) Similar to the black boxes on an airplane, EDRs will be used in vehicles to register all important parameters, especially in situations like accidents. 3.3.2.4 Tamper-proof hardware Vehicles will store cryptographic material such as ELPs and VPKI private or public keys in tamper-proof hardware that will keep this material safe from attackers, thus decreasing the possibility of information leakage. 3.3.2.5 Data correlation The bogus information attack cannot be easily discovered, like other attacks like DoS ones. The main solution to this problem is to use data correlation techniques that will collect data received from different sources and thus allowing the vehicle to make a decision on the level of credibility, consistency and relevance of the received information.

18

Alexandru George tefnescu Security Framework for Mobile VANETs 3.3.2.6 Secure positioning There is a real need for secure position verification, thus vehicles or base-stations may want to verify the position of other vehicles or basestations on the fly. The most common solution for this issue is the GPS system, that is very convenient but also has a lot of security leaks.

3.3.3 Basic safety messaging protocol

Because the research on VANETs and their applications is still in its beginnings, there are few papers in the literature that describe protocols for safety messaging. As discussed in related works like [7], [8] and [9], security solutions are only at a theoretical point. The implementation has to take into account a series of problems that are related to security issues, but the main idea is to analyze how could a basic safety messaging protocol could work. To better describe the security solutions introduced in this section we describe in the following a simple protocol for messaging with the properties:
o

we assume that each vehicle V periodically sends messages over a single hop every 300 ms within the range of 10 s travel time the inter-message interval drops to 100 ms and the range to 15 m if the vehicles are very slow or stopped and vehicles take decisions based on the received messages.

3.3.4 Secure aggregation mechanisms

In this section we present three major classes of aggregation techniques, each representing a better and different way to achieve efficiency. 3.3.4.1 Combined signatures In the basic scheme, each vehicle broadcasts a signed safety message. This creates considerable security overhead, especially in terms of message size and signature generation delay. There may be an additional delay resulting from data verification algorithms running on the receiving vehicles. Bearing in my mind the drawbacks of independent safety messages, we should be able to combine the signatures generated by a group of vehicles reporting the same events.

19

Alexandru George tefnescu Security Framework for Mobile VANETs There are several types of signatures combinations, each with its own benefits and drawbacks, especially in terms of overhead.

Concatenated signatures: in this case a vehicle that receives a message with correct information appends its signature to the existing signature and rebroadcasts the new message o Onion signatures: one of the most important issues is reducing the message size and therefore the signature size. With the help of onion signatures, we exploit the fact that signatures sizes are constant because the message is hashed before being signed, therefore we can over sign the message (instead of appending a new signature, the vehicles signs the previous signature) o Hybrid signatures: although concatenated signatures, in terms of computation overhead are more efficient than onion signatures, the opposite is true with respect to communication overhead.
o

3.3.4.2 Overlapping groups Despite the advantages achieved by the schemes in the previous section, they are still in the realm of asymmetric cryptography, which remains expensive. To make a quantitative leap, we designed a mechanism based on symmetric cryptography. The core idea is to use overlapping groups, each group having its own symmetric key. Vehicles in the intersection of two groups know the keys of both groups and hence are able to assure the bridge for data flow between the two groups. Therefore, we have to take into consideration the following aspects: the position of a vehicle can be securely determined or verified groups are established with each group having its own symmetric key there is a majority of honest vehicles, upon which data destination vehicles can rely to receive correct information 3.3.4.3 Dynamic group creation In contrast to overlapping groups where memberships are geographically determined, in this section we consider dynamic groups created by vehicles sharing the same driving pattern over an extended period of time. A good example of such groups is the platoon of vehicles formed on the highway. The key idea is that once the leader and members of the group are identified, the leader creates a key request message with a certain content and format. Once the asymmetric group key is established, any group member can send a message signed on behalf of the group. The message also includes an unique ID assigned by the CA to the group member that sent the message. 20

Alexandru George tefnescu Security Framework for Mobile VANETs

3.3.5 Security analysis

3.3.5.1 Compliance with the security requirements and anonymity Authentication of message legitimacy is provided by the digital signature of the sender and the corresponding CA certificate. The only guarantee that this provides is that the message comes from a vehicle that was trusted, at least when the keys were issued. Availability can be totally guaranteed. Even though the availability of vehicles and the network is almost totally guaranteed, the ways in which an attacker can disrupt the network service are limited: outsiders can only mount jamming attacks. Starting from the initial assumptions we have the following facts: vehicles cannot claim to be other vehicles since they only interact with their anonymous public keys vehicles cannot cheat about their position and related parameters if a secure positioning solution is used a vehicle cannot deny having sent a message because it is signed by an anonymous key that belongs exclusively to the sender.

Using these facts, the security of a VANET is more a certainty than an assumption. Yet, many problems can occur when trying to solve the basic issues of security in IVC. In order to preserve the driver's anonymity and minimize the storage costs of public keys, a key changing algorithm that adapts to the vehicle speed can be propose. Also the algorithm takes into account key correlation by the attacker.

Figure 3. Overview of security analysis

21

Alexandru George tefnescu Security Framework for Mobile VANETs

3.3.6 Implementation issues

On one hand the anonymous key set size should be small to reduce storage space on vehicles, but also on the other hand the certificate lifetime should be short to reduce the vulnerability window of the system if an anonymous public or private key is compromised. Therefore, a tradeoff must be made between the two. The lifetime certificate uses the following aspects: each anonymous key should be used only with a sequence of consecutive messages. Also, the lifetime certificate should be short, around one day, to limit in the effects of a possible key compromise. On the other hand, driving duration changes from day to day, hence some days a larger number of keys may be required. To account for this, the lifetime certificate should be stretched over several days. Another important aspect that has to be taken in consideration is that a vehicle should change its anonymous key only after having used it for a certain number of messages. As we propose using a PKI for supporting security in VANETs, it is important to choose a Public Key Cryptosystem (PCKS) with an acceptable duration overhead in vehicular context like the following:
o o o

RSA sign: the key and signature sizes are large (256 bytes) ECC (Elliptic Curve Cryptography): it is more compact that RSA (28 bytes), faster in signing but slower in verification NTRUSign (a recent cryptosystem) the key size is of approximately 197 bytes, but it is much faster than both in both signing and verification.

22

Alexandru George tefnescu Security Framework for Mobile VANETs 4. SECURITY FRAMEWORKS FOR VANETS

4.1 INTRODUCTION Today they are seen as solutions to improving the quality of traffic in urban environments, increasing traffic safety, lowering the pollution or reducing congestion in urban scenarios. Recently initiatives to create safer and more efficient driving conditions have begun to draw strong support. Vehicular communications (VC) play a central role in this effort, enabling a variety of applications for safety, traffic efficiency, driver assistance, and infotainment. There is a high effort in developing vehicular networking protocols that allow nodes, vehicles or roadside infrastructure units, to communicate with each other over single or multiple hops. In other words, nodes that would act both as end points and routers, with vehicular networks emerging as the first commercial instantiation of the mobile ad hoc networking technology. The self-organizing operation and the unique features of VC are a double-edged sword: a rich set of tools are offered to drivers and authorities, but a formidable set of abuses and attacks becomes possible. Hence, the security of vehicular networks is indispensable, because otherwise these systems could make antisocial and criminal behavior easier, in ways that would actually jeopardize the benefits of their deployment. What makes VC security hard to achieve is the tight coupling between applications, with rigid requirements, and the networking fabric, as well as the societal, legal, and economical considerations. Therefore, in the analysis of vehicular communication, security plays a very important role alongside making the communication possible and the architecture and design of the ad hoc network itself. Any wirelessenabled device that runs on a version of vehicular communications protocol stack poses as a threat and such threats have to be analyzed in every possible way according to the attacker's model discussed in a latter section. In this we present original solutions to increasing the safety and security characteristics of VANET systems. As seen in the previous chapters the security issue is one of the most important in the deployment of VANET systems, therefor a close analysis on types of attacks, attackers model and system architecture is needed. Important aspects of securing vehicular communications are discussed also in related work like [11], [12] and [13].

23

Alexandru George tefnescu Security Framework for Mobile VANETs 4.2 COMMUNICATION MODEL Wireless communication in vehicular networks represents the key part of the implementation and deployment of such networks. The communication can be modeled by following the data-link layer primitives and assumptions, explaining how the communication works between different participants of the ad hoc network. As described in [14], the communication model assumes that the communication across the network is dependent on the availability of sufficient resources and, in particular, bandwidth. Assuming that the network has all the necessary parts for deployment, the most important operations that can be done are the following: 1. SEND : used to transmit a message m to a node V within the radius R of the transmitting node; 2. BROADCAST : the sending of a broadcast message m to all the nodes within the radius R of the transmitting node; 3. RECEIVE : used to receive a message m transmitted by a node within the radius R of the receiver; Other assumptions related to the deployment of vehicular networks are as follows: A link between two nodes is up when the two nodes are able to communicate directly. Links are either up or down and their state does not change faster than the transmission time of a single packet. The network connectivity can be modeled as the graph G the edges of which are all up links. Transmission from one node is received by all nodes that are up during the transmission of the packet. Packets are delivered across an up link within a maximum delay or are not transmitted at all. The data link layer handles transient network failures, it retransmits but does not duplicate packets.

The model also assumes the possibility that nodes have more than one network interface. One option is to consider that multiple nodes run on each platform, with a distinct identity and credentials for each interface. In next sections we distinguish three different aspects of vehicular communication that are very important. 24

Alexandru George tefnescu Security Framework for Mobile VANETs

Figure 4. Overview of the communication model

4.2.1 Multi-domain and highly volatile environment

Any two or more nodes within range, or within multiple wireless links communicate independently of whether they are registered in different domains. The connectivity and the set of nodes in the vicinity of a node can change radically over time, at different time scales. As a result, it is likely that nodes that are not registered with the same authority communicate and become associated.

4.2.2 Frequent broadcast communication

Unicast or multicast communication is clearly possible, as networking protocols may determine a set of intended receivers of simply a single receiver. A first distinctive characteristic of the network is that restrictions determine how a message propagates across the network and the sender does not have prior knowledge of the receiver's identity of location. Secondly, traffic messages are transmitted either periodically or triggered by in-vehicle events of network events or both. The transmission time is low resulting in frequent transmission.

25

Alexandru George tefnescu Security Framework for Mobile VANETs 4.3 ARCHITECTURE

4.3.1 System Requirements

VANETs represent a type of network that has a large set of features to make transportation safer and easier, but also the large number of features is a double edged sword because of the gaps in security. Therefore, under all circumstances vehicular communications must be secured. In fact, it is possible that vehicles and their sensing, processing and communication platforms are compromised by some simple attacks upon the network. Also, any wireless-enabled device that runs a rogue version of the vehicular communication protocol stack poses a threat to the network and the transportation model. Thus, one of the most important steps in securing vehicular communication is to outline the stand-alone requirements that are relevant. As discussed in related work [12],[13] the system requirements are an important part of the deployment of the communication model

Message authentication and integrity : messages must be protected from any alteration and the receiver of a message must corroborate the sender of the message. Integrity does not imply the identity of the sender. Message non-repudiation: the sender of a message cannot deny having sent the message. Entity authentication: the receiver is not only ensured that the sender generated a message but in addition has evidence of the message. Access control: access to specific services provided by the infrastructure nodes or the other nodes is determined locally by policies. Message confidentiality: the content of the message is kept secret from those nodes that are not authorized to access it. Privacy and anonymity: vehicular communication systems should not disclosure or allow inferences on the personal and private information of their users. There are two types of anonymity: strong probabilistic anonymity and full anonymity, both possible in the implementation of VANETs.

26

Alexandru George tefnescu Security Framework for Mobile VANETs

Availability: protocols and services should remain operation even in the presence of faults, malicious or benign. This implies a secure and faulttolerant design. Liability identification: user vehicles are liable for their deliberate or accidental actions that disrupt the operation of other nodes or transportation system. The vehicular network should provide information that identifies or assists the attribution of liability. However, liability identification implies that anonymity would need to be paired with the option to learn or recover the node's identity of necessary.

4.3.2 Cryptographic support

The management of credentials in both short and long term is undertaken by the certificate authorities (CA) that are also responsible for the revocation of credentials for any node if needed, as well as holding the node accountable by mapping node communications to its long-term identity. Identity and credential management can be realized in two different ways: Long term identification: each node X has a unique long term ID which will be the outcome of an agreement between car manufacturers and authorities, similar to the use of vehicle identification numbers. Each identity is associated with a cryptographic key pair and a set of attributes of node X, attributes that reflect technical characteristics of the node equipment. Short therm identification: to obtain pseudonyms, a vehicle's hardware security model generates a set of key pairs and sends the public keys to a corresponding CA via a secure communication channel. The CA signs each of the public keys and generates a set of pseudonyms for the vehicle. Pseudonyms are stored and managed in the on board pseudonym pool with their corresponding secret key. Being a short term mechanism, vehicles can easily change their pseudonyms. Therefore, by using the same pseudonym only for a short period of time and then switching to a new one, vehicle activities can be linked only during the period of time when the same pseudonym is used.

27

Alexandru George tefnescu Security Framework for Mobile VANETs

4.3.3 Hardware Security Model

Also known as HSM, the hardware security model is the trusted computing base of the SeVeCom security architecture as discussed in [12] and [13]. It stores the private cryptographic functions to be used by other modules. The HSM is psychically separated from the on board unit and it has some tamper resistant properties in order to protect the private key material against physical attacks. The HSM consists of a CPU, some non-volatile memory, a built-in clock, and some I/O interface. In addition, the HSM has a built-in battery in order to power the clock and the tamper detection and reaction circuitry. The main HSM function is to include cryptographic operations, as well as key and device management functions: the main cryptographic operations provided by the HSM are digital signature generation and decryption of encrypted messages. The HSM always includes a time-stamp in every signature it generates, which makes it possible to detect replay attacks. The decryption function is mainly used by the pseudonym handling application that receives the anonymous certificates in an encrypted form from the pseudonym provider. Device management and long-term key updates are achieved through signed commands from the CA. In order to verify the signature on these commands, the HSM stores trusted root public keys that are loaded into the device during the initialization procedure in a secure environment. We envision two such root public keys K1 and K2 in the HSM with corresponding private keys held by the CA. The CA commands can include revocation of the entire device. The revocation of the HSM is achieved by a signed kill command that deletes every piece of information from the memory, making the device unusable.

4.3.4 Revocation
The certificates of faulty nodes have to be revoked to prevent them from causing damage to the VC system. Revocation can be decided by the CA from administrative or technical reasons. The basic mechanism to achieve this is certificate revocation lists (CRLs) the CA creates and authenticates. The challenge is to distribute the CRLs effectively and efficiently and this has also been discussed in related work like [12] and [13]. The size of CRLs and the overall amount of revocation information to be distributed is still a challenge. At first, collaboration between CAs so that CRLs contain only regional revocation information can keep the CRL size low. Revocation can leverage on the HSM with the CA initiating the revocation of the HSM protocol, issuing a kill command signed with the 28

Alexandru George tefnescu Security Framework for Mobile VANETs private key corresponding to one of the root public keys. If an HSM receives a kill command, it deletes everything from its memory including its own private keys, to prevent the generation of any new keys or signatures by the compromised module. The CA determines the vehicle position and sends it the kill command using the nearest road side unit. If the adversary controls the CA-HSM communication, CRL-based revocation has to be performed. This can also be done via the Revocation using compressed certificate revocation lists protocol, which can reduce the size of CRLs by a loosely compression scheme. The inclusion of credentials in a CRL implies that the CA has established the need to revoke the node. If this is because of faulty behavior, the absence of an omnipresent monitoring facility makes detection harder. Moreover, CRLs will be issued rather frequently, thus leaving a vulnerability window until the node is revoked.

4.3.5. Secure communication

4.3.5.1 Secure Beaconing Beaconing denotes periodic single-hop broadcasts typically used for so-called cooperative awareness applications. In order to create awareness of other vehicles in the vicinity, every beacon contains information of the sender's status such as vehicle position, speed, and heading. The frequency of beacon packets is expected to range from about 10 to 1 Hz for most use cases. Beacon messages are digitally signed and the signer's certificate is attached. These measures achieve four goals. First the receiver of a beacon message can verify that its sender is a valid participant of the VC system (either vehicle or road site unit). Second, no node can impersonate another node without compromising its HSM. Third, the integrity of the message is protected, as manipulations are detected if the signature is invalid. Finally, the use of a geographic stamp (geostamp) along with the signature allows for the detection of replay attacks. 4.3.5.2 Secure Neighbor discovery Cooperative awareness or safety messaging allow vehicles to discover a frequently updated view of the other vehicles in proximity. The other vehicles are also called physical neighbors. Also, two nodes are considered communication neighbors if they are directly reachable. Typically it is assumed that if two nodes are communication neighbors, they are physical neighbors and vice versa. The main idea is to estimate the sender-receiver distance based on the system's own coordinates, and the location in the received message and time of flight. 29

Alexandru George tefnescu Security Framework for Mobile VANETs 4.3.5.3 Secure Geocast The range covered by one-hop beaconing is often not sufficient, and information on events such as accidents need to be disseminated in relatively large areas. This is achieved by Secure Geocast (idea that was proposed in related work [12]) which uses three elements: addressing of a geographically defined destination region forwarding toward this region distribution of the packet within the destination region Position based routing (multi-hop or single-path forwarding of packets toward a geographically forwarding of packets toward a geographically defined destination) has been shown to be well suited to the dynamics of VANETs and is realized by greedy routing protocols such as GPRS or CGGC. As a basic security measure for both position-based routing and message distribution, source nodes sign created messages and then attach the corresponding certificate, similar to the functionality of secure beaconing. As beaconing is the basis for position-based forwarding decisions, the location given in beacons can be forged, with data delivery failures and an increase network load. We propose a position verification approach, based on plausibility heuristics, which is capable of detecting such position falsification. Second, changing pseudonyms for privacy reasons lead to increased instability in nodes' neighbor tables. This can result in transmission faults to the next hop, because a node is not reachable after a pseudonym change, which deteriorates routing performance. 4.3.5.4 Pseudonym Handling An adversary analyzing which certificates are attached to signed messages can track the location of vehicles over time. As the adversary could use information from other layers of the communication stack to track vehicles, a change of pseudonym should be accompanied by a change of the vehicles identifiers in underlying protocols as well. The general idea of mix zones is based on the following idea: if only one vehicle changes its pseudonym in a mix zone, an adversary observing vehicles entering and exiting the region would trivially track vehicles because of one pseudonym has changed. But if more than one vehicle changes their pseudonyms in a mix zone, the adversary should consider 30

Alexandru George tefnescu Security Framework for Mobile VANETs every possible match for entering and exiting vehicles, and should estimate the most likely matches given its belief about the mobility of vehicles, the time to traverse the mix zone and the geometry of the mix zone.

4.3.6 In-vehicle security

In order to achieve their full potential, VC systems need to access to the in-car network and sensors that observe the current status of the vehicle and the environment. This enables a VC system to process signals such as emergency breaking airbag activation and slippery road detection, thus greatly contributing to the avoidance of accidents improvement of road safety. Usually, the network architecture and in-car gateways restrict the signals to the defined network segments and prevent information from leaving its dedicated domains. If a change would be done into a more open architecture by allowing for reading out sensor information from invehicle networks or displaying and reacting to warning messages from external sources, it would be absolutely necessary to ensure that invehicle systems are protected from any external malicious influence. Also, within the in-vehicle security model two main components are provided: A firewall that controls the data flow from external applications to the vehicle and backwards. An intrusion detection system (IDS) that constantly monitors the status of in-car systems and provides real-time detection of attacks.

31

Alexandru George tefnescu Security Framework for Mobile VANETs 4.4 DESIGN PRINCIPLES Many proposals to address security for VC are extended to be devised. Nevertheless, security mechanisms and protocols to safeguard the system operation eliminate adversarial behavior will in general differ in functionality. Therefore, the following list contains a set of principles that could be used in the design of the VANET. The important ideas of the design principles can be found in related work [14]. Default network access: messages are by default accessible to all nodes that can receive them Locality and timeliness as privileges : applications are context-aware and only in the vicinity of a node to a location or an action to a point in time may enable specific action Visibility of events: an attestation of an event by an individual node requires that the event be visible to the attesting node Mandated mediation: all actions that change the security state of the network are mediated by a network authority. Accountability: all messages or protocol executions that affect the network operation are audible by authorities. Vehicle autonomy: node actions and operations that do not require mediation are autonomous with respect to those of other nodes. Separation of privilege: reliance on multiple authorities and the separation of the roles of authorities and infrastructure. Staged response to faulty behavior: calls for a system design with a multilevel escalating response to faults. Reconfigurability: is a principle that applies to the on-board software and firmware. Privacy conservation: vehicular communication should not become a weak link in terms of privacy, providing users at least with the same level of privacy that is currently afforded without the implementation of VANETs. Usability: calls for ease of the user to access and utilize the vehicular communication system, as well as to utilize the information it provides. 32

Alexandru George tefnescu Security Framework for Mobile VANETs

4.4.1 Vehicular Public Key Infrastructure and Authentication

The huge number of vehicles registered in different countries and traveling long distances, well beyond their registration regions, requires a robust and scalable key management scheme. Communication via based stations needs to authenticate themselves not only to base stations, but also to each other which creates a problem of scalability. Therefore, the use of public key cryptography is a more suitable option for the deployment of VC security. This implies the need for a Vehicular Public Key Infrastructure where certificate authorities will issue certified public/private key pairs to vehicles. Similarly to current vehicle registration authorities, there will be several certificate authorities, each corresponding do a different region. Other candidates for taking the role of certificate authorities are car manufacturers. In any of the two cases, the different CAs will have to be cross-certified so that vehicles from different regions or different manufacturers can authenticate each other. The fundamental security functions in VC will consist in authenticating the origin of a data packet. To authenticate each other, vehicles will sign each message with their private key and attach the corresponding certificate. Therefore, when another vehicle receives this message, it verifies the key used to sign the message and once this is done correctly it verifies the message itself. Last important part of authentication is that given the frequency of safety message broadcasts (approximately every 300 ms) a vehicle can easily ignore redundant messages. Vehicular Public Key Infrastructure and Authentication are two of the many solutions that are proposed to help vehicular communication. Some of these solutions can leverage on existing solution techniques. Vehicular communication represents a high-risk domain for those that want to deploy and use it, therefore managing risks and controlling the network represents one of the key aspects in this theory's success. The unique security challenges that imply deploying such a network are mostly induced but the high speed and sporadic connectivity of the vehicles, the high relevance of their geographic location and also the privacy and trust aspect. Through a careful investigation of the literature, we find that important aspects of the VPKI and authentication can be found in [14] III, IV, V, VI and [15].

33

Alexandru George tefnescu Security Framework for Mobile VANETs 4.5 PRIVACY AND TRUST

4.5.1 Authorities and Privacy enhancing mechanisms

Drawing from the analogy with existing administrative processes and automotive authorities a large number of certificate authorities (CAs) will exist. Each of them is responsible for the identity management of all vehicles registered in its region. The deployment of secure vehicular communication is also influenced by the hierarchical structure within each CA and cross-certification among CA (secure vehicular communication could still be handled locally to a great extent). At the same time, vehicles registered with different CAs can communicate securely in the network as soon as they validate the certificate of one CA on the public key of another CA. The deployment of such networks emphasize that CA manages longterm identities, credentials and cryptographic keys for vehicles. As a basic guideline that can be found in [14] III and IV, processes and policies for privacy protection should be defined, with minimum private information disclosure on a need-basis and fine-grained control mechanisms for regulating private information disclosure. Nonetheless, signed messages can be trivially linked to the certificate of the signing mode: thus, the removal of all information identifying the user from node certificate does make communication anonymous. Yet, as the vehicle can change pseudonyms, linking messages signed under different pseudonyms becomes increasingly difficult over time. The change of a pseudonym should be accompanied by a change of the node identifiers used by underlying networking protocols. If such identifiers do not change along with the pseudonym, messages generated but a node could be trivially linked according to the address used by the node's hardware and software. On the other hand, the network operation may require that node identifiers remain unchanged for a specific period of time. This implies that a change of pseudonym would be ineffective and thus meaningless throughout the period a protocol identifier must remain changed.

4.5.2 Trusted Components

Implementing security for vehicular communication requires the vehicle to be equipped with a Trusted Component (TC). Many vehicles are already equipped with components, such as speed limiters and event data recorders (EDRs), considered critical by manufacturers and legislators. We assume that nodes are equipped with a trusted component such as tamper-resistant hardware and firmware, as described in [15]. 34

Alexandru George tefnescu Security Framework for Mobile VANETs The main role of the TC is to store sensitive cryptographic material such as private keys and to perform cryptographic operations using that material. For this reason, the trusted component must have a processing unit, a memory module and some non-volatile storage. Note that having a trusted component clock is indispensable as otherwise the TC would be coerced to produce cryptographically protected beacon messages in the future that can later used to mislead other vehicles. Another important aspect is that one could include the positioning system and the other sensors of the vehicle within the trusted component, this being indispensable as long as the trusted component is equipped with its own trusted clock. It is required that the trusted component to be psychically protected against tampering. It is desired that the psychical protection of the trusted component also ensures some level of tamper resistance. The trusted components could still be fed with incorrect positioning information data, but the attacker must do this in real-time, which is considerably more difficult. In particular, not having unsupervised access to the vehicle constantly, the attacker must install some rogue equipment inside the vehicle that feeds the TC with corrupted position information and other fake data. Finally, analyzing the trusted components experts note that tamper resistant devices can be compromised by exploiting weakness in their API, a software layer that provides access to the functions of the device for applications running outside of the device.

4.5.3 Revocation Game

For the deployment and implementation of vehicular communication there are many models, one of the most interesting and effective ones is the game-theoretic model. The key point of the game-theoretic analysis is to consider costs when making a revocation decision. In fact, many security protocols proposed in the literature are often evaluated by their capability to cope with or to completely remove attackers, as described previous sections. There are three revocation strategies for each node based on the existing protocols, as discussed in related work [16] 3 and 4. First, player x can abstain from the local revocation procedure by playing A. This strategy assumes that player x is not willing to contribute to the local revocation procedure and instead expects other player or eventually the CA to revoke the attacker. Second, player x can participate in a local voting procedure by casting a vote v against a detected attacker. Finally, following the protocol suggested, the self-sacrifice of the player is allowed. The main downside of these strategies is that a strategic attacker may optimize the usage of these strategies to revoke benign nodes. The model of the revocation problem is using a finite dynamic game G with the wireless devices as players. Our choice of dynamic games is based on the sequential nature of the wireless channel access where the 35

Alexandru George tefnescu Security Framework for Mobile VANETs section of one player is conditioned by the action of the preceding player. Each level of the tree represents a stage of the game. There are n benign nodes in one game and m attackers in total. We assume that the number of nodes with detection capabilities is defined by the probability of the detection of nodes. All costs for this model are represented in terms of keys and any cost has two parts: the cost induced by the attacker and the cost of participation in revoking the attacker. Different methods for the revocation game are the following, as suggested in [16] 4. Games with fixed costs: the attacker causes a fixed cost if not revoked. Games with variable costs: the attacker-induced cost can increase in each stage there the attacker is not revoked Optimal number of voters: revocation takes place by voting. These methods are implemented in protocols such as RevoGame Protocol which is based on the rules of the different rules of the three methods.

4.5.4 Cryptographic mix-zones and mix-networks

Anonymous systems aim at increasing the adversary's workload to uniquely identify the author of an action. The idea of mix-zones is to prevent the adversary from accessing the content of safety messages, including the vehicle's signatures that are trivially linkable to the corresponding pseudonyms and thus be unable to connect two pseudonyms successively by the same vehicle. Because the highest mixing of vehicles occurs at road intersections where the speed and direction of vehicles change the most, the main thing that the concept of mix-zones proposes is that all vehicles participate in the process of transforming every road into an anonymous one. Since the location of mix-zones is fixed, the adversary can identify them and thus could easily attempt to eavesdrop on transmission originating in the mix-zones area. To solve this problem, the CMIX protocol is introduced to create cryptographic mix-zones. The CMIX protocol requires the exchange of two messages. One or several key request messages are sent until either a Road Side Unit or a vehicle receives it. When a key request is broadcasted, potentially every vehicle in the transmission range could send back a key reply. In terms of security, the adversary is computationally bounded and unable to launch bruteforce cryptanalytic attacks on the mix-zones encrypted messages. 36

Alexandru George tefnescu Security Framework for Mobile VANETs In the context of vehicular networks, the CMIX protocol creates mixzones at road intersections. By connecting various mix-zones, we accumulate the anonymity achieved by each mix-zone and obtain a larger system referred to as a mix-network. The strength of the adversary depends on the information available to him: a weak adversary or a strong one. A mix-zone is an anonymous region that obfuscates the relation between entering and exiting vehicles. The adversary observes the timing and the location of the entering and exiting vehicles in order to derive a probability distribution over the possible mappings. Using mix-zones we can analyze the following adversaries: Weak adversary: is aware of the set of vehicles entering and exiting the mix-zone but not of their timing and trajectories, in other words is an adversary with a limited view of an intersection. Strong adversary: captures the location of events by gathering entering and exiting times and positions of vehicles.

4.5.5 Related mobile and wireless networking technologies

Considering identity management and privacy protection, it can be useful to look at standardized wireless communication technologies. We take cellular networks and GSM as an example. There are two forms of Ids in GSM; the first one being the International Mobile Subscriber Identity (IMSI) which identifies the subscriber and is stored in the SIM card. The database where cell phone providers keep information is called Home Location Register where the IMSI is connected to the subscriber data. Second, there is the International Mobile Equipment Identity (IMEI), which uniquely identifies the GSM equipment. All the identity management within a network is completely managed by the provider, including authentication and revocation. In case of roaming between providers, they grant access to their personal information so that authentication can take place. In cellular networks, the mobile nodes only attach and authenticate with the base stations of own or foreign providers. Therefore, authentication, generation and resolution of pseudonyms are straight-forward, the base station plus core network is considered to be trusted. This is not the case in VANETs, where cars communicate with each other or with infrastructure provided by multiple organizations who may not be considered trusted. Also an important aspect of the issue is that WLANs have to be considered according to IEEE 802.11. There are no identities in the core WLAN standard itself, with no exception of the unique MAC address used. Instead there is the option of using a shared key for accessing the 37

Alexandru George tefnescu Security Framework for Mobile VANETs network. Another important fact is that there is no real mechanism for privacy protection in WLANs, as MAC addresses are always sent in the clear. Finally, a number of approaches have been proposed for generic MANET(mobile ad-hoc network), which are neither standardized nor target necessarily specific applications. The development of VANET, with a more precise application context, not only allows to pose specific questions on identity management but also moves towards providing answers.

4.5.6 Faulty nodes

Recent research initiatives supported by governments and car manufacturers seek to enhance the safety and efficiency of transportation systems, as discussed in [20] I, II, III and IV. Integrating security mechanisms into VNs is critical for their deployment: their rich functionality and services can be otherwise abused, jeopardizing the safety of vehicles, drivers and passengers, as well as the efficiency of the transportation system. The presence of an authority known as CA is implied or mandated in practically all the research efforts concerned with securing VNs. Rigid identity and credential management processes for vehicles and drivers have long been in place; accountability and attribution of liability will continue to be crucial and access control mechanisms will be necessary. One of the most important questions in VANETs is the following: unless a node is revoked for administrative reasons how can the authority obtain and validate sufficient evidence that a node is faulty or compromised. Therefore, some combinations of methods is proposed: Infrastructure-based revocation protocols , the revocation of the trusted component and revocation using compressed certificate revocation lists When the CA decides to revoke a vehicle it first uses this protocol. The CA generates a revocation message that contains the vehicle's identity encrypted with its public key and timestamp. There are several options for channeling this message to the trusted component of the vehicle, one of them would be to route it to the road side unit closest to the vehicle, if its location is known to the CA. A misbehavior detection system (MSD) The MSD should rely not only on the protocol-specific actions of nodes but also on the data these nodes provide. Therefore, there 38

Alexandru George tefnescu Security Framework for Mobile VANETs are two types of misbehaviors: known ones (can be identified by monitoring specific parameters of node or network) and data anomalies (do not follow any known pattern). It should be noted that the MDS detects only nodes that are in its current neighborhood, based on their locations and timestamps. A local eviction of attackers by voting evaluators (LEAVE) protocol Being warned of the misbehaving nodes allows the observing vehicle to ignore any messages sent by these nodes. Vehicles that detect an attacker begin broadcasting warning messages to all vehicles in range. The latter can use this information as input to their respective MDSs. The final step is to report attackers or faulty nodes to the CA as soon as possible. The eviction of faulty or attacking nodes is crucial to the performance of vehicular communication systems. To eliminate the vulnerability window, due to latency for the authority to identify faulty or misbehaving nodes and distribute revocation information, the three methods are a solution. The deployment of these methods is done with the help of a misbehavior detection module and a distributed eviction protocol.

39

Alexandru George tefnescu Security Framework for Mobile VANETs 5 IMPLEMENTATION DETAILS With the application for this project we implement a system that can stop certain attacks using the Openmoko open-source smart-phone. We presume that the attacks have a only one communication direction, meaning that we only analyze the communication from the phone to the VANET. In the next sections we will describe the phone and the API that we are using for the application as well as the architecture and the implementation. 5.1 OPENMOKO Openmoko is a project dedicated to delivering mobile phones with an open-source software stack. Openmoko is currently selling the Neo FreeRunner phone to advanced users and will start selling it to the general public as soon as the software is more developed. For proving the importance of security in VANETs, we decided to use this smart-phone which is the open-source equivalent of an iPhone. Being an open-source software phone its operating system is Linux based. The phone comes with a series of basic applications that can be upgraded and/or updated with open-source software developed by the Openmoko community. Neo FreeRunner allows users to customize the phone platform to their needs, modify existing software, and create or install any additional software.

Figure 5. Openmoko phone and iPhone 40

Alexandru George tefnescu Security Framework for Mobile VANETs

5.1.1 Phone specifications

For a better understanding of the phone this section is dedicated to the technical specifications. As a conclusion we can clearly see the Neo FreeRunner is an intelligent phone that can compete at a technical level with and closed-source phone, like an iPhone. The Openmoko phone has a lot of features; therefore the user has a large range of applications from which he can choose. 5.1.1.1 Size and weight - 120.7 x 62 x 18.5 mm and 133 grams 5.1.1.2 Display - Touch screen (2.8'' VGA (480x640) VGA Screen) 5.1.1.3 Speed - ARM @ 400 MHz and 2D/3D Graphics Acceleration 5.1.1.4 GSM - Tri band 850/1800/1900 Mhz and Tri band 900/1800/1900 Mhz 5.1.1.5 Power - Removable 1200 mAh battery 5.1.1.6 Memory - 128MB SDRAM, 256MB NAND Flash, microSD slot 5.1.1.7 Input and Output - 2.5 mm audio jack and GPS external connector 5.1.1.8 Hardware and software features - WiFi (802.11b/g), AGPS, GPRS, Bluetooth 2.0 and 2 x 3axis Motion sensors and open-source and Linux-based operating system andGNU/Linux development tools

41

Alexandru George tefnescu Security Framework for Mobile VANETs After the closer look at the phone specifications we can clearly say that the Neo FreeRunner is a Linux-based touch screen smart phone ultimately aimed at general consumer use as well as Linux desktop users and software developers.

5.1.2 Open source software distributions

Openmoko distributions are design to run on various mobile devices, with the primary aim of supporting Neo 1973 and Neo FreeRunner phones. Thes distributions are GNU/Linux based distributions and represent complete operating-systems that include user applications. A very important aspect is that stable in the FreeRunner world does not mean the same thing as stable in the Debian world. Most distributions use the same bootloader, kernel, drivers and hardware. therefore, the same low level bugs are commonly found in all distributions. Most of these distributions also have package repositories. It is a bad idea to feed from another distribution's repository. The most important distributions that can be used with the Openmoko phone are the following: Om2007.2, Om2008, Om2009 and also other distributions developed by the community. 5.1.2.1 Om2007.2 Om 2007.2 is one of the many distributions that currently work on the Openmoko phones. The main goal of distributions is the same as the distributions for a normal computer. It gives the phone all the software needed for operating. Om 2007.2 was the second version of the Openmoko distribution. This distribution is not developed anymore and has been replaced by Om2008 described in the next section. The interface of this distribution was totally finger-oriented, optimized for 285ppi and orange. It used the GTK stack, which is part of the GNOME Mobile Platform. Goals of this version were an improved set of PIM applications, improved theming that fixes a lot of the usability problems of the first generation design, more formalized UI guidelines and a number of changes in the build system.

42

Alexandru George tefnescu Security Framework for Mobile VANETs 5.1.2.2 Om2008 Om2008 is one of the many distributions that currently work on the Openmoko phones. You can compare a distribution with an Operating System on normal computers. It gives the phone all the software needed for operating. Om 2008 uses Enlightment Foundation Libraries (EFL) for the launcher, custom UI applications and Qtopia on X11 for telephony. The distribution was the first step from GTK+ on X11, which was used on Om7.1 and Om7.2 to using multiple toolkits in combination. Compared to 2007.2 that had a longer development history, Om 2008 was definitely a major release. 5.1.2.3 Om2009 Om2009 is the current version of the official Openmoko distribution. The latest release of OM2009 is testing5 from June 16th, 2009. Om 2009 is based on freesmartphone.org (FSO) framework and uses Paroli as the telecommunication software. Om2009 testing already has all the features most people need for daily phone usage: SMS, calling, phone book, call log, charging, suspend & resume, wifi gui, audio profiles, etc. Om2009 is still currently under development and once fully developed should replace Om2008 described in the above section. 5.1.2.4 Openmoko community - other important distributions

Android is a software stack for mobile devices developed by the The Open Handset Aliance. Openmoko is fully supporting Android running on the Freerunner. Android has now reached a point where it is usable on the FreeRunner as an everyday phone, there are, however, still some caveats. Check out the main Android section of the wiki for more info. Debian is considered "the universal operating system". It comes with thousands and thousands of packages (most of them designed for desktops or servers so far).
When installing Gentoo, you can choose how much you want to compile yourself, how to install Gentoo, what system logger you want, etc. Gentoo is a fast, modern metadistribution with a clean and flexible design. Gentoo is built around free software and doesn't hide from its users what is beneath the hood. Portage, the package maintenance system which Gentoo uses, is written in Python, meaning you can easily view and modify the source code. In the year 2009, the default preinstalled distribution is Om2009 that is based on the freesmartphone.org framework. We used the Om2009 distribution. The distribution integrates Qtopia phone stack with a set of new Openmoko applications based on the Enlightenment Foundation Libraries (EFL).

43

Alexandru George tefnescu Security Framework for Mobile VANETs 5.2 SOLUTION TO ATTACKS The starting point of the application is based on the attacks described and implemented in related work [1]. In that paper the author designed several attacks that can damage the communication in a VANET, using the same smart-phone as described in section 5.1. The attacks represent a simple way to demonstrate that VANET security is fragile at this point and also that further work is needed in securing this type of networks.

5.2.1 Attack scenarios

The following attacks were implemented:

The first attack has the purpose to find the path that the person is following sending an SMS every X minutes, where the variable X is set in the virus. The second attack has the purpose to find all the persons with Bluetooth devices in the proximity of the attacked phone. The third attack has the purpose to make a phone call on the attacked phone, at a specific day and hour, predefined in the virus. The fourth attack has the purpose to make the phone display black, so the user cant use the device until he connects the phone to a terminal and reset the phone brightness to the initial one.

The attack scenarios were implemented using the Openmoko Dbus, a message bus which provides a simple way for applications to talk to one another and be available as services. Also, for the implementation of the attacks the author used Python and the phone given API to implement the new services as described in [1] 6. We assume that we already have access to the phone, which means that the viruses and the antivirus can be simply run like other applications. The purpose of this project is to try an implemented antivirus on Openmoko, and the ways of phone access could be the subject of a future work. Also, another important aspect taken into consideration in the implementation of the attacks is the security of the smart-phone. Openmoko uses a Linux-based operating-system and has a few security leaks like the no password option while trying to connect through ssh.

44

Alexandru George tefnescu Security Framework for Mobile VANETs

5.2.2 Solution - architecture

The solution is based on using the smart-phone resources, the programming language Python along with Linux bash scripting and also the implementation of the attacks that can be found in related work [1]. The architecture of the application is based on real life situations. The user has complete access to a phone (user interface and command line) and on that phone there are viruses and an antivirus. In real life situations, a system is compromised if an attacker tries to execute harmful programs on the attacked system. In this case, the antivirus takes into consideration all of the known cases and stops the viruses from compromising the smart-phone.

Figure 6. Application architecture overview This project develops the application using as a starting point the following assumptions:

The application is installed on the smart-phone and runs in userspace. The attacks can be local (installed on the smart-phone) or distributed, using SSH connection from another machine. The application allows the files to be copied on the smart-phone but stops any script that can harm the communication of the phone with the VANET. The application is design to be used in the command line interface (CLI) and also can be adjusted in further work to use the graphical user interface with the usage of Enlightenment graphical module. 45

Alexandru George tefnescu Security Framework for Mobile VANETs

The application contains a command line menu in which the user select the running option of the antivirus. The application is developed in Python and contains:

Parser module: parses the Python script that is considered to be harmful. This module is based on keyword search and after analyzing the Python script decides if the script is a virus or not. Finding the script module: runs a Linux command that searches periodically Python scripts that run on the smartphone. It also verifies if the scripts are running at that time comparing the process start time with the current system time. Once a Python script besides the ones used by the antivirus is found, it is saved in a list. Stopping the script module: if there is a saved script, this module pauses the execution of the scrip, uses the parser module to find out if the script is a virus and decides if the execution is continued or if it is killed. Eliminating the virus module: after discovering a virus on a smart-phone this module moves it into a folder named quarantine and has the option of modifying the rights to that file. If the user explicitly wants the file to be deleted from the system, this module can delete the file after moving it in the quarantine folder.

5.2.3 Solution - implementation

The application was written using Python and Linux bash scripting and the main reason for that is rapid prototyping nature of Python combined with Linux bash scripting. For such an application there is a real need for faster response to possible viruses, therefore we chose the fastest way to implement such an antivirus in user-space using the phone's resources in the most efficient way possible. The implemented files are described in the next sections. Also, from the distributed point of view the attacks will run from the attacker's machine, without explicit connection to the smart-phone. The commands are sent through ssh connection, first the harmful files are copied on the attacked system and after the attacker tries to execute them on the attacked smart-phone. 46

Alexandru George tefnescu Security Framework for Mobile VANETs 5.2.3.1 Parser module This module parses the Python script that is considered to be harmful. The verification is made using a known dictionary of keywords.
NO_PY = -1 NO_VIRUS = 0 DISPLAY = 10 GSM_SMS_1 = 11 GSM_SMS_2 = 12 GSM_CALL = 13 GPS_POS = 14 #no python script #no python virus #black display #sms virus 1 #sms virus 2 #sms call #gps position virus

The main function of this module is based on the following steps: 1. Opens the suspected file:
if numeFisier != "parser.py": f = open(numeFisier, 'r') text = f.readlines() f.close()

2. Checks the file line by line and looks for the known keywords (the keywords are based on the smart-phone API)
cuvinteCheie = ['Device.Display', 'GSM.SMS', 'GSM.Call', 'Gypsy.Position']

3. For every file that is a Python script and for every line that is not a commented one in the suspected file the parser module checks the keywords and decides if the file is a virus. If none of the known keywords is found, the parser module decides that the analyzed script is not a virus and return the NO_VIRUS code.
# checks out if the file is a Python script if scriptPy == 1: for line in text: # if the line is NOT a comment if line.rfind("#") == -1: for cuv in line.split(): if cuv.rfind(cuvinteCheie[0]) != -1: return DISPLAY elif cuv.rfind(cuvinteCheie[1]) != -1 numeFisier.rfind("gps") != -1: return GSM_SMS_1 elif cuv.rfind(cuvinteCheie[1]) != -1 cuv.rfind("GPSD") == -1: return GSM_SMS_2 elif cuv.rfind(cuvinteCheie[2]) != -1: return GSM_CALL elif cuv.rfind(cuvinteCheie[3]) != -1: return GPS_POS else: return NO_PY return NO_VIRUS

and and

47

Alexandru George tefnescu Security Framework for Mobile VANETs 5.2.3.2 Finding the script module This module contains the following functions: A function to find out the exact time of the running process in the attacked system; runs the 'date' operating-system command and parses the output. The code for this function is the following:
string = commands.getoutput('date') for cuv in string.split(): if cuv.rfind(":") != -1: h = cuv.partition(":") oraSis = h[0] h1 = h[2].partition(":") minuteSis = h1[0] secundeSis = h1[2]

A function that checks if the exact time is the one that the presumed harmful process is running; returns true of the running time of the process is the correct one and false if not.
if oraSis == ora: if minuteSis == minute: return 1 else: return 0

A function that runs an operating-system command and parses the output of that command; also this function returns a list of Python scrips that will be analyzed by the parser module
string = commands.getoutput('ps auxwww | grep python') string1 = string.split("\n") for line in string1: print line if line.rfind("frameworkd") == -1 and line.rfind("paroli") == -1 and line.rfind("main") == -1 and line.rfind("grep") == -1: for cuv in line.split(): if cuv.rfind(":") != -1 and len(cuv)>4: oraRulare = cuv.partition(":") ora = oraRulare[0] minute = oraRulare[2] aflaOra() if cuv.rfind(".py") != -1 and verificaOra() == 1: temp = cuv.rpartition("/"); listaFisiere.append(temp[2]) if not listaFisiere: return 0 else: return listaFisiere[0]

48

Alexandru George tefnescu Security Framework for Mobile VANETs

A function that will find the PID of the suspected script. It runs the command pidof python and saves the PID in a list.
string = commands.getoutput("pidof python") for pid in string.split(): listaPiduri.append(pid) if listaPiduri[0] > listaPiduri[1]: return listaPiduri[0] else: return listaPiduri[1]

5.2.3.3 Stopping the script module This module contains one function def opreste(proces,pid) that verifies two arguments: the name of the running process and the PID of that process. The function has the following steps: 1. Pauses the process received as an argument for the function
if len(proces) != 0: cmd = 'kill -STOP '+str(pid) os.system(cmd) stopat = 1

2. Sends the name of the process to the parser module after pausing the execution of the presumed harmful script
if stopat == 1: print "\t\t[opresteProces.py] Aflu virusul." print "\t\t[opresteProces.py] Procesul "+str(proces)+" este stopat." parse = parser(proces)

3. If the process is not a virus this module resumes the execution of the script:
if parse != DISPLAY and parse != GSM_SMS_1 and parse != GSM_SMS_2 and parse != GSM_CALL and parse != GPS_POS: print "\t\t[opresteProces.py] sigur... Se continua executia." cmd = 'kill -CONT '+str(pid) os.system(cmd) stopat = 0 return 1

Procesul

este

49

Alexandru George tefnescu Security Framework for Mobile VANETs 4. If the process is a virus this module stops the script
elif parse == DISPLAY or # if the display keywords exist in the file parse == GSM_SMS_1 or # if the sms 1 keywords exist in the file parse == GSM_SMS_2 or # if the sms 2 keywords exist in the file parse == GSM_CALL or # if the call keywords exist in the file parse == GPS_POS: # if the position keywords exist in the file if parse == DISPLAY: print "\t\t[opresteProces.py] Virus la DISPLAY." elif parse == GSM_SMS_1: print "\t\t[opresteProces.py] Virus la SMS cu coordonate GPS." elif parse == GSM_SMS_2: print "\t\t[opresteProces.py] Virus la SMS simplu." elif parse == GSM_CALL: print "\t\t[opresteProces.py] Virus la CALL." elif parse == GPS_POS: print "\t\t[opresteProces.py] Virus la POZITIE GPS." print "\t\t[opresteProces.py] Proces care nu este sigur. Se inchide..." cmd = 'kill -9 '+str(pid) os.system(cmd) return 0

5.2.3.4 Eliminating the virus module This module contains several functions that have the final purpose to move the virus to a quarantine folder and has the options to change the rights to that virus or delete the file from the system after moving it in the quarantine folder. The module contains the following functions: 1. Find the path of the virus - implemented first for the simulation made on a normal computer and a version for the Openmoko smartphone. The function searches the path of the script in the Linuxbased file-system starting from the base point in which we presume that the virus will be copied: /home/root/. The function has one argument, the name of the Python script:
def gasesteCaleOM(proces): if len(proces) != 0: cmd = 'find /home/root/' string = commands.getoutput(cmd) string1 = string.split("\n") for line in string1: if line.rfind(str(proces)) != -1: print "\t\tCale virus: "+line+"\n" return line

50

Alexandru George tefnescu Security Framework for Mobile VANETs 2. Move the script into the quarantine folder this function has one argument def mutaInCarantina(cale): executes two commands, first we move the script in the quarantine folder located in /home/root/antivirus/quarantine/ and after that moves also the result text file in the same folder. The main idea behind the quarantine folder is that a normal user can delete all the files in that folder or just modify the rights of those folders so that they can not be executed by anyone else besides root.
if len(str(cale)) != 0: cmd = 'mv '+str(cale)+' /home/root/antivirus/quarantine/' os.system(cmd) cmd1 = 'mv /home/root/antivirus/rezultat.txt /home/root/antivirus/quarantine/' os.system(cmd1)

3. Change the rights of the file this function has two arguments: the name of the virus and the option (change rights or not) def scoateExecutieFisierVirusat(proces, optiune):. The function searches in the quarantine folder that can be found at /home/root/antivirus/quarantine/ and executes the command chmod with the arguments -rwx, meaning that anyone besides root can not read, write or execute the script.
if len(proces) != 0: if str(optiune) == 'da' or str(optiune) == 'yes' or str(optiune) == 'y': cmd = 'chmod -rwx /home/root/antivirus/quarantine/'+proces os.system(cmd) print "\t\t\t[eliminaVirus.py] Fisierului din carantina i-au fost modificate drepturile." if str(optiune) == 'nu' or str(optiune) == 'no' or str(optiune) == 'n': print "\t\t\t[eliminaVirus.py] Fisierului din carantina nu i-au fost modificate drepturile."

4. Eliminate the file from the Openmoko smart-phone this function has two arguments, the name of the virus and the option (delete the file or not). The function deletes the virus from the quarantine folder if the option is 'yes' and it is simular to the function described in the step 3. 5.2.3.5 Main module In this script the antivirus executes standard steps for each Python scripts besides the ones of the antivirus. Also, this main form connects all the modules together. The script is designed to run in a while cycle in which the following steps are executed:

51

Alexandru George tefnescu Security Framework for Mobile VANETs

1. Finding out if a suspect Python script is running on the system. 2. If there is such a process we continue to the next steps: We discover the PID of the process using the Finding the virus module described in section 5.2.3.2. We pause the process using the Stopping the virus module described in section 5.2.3.3. If the process is paused then we continue to the next steps: We find out the path of the script using the Eliminating the script module described in section 5.2.3.4. We move the script in the quarantine folder using the Eliminating the script module described in section 5.2.3.4. After moving the script in the quarantine folder we analyze the command line arguments and we decide what we do with the virus. We do so using options of the Eliminating the script module described in section 5.2.3.4.

After a virus is detected and resolved the script stops running and the user has to restart the application in order to have full protection over the system. The code to the main module is the following:
rulare = True while rulare: proces = aflareProces() if proces != 0: pid = aflarePID() continuareProces = opreste(proces,pid) if continuareProces == 0: cale = gasesteCaleOM(proces) mutaInCarantina(cale) if len(sys.argv) > 2: stergeFisierVirusat(proces, sys.argv[1]) scoateExecutieFisierVirusat(proces, sys.argv[2]) rulare = False else: rulare = False

5.2.3.6 Main menu The main menu of the application was written using Linux bash scripting. Using this module, the user can choose any option that the antivirus has implemented. The menu has the following options:
[1] Move in quarantine without deleting the file and without changing its rights [2] Move in quarantine without deleting the file and with changing its rights [3] Move in quarantine with deleting the file [4] View log file [5] Clean the application [6] View quarantine [7] Clean quarantine [8] Exit

52

Alexandru George tefnescu Security Framework for Mobile VANETs The user chooses one option at a time and after running the selected option the screen cleans, forcing the user to press ENTER and select another option. The menu will run from the smart-phone while the virus menu will run from the attacker's system. While designing the architecture of the application we presumed that the antivirus will be running before the virus tries to attack the smart-phone. 5.2.3.7 Viruses As described in the previous sections, the viruses are small Python scripts (user-space applications) that execute commands on the smartphone without the users knowledge. Taking into consideration this detail, a delay of 5 to 10 seconds must be inserted in the code of the viruses so the execution will not be instant. The delay was calculated analyzing the smart-phone's resources and the architecture of the antivirus application. Therefore, in this project we presume that the execution of the virus is not instant. The only way that the antivirus can catch the viruses while they are running is if the time of the execution is larger than the time it takes the antivirus to monitor the processes running. Also, the viruses after their successful execution print a message that is redirected in a text file. The text file and the script file are moved together in the quarantine folder after the execution of the application.

5.2.3.8 Running the application and stopping the viruses The application has been designed as a simple one that contains a menu for the antivirus as well as for the viruses. First of all the project contains several additional bash scrips for cleaning the project, creating the folder structure, connecting to to smart-phone and also two different menus. In order to simulate the different behavior for each participant in the network, we will use separate command shells. Actions for the normal user that runs the antivirus application: 1. Connecting to the smart-phone.

The connection to the smart-phone is a script that repeats the SSH connection command under the root user from the first machine. We can see that the smart-phone has no password and we can establish the connection just pressing ENTER.

53

Alexandru George tefnescu Security Framework for Mobile VANETs 2. Once connected to the smart-phone, the user has to create the folder structure and has to copy the antivirus application.

3. Running the antivirus and choosing one of the options described in the previous sections.

4. Running the viruses from a different system.

54

Alexandru George tefnescu Security Framework for Mobile VANETs 5. The attacker tries to run a virus; The antivirus stops the virus On the smart-phone:

On the attacker's system:

55

Alexandru George tefnescu Security Framework for Mobile VANETs 6 RESULTS The project results are given by a series of tests that can be made on the smart-phone. In this project we take into consideration two different aspects: how to infect a smart-phone and what are the performances of the implemented antivirus. By default, Openmoko phones have only one user (root) and no password for it, and a default IP address. This means the phone can be access through SSH with user root and password . In this project we consider that the default way to access the smart-phone is through ssh connection. There are also some ways to infect the phone with a virus. A virus can get to the phone memory being downloaded from a mail attachment or being downloaded from a server with different kinds of data. GSM is also a way to infect the phone. A received SMS message can have an attachment containing a virus. Through SSH, the phone can be simply infected copying the virus and executing it and this is the way the viruses are executed in the case of this project. The second aspect of the application is represented by the performance of the system while the application is being executed and if the viruses are stopped from harming the smart-phone system. Following the steps described in the previous section we can observe that the viruses are stopped from executing and therefore affecting the smartphone. The hardware performance of the system while the antivirus application is running are similar from the one without the application running. The operations of the application do not represent complicated ones, which means CPU, memory or battery performances are similar with the ones when the antivirus is not running. We consider the following results using the top command: When the antivirus is not running:

When the antivirus is running (normal mode):

56

Alexandru George tefnescu Security Framework for Mobile VANETs After comparing the output of the top command in the two cases we can observe that the maxim CPU usage reaches approximately 50%, which is a normal value. Also, the User-interface is responsive while the antivirus is running, calls can be made, SMS texting is available and the overall performance of the smart-phone is not affected. Therefore, we can affirm that the antivirus is somewhat invisible from the normal user's point of view. In the tables bellow we analyze the CPU and memory usage of the antivirus. First, we measure the CPU usage in the first 3 seconds of one of the three states: Antivirus not running (blue) Antivirus running normal without any processes to analyze (orange) Antivirus killing a virus (yellow)
3s

2s

Antivirusnotrunning Antivirusrunning normal

1s

Antiviruskillinga virus

0s

10

20

30

40

50

60

Table 1. CPU usage Also, another important aspect is the memory used by the smartphone. From a total of approximately 128MB (128000KB) the smartphone's memory usage reaches at its peak a maximum of approximately 81294KB.

Antivirusnotrunning Antivirusrunning normal Antiviruskillinga virus

Memory

76000

77000

78000

79000

80000

81000

82000

Table 2. Memory usage (KB)

57

Alexandru George tefnescu Security Framework for Mobile VANETs

Antivirusnotrunning Antivirusrunning normal Antiviruskillinga virus

Memory

37000

38000

39000

40000

41000

42000

43000

Table 3. Free memory (KB) The only disadvantage of the application is that the running time is larger because of the delay added in the code of the virus. Therefore, for a full simulation of the application and its results the time of stopping a virus is somewhere between 3 seconds and 7 seconds. The explication for this fact is that the application needs enough time to execute all of its operations and the virus has to stay alive the whole time while the applications executes those operations. The application can be developed also with the use of the Openmoko user-interface features, using Enlightenment graphic libraries. Also, specific solutions can be added to the application. For example, if there is a SMS virus trying to execute some forbidden operations, the antivirus could stop the sending SMS service. This solution was not preferred in this project because we tried to develop an generic solution to all of the viruses known until now. Each module of the antivirus has a series of important operations that have a certain cost that has to be taken into consideration. The parser module opens the virus file and parses its code. The finding the script module uses the CPU the most, having to check the output of a ps command. The main disadvantage of the use of this method is that it takes a serious amount of time to recheck the output of the command. From testing the application, we reached to the conclusion that in 5 seconds this module makes 4 checks of the ps command's output. We also can affirm that the key point of the application is the system monitor implemented in this module because it constantly verifies of a virus is running. If there is a suspicious file trying to run on the system, this module sends the responses to the other modules, in order to stop the presumed virus. Stopping the virus module executes several operations that are important: pausing the presumed virus, interaction with the 58

Alexandru George tefnescu Security Framework for Mobile VANETs parser module, receiving and interpreting the code from the parser module and also deciding if the script is a virus or not. Once that decision is made this module stops or continues the execution of the script. These are all important operations that also slow down the performance of the application. While testing with a script that is not a virus, the normal delay is approximately 1 second. Eliminating the virus module checks the option of the user and chooses if the file is deleted or if its rights are changed. Also, the module finds out the full path of the virus taking into consideration the output of a find command. These operations are executed once and therefore the performance of the application is not affected. The main module is the one that connects all the other modules and that runs the antivirus. The operations of this module have been explained in the above paragraphs. The antivirus menu consists in the execution of the main module with the choices the user makes. The operations have been described in the above paragraphs.

The costs of the viruses have been discussed in [1] 7 and will not be analyzed in this paper due to the fact that the presumed attacker tries to execute the viruses from another system than the smart-phone.

59

Alexandru George tefnescu Security Framework for Mobile VANETs 7 CONCLUSIONS AND FUTURE WORK In this document, we demonstrated the need for security in vehicular networks (VANETs), and why this problem requires a specific approach. We proposed a model that identifies the most relevant communication aspects and then we identified the major threats. Besides all of these aspects, in the project we implemented an antivirus application that is specific for Linux-based operating-systems, like the one used by the Openmoko smart-phone. For demonstrating the VANET vulnerabilities we implemented several possible attacks designed with the generality in mind. We demonstrated the vulnerability of not only VANETs, but of currently existing smartphones as well. Using these attacks the antivirus application is the implementation of a security level on the real life smart-phone. Using the steps in the design of the application, similar antivirus systems can be implemented in other operating-systems like Windows Mobile or Macintosh OS. The results of the project are the following: The viruses are not allowed to execute harmful operations while the antivirus is running and therefore the attacker is stopped. The resources of the phone are used at maximum 50% capacity, especially the CPU and memory. The smart-phone's primary functions are not affected by the application's execution. In order to simulate a VANET attack, we presumed that the viruses are being executed from a different system and that the attacker has access to the smart-phone. The solution for the security problem is a global one, valid for all the known types of viruses using a keyword dictionary. In this project we decided to find a global solution to the security issue regarding viruses in VANETs. Future work regarding this project is represented by the following aspects: The use of the user-interface with the integration of Enlightenment graphic features. The development of modules that analyze the ways that the viruses are copied and executed on a smart-phone. Given the initial assumptions of the project, a larger database using the smart-phone's API should be integrated on the system. Also, in future work specific solutions for specific attacks should be developed using the smart-phone's API and resources.

60

Alexandru George tefnescu Security Framework for Mobile VANETs 8 REFERENCES [1] O. Gavril, Security in VANET, Politehnica University of Bucharest, 2009 [2] M. Raya and J. P. Hubaux, Security aspects of inter-vehicle communications, Conference paper STRC 2005 [3] J. Luo and J. P. Hubaux, A survey of inter-vehicle communication, School of computer and communication sciences, Switzerland, 2004 [4] IEEE Computer Society, The Security and privacy of smart vehicles, 2004 [5] M. Raya, A. Aziz and J. P. Hubaux, Efficient secure aggregation in VANETs, School of computer and communication sciences, Switzerland, 2006 [6] S. Eichler, C. Schroth, J. Eberspacher, Car-to-car communication, Institute of communication networks, Munchen Germany, Institute of media and communication management, Switzerland, 2007 [7] M. Raya and J. P. Hubaux, Securing vehicular ad hoc networks , Laboratory for computer communications and applications, School of computer and communication sciences, Switzerland, 2005 [8] M. Raya and J. P. Hubaux, The security of vehicular ad hoc Networks, Laboratory for computer communications and applications, School of computer and communication sciences, Switzerland, 2006 [9] M. Gerlach, A. Festag, T. Leinmuller, G. Goldacker and C. Harsch, Security architecture for vehicular communication, Fraunhofer institute for open communication systems, 2008 [10] A. Baliga, V. Ganapathy, L. Iftode, Automatic inference and eforcement of kernal data structure invariants, Department of computer science Rutgers University, 2008 [11] M. Raya, P. Papadimitratos and J. P. Hubaux, Securing vehicular communications, IEEE, 2006 [12] P. Papadimitratos and J. P. Hubaux, Secure vehicular communication systems: Design and architecture, IEEE, 2008 [13] P. Papadimitratos and J. P. Hubaux, Secure vehicular communication systems: Implementation, performance and research challanges, IEEE, 2008 61

Alexandru George tefnescu Security Framework for Mobile VANETs [14] P. Papadimitratos and J. P. Hubaux, Securing vehicular communications assumptions, requirements and principles, IEEE, 2006 [15] M. Raya, P. Papadimitratos and J. P. Hubaux, Architecture for secure and private vehicular communications, IEEE, 2008 [16] M. Raya, M. Hosssein Manshaei and J. P. Hubaux, Revocation games in ephemeral networks, ACM, 2008 [17] M. Raya, P. Papadimitratos, J. P. Hubaux and V. Gligor, On data-centric trust establishment in ephemeral ad hoc networks, EU project SEVECOM, 2007 [18] J. Freudiger, M. Felegyzahi, M. Raya, P. Papadimitratos, J. P. Hubaux, Mix-zones for location privacy in vehicular networks, EPFL, Switzerland, 2007 [19] P. Papadimitratos, J. P. Hubaux, F. Kargl, A. Kung, Privacy and identity management for vehicular communication systems: a position paper, European Commission, 2006 [20] P. Papadimitratos, J. P. Hubaux, I. Aad, D. Jungles, Eviction of misbihaving and faulty nodes in vehicular networks, IEEE, 2007 [21] M. Gerlach, VaneSe - An approach to VANET security, in: Proceedings of V2VCOM05, 2005. [22] http://openmoko.com/ [23] http://wiki.openmoko.org/wiki/Main_Page [24] http://en.wikipedia.org/wiki/Vehicular_ad-hoc_network [25] http://vanet.info/

62