service provisioning models depends on the underlying communication system to enable the user devices to connect to ..... damaging profile of the user.
2011 IEEE 7th International Conference on Wireless and Mobile Computing, Networking and Communications (WiMob)
REACT: Secure and Efficient Data Acquisition in VANETs Khaleel Mershad and Hassan Artail Electrical and Computer Engineering Department American University of Beirut Beirut, Lebanon {kwm03, hartail}@aub.edu.lb Relying on such hybrid networking appears to be the only means to realize various types of applications, as a pure V2V paradigm will provide very limited connectivity in addition to the fact that vehicles will not be able to utilize Internet services and applications. Hence, RSUs can be deployed every few miles for users to download maps, traffic data, multimedia files, check emails and news, etc… Although third-generation (3G) networks or satellite techniques can be used to achieve this goal, RSUs have the advantage of low cost, easy deployment, and high bandwidth. These kinds of vehicular networks are usually referred to as service-oriented [3], and they are expected to virtually provide all types of data to vehicle occupants while on the road. A key challenge in VANETs deals with information security among communicating parties. Recently, there have been different proposals concerning security in VANETs in order to mitigate the potential risks of attacks. For instance, a detailed description of different threats of attacks and their countermeasures can be found in [4] [5]. Few works (such as [3] and [6]) deal with the security of data messages in serviceoriented VANETs. Most of these works provide solutions to certain problems such as privacy or confidentiality. However, to our knowledge, none of the previous works proved to provide efficient security of data and location privacy of users in service-oriented VANETs while ensuring efficient throughput and acceptable end-to-end message latency. In this paper, we study the location privacy of VANET users and the security of data messages exchanged between users and RSUs. We briefly discuss a framework that allows users to securely connect to RSUs. We give a detailed explanation of the security features of our framework. We also discuss the possible attacks and how they are resisted. Finally, we prove through simulations that our system provides firm security while ensuring high network throughput and low latency. We call our system secuRe and Efficient dAta aCquisiTion in VANETs (REACT). The rest of the paper is organized as follows. The detailed description of our system and its security features are in Section 2, while Section 3 summarizes the attack model and the corresponding countermeasures. Section 4 evaluates our proposed approach and Section 5 concludes the paper.
Abstract—Vehicular ad hoc networks (VANETs) enable vehicles that are not necessarily within the same radio transmission range to communicate with each other and with roadside units (RSUs). The success of data acquisition and delivery systems in VANETs depends on their ability to defend against the different types of security and privacy attacks. The security of safety messages (like emergency and traffic information) has been the concern of VANET security researchers, and very few works dealt with the security of data messages exchanged between users and the infrastructure. This paper introduces a system that takes advantage of the RSUs that are connected to the internet and provide various types of information to VANET users. We provide a suite of novel security and privacy mechanisms in our proposed system, and evaluate its performance using the ns2 software. We demonstrate through comparing its results to those of another system its feasibility and efficiency. Keywords-VANETs; roadside units; service-oriented; security; location privacy; cryptography; anonymity
I. INTRODUCTION The advancement and wide deployment of wireless communication technologies have revolutionized human lifestyles by providing the most convenience and flexibility ever in accessing Internet services and various types of personal communication applications [1]. Lately, researchers conceptualized the idea of communicating vehicles giving rise to Vehicular Ad hoc Networks (VANETs), which are the main focus of engineers yearning to turn cars into intelligent machines that communicate for safety and comfort purposes. A Vehicular Ad hoc Network (VANET) is formed of vehicles equipped with wireless communication devices, positioning systems, and digital maps. VANETs allow vehicles to connect to roadside units (RSUs), which are connected to the Internet and may be interconnected with each other via a high capacity mesh network. Current research trends for VANETs have focused on developing applications that can be categorized into two main classes: 1) improving the safety level on the roads, and 2) providing commercial services and entertaining drivers and passengers. To enable such applications, vehicles and RSUs will be equipped with on-board processing and wireless communication modules. Then, vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) (bidirectional) communication will be possible directly when in range, or, in general, across multiple wireless links (hops), with nodes acting both as end points and routers [2].
978-1-4244-7803-3/10/$26.00 ©2010 IEEE
II. SYSTEM MODEL With the advancement of wireless technology, vehicular ad hoc networks (VANETs) are emerging as a promising
149
other side of a VANET. Security mechanisms must take this constraint of efficiency into consideration [7]. In this paper, we argue that the security of users and RSUs should be accounted for starting from the initial contact between a user in his vehicle and an RSU. For this reason, we describe a web-based secure registration process that allows a user to create an account with RSUs. During registration, a user provides all necessary information that enables him to have the benefit of secure connectivity starting from the initial packet he sends to the RSUs. To defend against privacy hacking and impersonation, we make an RSU specify for each user the next encryption key and the next pseudonym to use. We derive the encryption key for the next packet as part of the data in the current packet. To provide a high security level, we encrypt each packet with a different key. We assume that each participant in the VANET is equipped with a positioning system (e.g., GPS), has an Electronic License Plate (ELP) [4] installed, and has access to a digital map of its environment. We also assume a hybrid RSU architecture in which some RSUs are directly wired to each other, others connect to the RSU network via the Internet (using gateways), while a third group is both wired to other RSUs and have an Internet connection. In all cases, however, each RSU has a way to connect to any other RSU (possibly through other RSUs). This design enables multiple possible ways for communication between RSUs according to the importance of the RSU location and its applications. In addition to vehicles and RSUs, several trusted authorities (TAs) are connected to the RSUs via secure wired links. Similar to [8], we assume that TAs have powerful firewalls and other security protections that prevent them from being compromised. Also, the RSUs are supposedly equipped with trusted platform modules enabling them to resist software attacks. The RSUs do not store sensitive data, but each RSU has a secure connection to a database server that stores the RSU’s private information. Each RSU will have its own database to avoid the effect of failures. Finally, we assume that each RSU will be monitored by a TA which, upon detecting a malicious behavior from the RSU, will isolate the RSU from the network by informing all other RSUs which in turn inform
approach to increase road safety, efficiency and convenience [3]. The U.S. Federal Communication Commission (FCC) has allocated 75 MHz spectrum at 5.9 GHz for V2V and V2I communications, known as DSRC (dedicated short-range communications). Many major car makers are adding both hardware and software capabilities to their new models to make them ready to be part of future VANETs. Also, car manufacturers are working together in designing and testing long term projects aiming for intelligent vehicular networks. Although the primary purpose of DSRC is to enable communication-based automotive safety applications such as accident avoidance, natural disasters warning, and reducing traffic jams, the standard also allows for a range of comfort applications. For example, Internet access has become part of our daily lives, and there is a growing demand for accessing the Internet or information centers from vehicles via the VANET infrastructure. Many services could be provided by exploiting RSUs as delegates to obtain data on the user’s behalf. These applications span many fields, from office-on-wheels to entertainment, mobile Internet games, mobile shopping, downloading files, reading e-mail while on the move, chatting within secure social networks, etc… In service-oriented vehicular networks, the success of service provisioning models depends on the underlying communication system to enable the user devices to connect to a large number of communicating peers and even to the Internet. The dependence of these applications on the fixed infrastructure poses many new challenges, especially for security and user privacy. In particular, a series of security mechanisms on user authentication and content encryption should be well designed to provide a secure way to exchange information between the involved parties. In addition, anonymity services need to be provided in service-oriented VANETs to meet users’ demands for location privacy [3]. Cryptographic algorithms employed in authentication and in the integrity check should be effective enough to reduce the overhead in vehicles, RSUs, and trusted authorities. The connectivity among vehicles can often be highly transient or a one-time event. Delivering a message may involve long delays of recurrent hops to establish a path to a personal contact on the
Figure 1. A sample architecture of REACT
150
Nevertheless, it uses them to obtain the users data as fast as possible after the user connects to the VANET. Also, the user provides during registration the ELP of the vehicle from which he will connect to the VANET. This ELP will be used to enable the user to obtain his master key as we will explain. 2) Master Key After the user registers, his default RSU saves his account and contacts the TA to obtain a master key Km for him. The user will obtain Km the first time he connects from his vehicle to one of the RSUs (after registration). To achieve this goal, we propose a technique which we explain in details in Section IIB1. Our scheme derives an encryption key (Kpa) from the user password and uses this key to securely transfer Km to him. Kpa is generated using the famous PBKDF2 key derivation function [9]. One of the inputs to this function is an iteration count (IC1) which is an integer kept as a secret between the user and the RSU. After the registration finishes, the RSU generates IC1 (which should be above 1000) and sends it to the user (online during the Internet session in which the user registers), who saves it and uses it later as an input to the PBKDF2 function. 3) Sessions Each time a user connects to an RSU, he starts a new session. In order to preserve users’ location privacy, we include several provisions in REACT: first, we make each user connect to a single RSU at a single time, second, we make each RSU assign to each user a pseudonym (which is a virtual ID), third, we make the RSU change the user’s pseudonym per packet (as we will explain in Section II-B2). This insures that attackers will not be able to track the user movement and jeopardize his location privacy. A user starts a session by sending a “Hello” packet that contains his username to the nearest RSU. Each packet will include a timestamp to be used for resisting replay attacks. When the RSU receives the “Hello” packet, it starts preparing the user’s data that do not require authentication with other SPs. Interests that require authentication with SPs will be delayed until the RSU gets Kc securely from the user. While the RSU is preparing the user’s data, it assigns him a pseudonym and sends an “ID” packet that contains the pseudonym along with his username. The user then sends to the RSU an “Identify” packet encrypted with his Km. This packet contains the user’s username, password, and Kc. The RSU then authenticates the user using his password, and if successful, it retrieves from its database the user’s encrypted credentials with other systems, and uses Kc to decrypt them before sending them to these systems to obtain the user’s data. After the RSU authenticates the user, it obtains from the TA a session key Ks that it encrypts with the user’s Km, and sends it to the user in a “Session Key” packet. Ks will be used by the user to encrypt the first packet which he sends to the RSU (after he receives the “Session Key” packet). After that, each packet will be encrypted using a different key (Section II-B3). After sending the user’s data to him, the RSU can receive requests from him and answers them using available resources (such as other RSUs, nearby vehicles, mobile agents, etc…). Also, the RSU can send to the user advertisements and news it receives from websites and SPs that match his interests. The connection between an RSU and a user continues as long as the user does not switch connection to another RSU.
the vehicles connecting to them. A secure protocol (such as IP tunneling) is assumed to connect RSUs to each other. As for the VANET users, we assume that each user will connect to a single RSU at a single time. This assumption is made to reduce the overhead since thousands of users might be present in the VANET. Hence, a handover operation is required whenever the user switches connection between RSUs. Fig. 1 illustrates the environment of REACT. Next, we describe the general operations (without security aspects) of REACT, and then present its detailed security and location privacy features. These features can be added to any other V2I application to enhance its security. A. Global View Since vehicles might be occupied by several users (driver and passengers), and since each user in the car might have his own interests and requests, it is better to consider each user as a distinct participant in the network and give him a unique account with the RSUs. For this purpose, we require users to register with the RSUs via the web (outside the VANET) before they start connecting from their vehicles. This step allows for benefiting from security measures that exist in Internet protocols. These measures will enable users and RSUs to exchange credentials, keys, and general information that will help them start their connection in the VANET securely. 1) Registration When a user registers using the RSU website, he specifies his personal details (i.e., name, address, phone, etc…) plus a username and password to use for authentication when he connects to the RSU network from his vehicle. The user also chooses a default RSU, which will save his account in its database. Examples of user’s interests are Web pages, certain news, traffic information in certain areas, email messages (possibly from different email accounts), etc… When he later connects to the VANET, he sends a “Hello” packet to the nearest RSU, which will notify his default RSU, which in turn retrieves his interests from its database and collects the required data for him. This later operation might entail fetching certain news and grouping them, contacting web servers and saving their html files, contacting email servers on the user’s behalf and downloading messages, etc... A user can choose any RSU as his default one, but it is best to select the nearest to his starting point in the VANET. Some user interests may require authentication, meaning that the RSU needs to obtain from the user his credentials with the corresponding service providers (SPs) so that it can connect to these SPs on the user’s behalf. In REACT, we do not save the user’s credentials in the RSU in plain text. Instead, we require the user to provide during registration his authentication data with these SPs in addition to a secret key Kc (e.g., a sequence of 12 random characters) to be used by his default RSU to encrypt his authentication data and save them. The RSU does not save Kc which remains secret to the user. When the user connects to the VANET from his vehicle, he sends Kc (encrypted with his master key) to the RSU, which will then use Kc to decrypt the user credentials with other systems and obtain the data from these systems. However, the RSU in this last step does not save Kc which is used by the RSU’s software only. In this way the user credentials with other systems remain hidden in the RSU database.
151
4) Handover A user observes his current location at constant intervals of time and calculates his distance from all nearby RSUs using the digital map. When he finds that he is much closer to another RSU (e.g., closer by a factor of 30%), he switches to it. We explain the handover process using the following scenario: suppose a user A was connecting with RSU R1, and now wants to switch to RSU R2. A sends to R1 a “Handover Request” containing the ID of R2. This prompts R1 to send to R2 a “Handover” packet containing A’s username, his next pseudonym with R1 (pc), and his next packet key (Kpc). Next, R1 sends to A a “Handover Confirm” that contains pc and Kpc. This last packet will be encrypted with the user’s current packet key at R1 (as we will explain in II-B3). A then sends to R2 an encrypted “Hello” (with Kpc) containing his username and pc. R2 decrypts the “Hello” and checks that the username and pc are the same as those received from R1, and then assigns to A a new pseudonym and sends it to him in an “ID” packet. After R1 sends the “Handover Confirm”, it waits for a short period of time, τ, before it sends A’s data in its cache (if any) to R2. This time is used to allow requests in transit sent from A to R1 to arrive, and to allow replies being sent to R1 from data sources to reach R1. Next, R1 sends a “User Data” packet that contains all pending requests and data replies for the user to R2, which in turn sends to A the replies that are ready and the pending requests to their data sources. That is, the services offered to A will not be interrupted. B. Security and Privacy This section provides a detailed explanation of the security and privacy features that were included in REACT. 1) Complete Security from the Initial Connection After the user registers, he needs to obtain his Km from the RSUs and save it in his vehicle’s onboard unit (OBU). On the other hand, the RSU needs to authenticate him in order to send him km. At the same time, the user cannot send his password to the RSU in plain text. In order to solve this problem, we proposed the secure registration process in which a user creates an account with the RSUs. The user credentials from his account will allow the RSUs to authenticate him (as explained in Section II-A3). Fig. 2 describes an algorithm that will be executed by the user and the RSU to obtain an encryption key Kpa from the password provided by the user during registration. The RSU uses Kpa to safely transport Km to the user in a cipher message M. The user uses his password to generate Kpa and uses Kpa to decrypt M and obtain Km. The idea of deriving an encryption key from a simple human-memorizable secret (i.e., password) goes back to the seventies, and the first standardization effort began in 1996 as IEEE announced the start on work on the P1363.2 supplement which defines techniques for the “Password-based Public Key Cryptography”. Currently, the P1363.2 standard includes a number of password-authenticated key agreement schemes and password-authenticated key retrieval schemes such as PAK, SPEKE, AMP, SRP3, SRP5, SRP6, and PKRS. On the other hand, current researches have focused on using password-based key derivation functions (KDFs) in designing modern password-based encryption schemes. For example, the PBKDF2 key derivation function (specified in RFC 2898) [9], uses a hash function (such as MD5, Tiger, SHA256, etc…), a
salt (e.g. 64 bits) and a high iteration count (often 1000 or more) to generate a cryptographic key from a simple password. In REACT, we propose the PtK algorithm (Fig. 2) which uses the PBKDF2 function to generate a symmetric key Kpa that is used to encrypt the user’s master key. Kpa is obtained by executing the PBKDF2 function passing to it P (the userdefined password during registration), S1 (a random salt of size Ss bits, example Ss = 128), and IC1 (the iteration count). As we explained in Section II-A2, IC1 will be sent secretly (online) by the RSU to the user. The RSU will use a predefined symmetric encryption scheme (such as AES, Twofish, etc…) to encrypt Km using Kpa to obtain the cipher message m1. Finally, the RSU sends to the user a message M which is the concatenation of S1 and m1. When the user obtains M, he separates the first Ss bits and saves them is S1. Then the user passes to the PBKDF2 function the password (P), S1, and IC1 to calculate Kpa. Next, the user uses Kpa to decrypt the rest of M to obtain Km. Password-to-Key (PtK) Algorithm At the RSU: Input: password P, master key Km, initial iteration count IC1, encryption function E[], size of required key L bits. Output: cipher message M. (1) begin (2) generate random Salt S1 of size Ss bits. (3) calculate Kpa = PBKDF2 (P, S1, IC1, L) K (4) encrypt Km using Kpa to get m1 = E (5) calculate cipher message M = S1 || m1 (6) return M (7) end At the user: Input: password P, cipher message M, initial iteration count IC1, decryption function D[], size of required key L bits. Output: master key Km. (1) begin (2) separate M to get S1 and m1 (3) calculate Kpa = PBKDF2 (P, S1, IC1, L) to obtain Km (4) apply D (5) return Km (6) end Figure. 2. Algorithm for securing the master key of the user
The hardiness of cracking Kpa by an attacker is increased by keeping the iteration count IC1 secret between the RSU and the user. Suppose an attacker obtains the message containing M and attempts to perform brute-force dictionary attacks on M to deduce Km. First, the attacker can obtain S1 and m1 from M but will not have any information about P or IC1. Hence, the attacker will be forced to attempt all possible values of IC1 on each possible value of P in the dictionary. In [9], the iteration count was recommended to have values above 1000. Hence, IC1 can take values between 1000 and (231-1). Accordingly, the attacker needs to run the dictionary attack 1.073 × 109 times (on the average). Each time the attacker tries a combination of P and IC, he obtains a candidate key Kc. The only way for the attacker to find if Kc is equal to Kpa is by trying to decrypt m1 using Kc and checking if the result is a candidate value of Km. The complete operation can be very expensive if the password has high entropy (note that we do not discuss here the strength of the used password since it is outside the scope of this paper; however, we consider that the RSUs will generate or accept only passwords with high entropy; for example, 60 or above).
152
This will take the attack more than 109 times than solving for an ordinary dictionary attack. According to [10], the $-year cost of performing a dictionary attack on PBKDF2 using a 12 random character password is about 160 million dollars per year. Our algorithm outperforms ordinary PBKDF2 by a factor of 109 which means it costs about 160 × 103 trillion dollars to crack a master key encrypted using PtK in one year. Going back to obtaining the master key, a user starts his initial session after registration by sending an “Initiate” packet to his nearest RSU. This packet contains the user username, and ELP (which he provided at registration). According to [4], the ELP is a unique electronic identifier issued by the government to each vehicle. The ELP is cryptographically verifiable by the TA. Hence, when the RSU receives the “Initiate” packet, it sends the ELP and the username of the user to the TA which authenticates the user and replies to the RSU. When the RSU receives a positive reply from the TA, it obtains from the user account his password, IC1, and Km and executes the PtK algorithm to obtain M and sends it to the user in a “Master Key” packet. The user executes the PtK algorithm to decrypt M and obtain Km. Note that as long the user’s password and IC1 are known only to the user, he is the only one who is able to decrypt M. Hence, the security of Km is coupled with the secrecy of the password and IC1. For this reason, a user needs to keep these two in a very safe state and should obtain a new password and IC1 from the RSU system each time he changes Km. The process of assigning a new Km to a user should be executed at constant periods of time (for example, yearly or half-yearly) such that high sophisticated attacks are not able to crack Km. 2) Location Privacy If a user in a VANET uses the same ID whenever he sends a packet, an attacker could listen to his packets and build a profile of his locations which jeopardizes his privacy. To solve this problem, pseudonyms were proposed in the literature to deceive attackers. In REACT, we explore the fact that a user connects to a single RSU at a time and make the RSU give the user a new pseudonym each time it sends a packet to him. Each RSU will have its own address pool, and pseudonyms are composed of two parts: the RSU ID and the random ID picked by the RSU from its address pool. The address pool can be viewed as a one way hash function that hashes the username to an integer within a certain range. If conflicts occur, a rehash of the obtained ID is performed. Each RSU stores a table Tr that contains five fields: . The current_ID is the last pseudonym the RSU sent to the user, while the next_ID is the pseudonym that the RSU will send to the user in the next packet. The current_key and next_key fields will be explained in the next section. When the RSU receives a packet from the user, it identifies him by looking up his pseudonym in the current_ID field in Tr. When the RSU sends the next packet, it includes in it the next_ID which will be used by the user as his new pseudonym. The RSU then generates a new pseudonym Pn and replaces the user’s current_ID with his next_ID and the current value of next_ID with Pn. In order to account for lost or corrupt packets, the RSU does not delete the old pseudonym, but stores it in the old_ID field in a temporary table Ttem which contains four fields
{{
{
. In the future, if the RSU receives a packet from the user in which he uses his old pseudonym, it assumes that the user has not received the new pseudonym that was assigned to him (due to lost packets). Hence, the RSU resends the current_ID (from Tr) to the user in the next packet. 3) Packet-based Keys When a user S starts a new session with an RSU R, the latter obtains from the TA a session key Ks and sends it to S, encrypted with his Km. The user uses Ks to encrypt the next packet he sends to R. After that, each packet will be encrypted with a new key. The body of each packet will contain a start_of_key variable of type integer that contains the index of a random byte in the packet body. The key will be chosen starting from this byte. For example, if the system uses a 128bit key, and the value of start_of_key is 47, then the receiver of the packet will count 47 bytes from the start of data, and will save the next 16 bytes (128 bits) as the new value of Ks with which the next packet will be encrypted. If the data in the body of the packet has a total size of n bytes, the value of start_of_key is chosen randomly between 1 and (n-16). Fig. 3 illustrates this example. Each user stores a table Tu which consists of two fields: . Also, the table Tr at each RSU contains these two entries for each user as we illustrated in the previous section. When an RSU R obtains a session key Ks from a TA for a user A, it stores Ks in the next_key field in A’s entry in Tr. When the user receives Ks, he also stores its value in the next_key field in Tu. After this, when an RSU (or a user) receives an encrypted packet P, it uses the next_key field to decrypt the packet. Next, the RSU (or user) calculates the value of the key Ks1 from the received packet and uses it to encrypt the next packet P1 it sends. P1 will also contain a value of start_of_key which will correspond to a key Ks2 that will be used by the receiver of P1 to encrypt the next packet. Hence, the RSU (or user) will update its table by replacing the current_key with Ks1 and by replacing the next_key with Ks2.
Figure. 3. General packet format in REACT
Similar to the previous section; each user will have a table Ttem which contains three fields: . Each RSU also stores a table Ttem which we explained in Section II-B2. Before replacing them with their new values, the user and the RSU store the old values of current_key and next_key in the old_cur_key and old_next_key fields in Ttem to account for lost or corrupt packets. If an RSU (or user) receives a packet and fails to decrypt it using the next_key from Tr (or Tu), it attempts to decrypt it using the old_next_key from Ttem. If it succeeds, it assumes that the other end has not received that last packet and reuses the old_cur_key and the old_next_key from Ttem instead of the current_key and next_key from Tr (or Tu).
153
Note that the size of Ks should be carefully chosen. If we consider that the data exchanged between the user and the RSU will have a period T after which it becomes not private, then the size of Ks should be chosen such that if an attacker listens to a packet and tries to deduce Ks by brute-force, it should take him at least a period T. According to analysis made for effective lengths of symmetric keys, an 80-bit symmetric key will take an attacker about 1 year to crack if he is able to build a machine that can check 1018 keys per second (which is stated in [11] as a very hard task to achieve). Hence, sensitive data can be encrypted using a 128-bit key while less-sensitive data could be encrypted using an 80-bit symmetric key.
from replying to the RSU (i.e., using DoS), decrypting the packet, and using the pseudonym assigned by the RSU in the packet as his own one. As we explained in the previous paragraphs, it is very difficult to carry out the above actions considering the properties of our proposed design. 5) Location Privacy: By collecting an unsuspecting individual’s location trace over time, such information can be used in tracking, stalking, or in building a potentially damaging profile of the user. Pseudonyms serve to deceive attackers as they become unaware of the subject of these locations. Anonymity breaks the linkage between location information and real identity. Many techniques for pseudonym changing were proposed in the literature (e.g., mix zones [12]). The solution we adopt in REACT is to make the RSU assign to the user the next pseudonym he should use. In urban scenarios, vehicles are usually surrounded by several neighbors. If each vehicle changes its pseudonym each time it sends a new packet, an attacker will not be able to know if the vehicle or a neighbor sent the new packet. The attacks described above are the ones we consider most probable to be performed by attackers aiming to gain personal profit by stealing other’s data or propagating false information. Many other attacks may occur in VANETs but most of these are specific in their nature. For example, DoS is usually performed for harming the victim and they have their own set of countermeasures. Also, position cheating and transmitting false traffic data are used to gain better traffic conditions but are outside the scope of our system. Most other attacks in VANETs are not related to data dissemination and acquisition.
III. ATTACKS AND COUNTERMEASURES In this section we describe the most important security threats that REACT was designed to face. Since we cannot envision all the possible attacks that will be mounted in the future on VANETs (some previous works, such as [4] and [5] defined about 15 to 20 different attacks that could be carried out in VANETs), we will provide a general explanation of the attacks that we consider and how they are prevented by our system. First, though, we have to define the attacker. According to the classification of attackers in [4], we consider attackers of type IR* who are inside the VANET, rational, and could be either active (performing actions) or passive (listening to packets and stealing data). Based on this classification, we identify the attacks that attackers could perform as: 1) Eavesdropping: In this type of attack, it is very hard to catch the attacker since he just listens to the wireless channel and tries to steal important information from packets for his own profit. In REACT, all sensitive information are encrypted with packet keys. Even the first packets between a user and the RSU are encrypted with Kpa (Section II-B1). The only way for an attacker to decrypt a packet is through knowing all previous packet keys, and consequently knowing the user’s master key, which we described thoroughly how to highly secure it. 2) Packet Tampering: In this type of attack the attacker tries to change the contents of the packet before he forwards it. As before, this attack cannot be performed unless the attacker decrypts the packet. Hence, he should obtain the packet key, and consequently Km, which is only possible if the attacker physically attacks the user’s vehicle. 3) Packet Replay: The attacker here stores a packet and releases it after a certain period (possibly for performing a Denial of Service (DoS) or a compromization attack). As we explained in Section II-A3, the timestamp in the body of each packet will serve to defend against this attack. The timestamp will be encrypted to prevent the attacker from altering it. The destination of a packet will discard any packet if the difference between the current time and the timestamp of the packet is greater than a threshold Trep. 4) Masquerade: The attacker actively pretends to be another vehicle by using false identities and can be motivated by malicious or rational objectives. In REACT, the RSU defines for each user his next pseudonym in each packet. Hence, the only way for the attacker to know the user’s current pseudonym is by listening to the last packet, preventing him
IV. SIMULATIONS This section presents the results of the simulations that were performed to evaluate REACT. We implemented our system using the ns2 software (version 2.34 with the 802.11p amendment and the Nakagami propagation model), and used the SUMO tool [13] to generate the node movement file that was inputted to ns2. The map used to generate the movement file has a size of 1.5×1.5 Km2. The wireless bandwidth and the radio transmission range were assumed 6 Mbps and 300m respectively. The number of vehicles was set to 100, and their minimum and maximum speeds were set to 15 and 30 m/s respectively. Five RSUs were deployed uniformly across the map so as to balance the load as much as possible. Fig. 4 shows the map used in the simulations and the locations of RSUs. Two of the four corner RSUs were wired to the RSU in the center, while the other two corner RSUs and the one in the center were simulated to have an Internet connection. Each RSU was simulated to be wired to an SP, linked through an access point to a second one, and connected through the Internet to a third one. Consistent with the literature, the delay for an RSU to access the wired SP was set to 20ms and that for accessing the wireless SP was set to 50ms. The delay for an RSU to send a message to another was distributed uniformly over the range [0.05, 0.1] seconds. Each vehicle generates every 30 seconds a new request that randomly targets one of the 15 SPs. The size of the data packet was set to 350 bytes. This value was chosen to ensure that the encrypted packet size will be less than the maximum transmission unit
154
VANETs. It uses elliptic curve cryptography (ECC) at the RSUs to authenticate requests from multiple vehicles at the same time. The basic difference between REACT and ABAKA is that REACT does not require RSUs to authenticate each message as ABAKA does, since REACT relies on the RSU to send the next key for the vehicle in the packet. Also, ABAKA requires a tamper-proof device to be installed in the vehicle while REACT doesn’t. Finally, ABAKA requires the RSU to generate a session key that will be used in the connection between the vehicle and the SP, while in REACT we make the RSU perform all required operations with the SP on behalf of the user. In our simulation of ABAKA, we used the same key lengths used in REACT (128 bits) so that the two systems provide the same level of security and the comparison is fair. The metrics used for comparing the two systems are: the 1) Message Response Time (MRT), which is the total time required to send a message from a vehicle to its nearest RSU (or vice versa), the 2) Initialization Phase Time (IPT), which is the average time between the instance a vehicle sends the first packet in a session to the instance it sends the first packet encrypted with a session key, and the 3) Average Overhead Traffic (AOT), which is the additional traffic (increase in sizes of messages due to cryptographic operations) sent or received by a vehicle during the simulation time. Note that the IPT is calculated in REACT as the time between the user sending the “Hello” packet and receiving the session key, while in ABAKA it is the time required for the “Pseudo-identity Generation” and the “Batch Authentication and Key Agreement” phases to complete (see [16] for complete details of these two phases). The three compared metrics were measured while varying the Request Rates (Rr) between 1 and 60 requests per minute. B. Simulation Results Fig. 5 shows the total delay which reflects the efficiencies gained by assigning keys from within the packets themselves and having RSUs contact SPs on behalf of users. In ABAKA, each time a vehicle wants to contact an SP, it should send it authentication data, and negotiate with it a session key. Fig. 5 shows that these operations increase considerably the delay of a packet. The two systems seem to have similar latencies when the request rate (Rr) is small, mainly because the network is relaxed and the packets are sent directly without queuing. At Rr = 60 requests per minute, ABAKA produces a delay of 320ms which is approximately double that of REACT. The main reason of this is that the authentication and handshaking operations of ABAKA are substituted in REACT with authenticating a user per packet, and by assigning the RSU the task of obtaining the user’s data on his behalf. The next parameter we examine in Fig. 6 is the Initialization Phase Time (IPT), which in ABAKA includes 1) transmission of the request to the SP via the RSU; 2) vehicle verification and key agreement (at the RSU); and 3) mutual authentication and key agreement (between the vehicle and the SP). The initialization delay shows how much of the latency is due to security activities. The figure shows that REACT has a much lower IPT than ABAKA especially for high Rr. This indicates that the handshaking between the user and the RSU in REACT is faster than the 3-way handshaking in ABAKA (between the user, the RSU, and the SP).
(MTU) of 802.11 MAC (1500 bytes). From the experiments we made on AES using the Crypto++ package, we found that the size of a message is multiplied by an average factor of 3.47 when the message is encrypted with a 128-bit AES key. Hence, the encrypted message will have an approximate size of 1.22 Kbytes which will remain less than the MTU even after we add the necessary headers. The Hello interval was set to 2 sec. Finally, we used TrafRoute [14] to route messages between vehicles and RSUs and vice versa. TrafRoute operates by routing messages through vehicles that are around virtual waypoint called Forwarding Points (FPs) until the message reaches the nearest RSU, and then through the RSU network (if needed), and finally to the destination. The routing scheme of TrafRoute is the most suitable to our proposed system among other protocols for VANETs. Note that in the simulation scenarios, the average distance between a vehicle and its nearest RSU was calculated to be about 260 meters which implies that a vehicle is always less than 2 hops away from the nearest RSU. This reflects our aim to test the performance of the security mechanism and not the routing protocol.
Figure. 4. City map used in the simulations
The Internet user registration process was substituted by installing at the RSUs data files that include users’ information. These files are read by the RSU agent (ns2 C++ class) that processes the user connections from the vehicle agent. The processes of generating the different keys were implemented as functions in their corresponding agents. The cryptographic operations were implemented using the Crypto++ package [15]. The widely used AES algorithm was used for encryption and decryption of messages. The size of the master key (Km) was set to 256 bits, while those of the secret key (Kc), password key (Kpa), and packet key (Ks) were set to 128 bits. The cryptographic operations were implemented in a separate ns2 agent that uses necessary classes from the Crypto++ package. A. Compared Protocol In order to compare our system with other security mechanisms that were proposed for service-oriented VANETs, we simulated the ABAKA protocol [16] which was recently proposed as an authentication and key agreement scheme for
155
in [17]. We will also study different prediction models in conjunction with caching mechanisms to enhance the user’s experience and speed up the data delivery process. This can be done by having RSUs prepare the user’s data ahead of time so that he can acquire the data directly after he joins the network. Overhead Traffic (Kb/sec)
Message Delay (sec)
Finally, we show in Fig. 7 the overhead traffic per node (in Kbits per second) which is due to exchanging security messages and also due to the increase in the sizes of messages because of encryption. The AOT was calculated by calculating the total number of each type of messages sent, received, and forwarded during the simulation, multiplying each number by the message size, and summing the results. For the data messages, the overhead size of the message is the additional size induced by encrypting the message. REACT
0.35
ABAKA
0.3 0.25 0.2 0.15 0.1
ABAKA
0
5 10 15 20 25 30 35 40 45 50 55 60
Request Rate (req/min)
0.05
Figure. 7. AOT of REACT and ABAKA for different request rates.
0 0
REFERENCES
5 10 15 20 25 30 35 40 45 50 55 60
Request Rate (req/min) Figure. 5. MRT of REACT and ABAKA for different request rates.
[1]
Fig. 7 shows that when Rr is low, the two systems produce similar AOTs (REACT has a slightly lower AOT). As we stated before, when Rr is low, the network is relaxed and packets are sent directly without queuing. When Rr increases, network congestion is expected and packet are delayed or dropped. For this reason, ABAKA experiences high overhead traffic due to broadcasting operations in ABAKA which are avoided in REACT. Initialization Delay (msec)
REACT
5 4.5 4 3.5 3 2.5 2 1.5 1 0.5 0
[2]
[3]
[4] [5]
REACT
18 16 14 12 10 8 6 4 2 0
ABAKA
[6]
[7]
[8]
0
5 10 15 20 25 30 35 40 45 50 55 60
[9]
Request Rate (req/min) Figure. 6. IPT of REACT and ABAKA for different request rates.
[10]
V. CONCLUSION AND FUTURE WORK This paper presented REACT, which is part of a complete system that we are designing for providing car drivers and passengers pervasive access to needed data while on the road. The proposed system exploits the presence of RSUs to reduce the load on vehicles and to hide the complexity of getting the required data in a convenient way. The evaluation of REACT confirmed its effectiveness as compared to a recent security mechanism for VANETs. The ongoing work on the proposed system is focusing on the design of a high level routing protocol that will both cope with the extreme dynamics of VANETs and benefit from its properties, for example by taking advantage of the ability of cars to carry and forward data in order to get it to distant locations. A preliminary design of this protocol was presented
[11] [12] [13]
[14]
[15] [16]
[17]
156
X. Lin, R. Lu, C. Zhang, H. Zhu, P. H. Ho, and X. Shen, “Security in Vehicular Ad Hoc Networks”, IEEE Communications Magazine, April 2008. P. Papadimitratos, V. Gligor, J-P. Hubaux, “Securing Vehicular Communications - Assumptions, Requirements, and Principles”, Workshop on Embedded Security in Cars (ESCAR 2006). H. Zhu, R. Lu, X. Shen, and X. Lin, “Security in Service-Oriented Vehicular Networks”, IEEE Wireless Communications (2009), Vol 16, No, 4, pp. 16-22. M. Raya and J. P. Hubaux, “The Security of Vehicular Ad Hoc Networks”, (SASN 2005), Virginia, USA, Nov. 2005, pp. 11-21. C. Laurendeau and M. Barbeau, “Threats to Security in DSRC/WAVE”, (ADHOC-NOW 2006), LNCS, Springer, Vol. 4104, pp. 266-279. E. Coronado and S. Cherkaoui, “Service Discovery and Service Access in Wireless Vehicular Networks”, SUPE Workshop in IEEE Globecom’08, N.O. USA, 2008. H. K. Choi, I. H. Kim, and J. C. Yoo, “Secure and Efficient Protocol for Vehicular Ad Hoc Network with Privacy Preservation”, EURASIP Journal on Wireless Communications and Networking, 2011. Y. Hao, Y. Cheng, C. Zhou, and W. Song, “A Distributed Key Management Framework with Cooperative Message Authentication in VANETs”, IEEE Journal on Selected Areas in Communications, Vol. 29, No. 3, March 2011, pp. 616-629. 2898-PKCS# 5: Password-Based Cryptography Specification Version 2.0. C. Percival, “Stronger Key Derivation via Sequential Memory-Hard Functions”, BSDCan 2009, Ottawa, Canada, May 2009. http://en.wikipedia.org/wiki/Brute-force_attack A. R. Beresford and F. Stajano, “Location privacy in pervasive computing,” IEEE Pervasive Computing, Vol. 2, No. 1, pp. 46–55, 2003. Centre for Applied Informatics (ZAIK), Institute of Transport Research, German Aerospace Centre, “Sumo - simulation of urban mobility”, http://sumo.sourceforge.net/ R. Frank, E. Giordano, P. Cataldi, and M. Gerla, “TrafRoute: A Different Approach to Routing in Vehicular Networks”, VECON 2010, N. F., Canada. Crypto++ 5.6.1 Library, , (April 2011). J. L. Huang, L. Y. Yeh, and H. Y. Chien, “ABAKA: An Anonymous Batch Authenticated and Key Agreement Scheme for Value-Added Services in Vehicular Ad Hoc Networks”, IEEE Transactions on Vehicular Technology, Vol. 60, No. 1, Jan. 2011, pp. 248-262. K. Mershad and H. Artail, “Exploiting RSUs for Efficient Routing in VANETs”, WiMob 2011, Shanghai, China (to appear).
