A Framework for Secure and Efficient Data Acquisition in ... - IEEE Xplore

536

IEEE TRANSACTIONS ON VEHICULAR TECHNOLOGY, VOL. 62, NO. 2, FEBRUARY 2013

A Framework for Secure and Efficient Data Acquisition in Vehicular Ad Hoc Networks Khaleel Mershad and Hassan Artail

Abstract—Intervehicular communication lies at the core of a number of industry and academic research initiatives that aim at enhancing the safety and efficiency of transportation systems. Vehicular ad hoc networks (VANETs) enable vehicles to communicate with each other and with roadside units (RSUs). Serviceoriented vehicular networks are special types of VANETs that support diverse infrastructure-based commercial services, including Internet access, real-time traffic management, video streaming, and content distribution. Many forms of attacks against service-oriented VANETs that attempt to threaten their security have emerged. The success of data acquisition and delivery systems depends on their ability to defend against the different types of security and privacy attacks that exist in service-oriented VANETs. This paper introduces a system that takes advantage of the RSUs that are connected to the Internet and that 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 show, by comparing its results to those of another system, its feasibility and efficiency. Index Terms—Anonymity, hierarchal password-based key derivation (HARDY) function, key derivation, roadside units (RSUs), security, service-oriented vehicular ad hoc networks (VANETs).

I. I NTRODUCTION

T

HE development and wide utilization of wireless communication technologies have transformed human lives by providing the most convenience and flexibility ever in accessing Internet services and various applications. Lately, researchers conceptualized the idea of communicating vehicles, giving rise to vehicular ad hoc networks (VANETs), which are the main focus of engineers who yearn to turn cars into intelligent machines that communicate for safety and comfort purposes. A VANET is composed of vehicles that are equipped with wireless communication devices, positioning systems, and digital maps. VANETs allow vehicles to connect to roadside units (RSUs), which may be interconnected with each other through a high-capacity mesh network. Current research trends for VANETs focused on developing applications that can be grouped into the following two classes: 1) improving the safety level on the road and 2) providing Manuscript received December 22, 2011; revised August 15, 2012; accepted October 13, 2012. Date of publication October 26, 2012; date of current version February 12, 2013. This work was supported in part by the Lebanese National Council for Scientific Research under Grant 2011/09. The review of this paper was coordinated by Prof. Y. Cheng. The authors are with the Department of Electronics and Communications Engineering, American University of Beirut, Beirut 1107 2020, Lebanon (e-mail: [email protected]; [email protected]). Color versions of one or more of the figures in this paper are available online at http://ieeexplore.ieee.org. Digital Object Identifier 10.1109/TVT.2012.2226613

commercial and entertainment services. To enable such applications, vehicles and RSUs will be equipped with onboard processing and wireless communication modules. Then, vehicle-to-vehicle and vehicle-to-infrastructure (V2I) communications will directly be possible when in range or across multiple hops. RSUs are usually connected to the Internet and allow users to download maps, traffic data, and multimedia files and check emails and news. These kinds of VANETs, referred to as service oriented [42], are expected to virtually provide all types of data to drivers and passengers. The unique features of intervehicular communication (IVC) are a double-edged sword: A powerful collection of tools will be available, but a set of dangerous attacks becomes possible. Recently, there have been different proposals for securing VANETs and lessening the potential risks of attacks. A detailed description of different attacks and their countermeasures can be found in [21] and [33]. Few works (such as [9] and [42]) deal with the security of service-oriented VANETs. Most of these works provide solutions to specific problems such as user privacy or data confidentiality. Nevertheless, to our knowledge, none of the previous works proved to provide security of data and location privacy of users in service-oriented VANETs while ensuring efficient throughput and acceptable end-to-end latency. From another point of view, several projects were launched, with the security of VANETs being their main concern. Some of these projects (such as SeVeCom [38], SafeSpot [36], and GeoNet [14]) have already delivered their outcomes, whereas other projects, such as ITSSv6 [18], are still in progress. Most of these projects provide a general overview of security features that should be employed in VANETs. For example, the SeVeCom Project focused on safety applications such as collision warning. The security of such applications is different from the security of service-oriented applications because of their different security requirements. For example, the data exchanged in safety messages (such as location information or warnings) need not be encrypted. However, messages that contain data from infotainment applications must be tightly encrypted. Many similar security requirements greatly differ between safety mechanisms and service-oriented systems. In this paper, we study the security of data messages exchanged between users and RSUs and the location privacy of VANET users who exchange these messages. There are systems that are proposed in the literature and have this same aim. However, they use asymmetric encryption systems, mainly the elliptic curve cryptography (ECC) standard. We, on the other hand, use a symmetric scheme [Advanced Encryption Standard (AES)] and propose an approach to increase its security to a

0018-9545/$31.00 © 2012 IEEE

MERSHAD AND ARTAIL: FRAMEWORK FOR SECURE AND EFFICIENT DATA ACQUISITION IN VANETs

high extent by using a hierarchical-based encryption function. The main contributions of this paper can be summarized as follows. 1) We propose a novel approach for users to start their connections in the VANET in a secure way. 2) We illustrate a new handover scheme that is particularly suitable for VANETs. 3) We explain a new cryptographic approach that provides much higher security measures compared to existing ones and analyze the performance of our approach using mathematical and simulation means. 4) We suggest two novel mechanisms for data confidentiality and users’ location privacy in VANETs. This paper is organized as follows. We first conduct a study of previous works in Section II. Next, we discuss a framework that allows users to create accounts with RSUs and connect to them in secure sessions in Section III, where we additionally describe the security features of our framework, which employs multiple packet keys for encryption, and also describe a new approach for providing location privacy to users by using packet-based pseudonyms and mix zones. We analyze our cryptographic scheme and the system deployment cost in Section IV. Finally, we prove through simulations in Section V that our system provides firm security while ensuring a high success ratio and low latency. We call our system secure and efficient data acquisition in VANETs (REACT). II. P REVIOUS W ORK Several researchers studied security challenges related to VANETs. In this section, we conduct a brief study of recent and relevant works. Raya and Hubaux [33] describe security vulnerabilities and challenges in vehicular networks. A detailed threat analysis, a basic attacker model, and appropriate security architecture are provided. In addition, there have been several proposals for privacy preservation in VANETs. If VANET users use the same ID whenever they send a packet, an attacker could listen to their packets and build a profile of their locations, which jeopardizes their privacy. Hence, pseudonyms were proposed to deceive attackers. It preserves the location privacy of a user by breaking the linkability between two locations. A vehicle can periodically update its pseudonym. Considering that a powerful adversary may still link the new and old pseudonyms by monitoring the temporal and spatial relations between new and old locations, the techniques of mix zones [13], silent period [16], and ad hoc anonymity [20] were proposed. A mix zone is an area in which several vehicles change their pseudonyms together so that an attacker will not distinguish the new pseudonym of each vehicle. The silentperiod approach enables mobile users to jointly change their pseudonym with other approaching users by simultaneously entering a silent period, in which all nearby users suppress their location updates and wield new pseudonyms [16]. Ad hoc anonymity [20] extends mix zones by using dummies, which are virtual users that are created before the pseudonym change starts and disappear after it ends. The dummies link several pseudonym change sets together and mix up all the users who have participated in pseudonym changes at different times.

537

One major disadvantage in the mix-zone approach is the process of pseudonyms refill. For example, the authors in [24] assume that each vehicle acquires a new set of pseudonyms from the central authority (CA) when their stored pseudonyms are used. Another disadvantage, as depicted in [4], is that vehicles do not know where the adversary installed its radio receivers, i.e., where the observed zones of the adversary are. Current approaches that use mix zones assume that the observed zones are small and scattered such that users who change their pseudonym every several transmissions will avoid sending multiple packets with the same pseudonym from within an observed zone. This assumption, however, is not viable in case of a global eavesdropper who can hear all messages in the network. Another disadvantage is that a user might not always find other near users that are willing to enter a mix zone. In AMOEBA [37], vehicles form groups, and the messages of all group members are forwarded by the group leader. Hence, the privacy of group members is protected by sacrificing the privacy of the group leader. Moreover, if a malicious vehicle is selected as a group leader, all group members’ privacy may be leaked. The group signature [7] is a privacy scheme in which one group public key is associated with multiple group private keys. Although an eavesdropper can know that a message is sent by the group, it cannot identify the sender of the message. In [5], a pseudonym is combined with a group signature to avoid storing pseudonyms and certificates in vehicles. With regard to message (or data) security, we notice that few studies were devoted to developing security mechanisms for value-added applications in VANETs. Li et al. [22] proposed a secure and efficient scheme with privacy preservation in which a vehicle needs to acquire a blind signature before it can access the desired services from the near RSU. A service provider (SP) is responsible for verifying the validity of signatures. The ABAKA protocol [17] uses ECC at the RSUs to authenticate requests from multiple vehicles together. ABAKA requires a tamper-proof device to be installed in vehicles and requires SPs to generate session keys that will be used in their connection with vehicles. In [1], an RSU is made to sign and deliver messages to end users on behalf of CAs. The CA derives a secondary secret key from its private key and securely sends it to the RSU. The receiver verifies a message by checking both the correctness of the key signature and the location of the sender. Another approach, in [28], depends on hash chains to sign messages. Each vehicle periodically generates a new hash chain and sends it to the CA, which generates an authentication code (AC) from the hash chain and sends it to the vehicle. The ACs are used as signatures for messages, and RSUs are used for relaying messages between vehicles and CAs. In [11], an approach that is based on Lite-CA-based public key cryptography and on-path onion encryption scheme is proposed. The approach relies on encrypting a message by each relaying hop and thus prevents any adversaries from tracing message flows. The secure and privacy enhancing communications schemes (SPECS) protocol [8] is based on bilinear pairing and bloom filters to replace hash values in notification messages to reduce the message overhead and enhance the effectiveness of the verification phase. A vehicle in SPECS uses a different pseudonym

538


in each session to protect its privacy, whereas the real identity is traceable only by the CA. With regard to actual experimentation on VANET security that was done by several projects such as SeVeCom and SafeSpot, we notice that most projects focused on the security of safety beacons or traffic messages. For example, [29] describes the types of applications whose security requirements were considered by SeVeCom. These applications vary from collisions to cruise control, including obstacles and work zone warnings. Hence, the security of data messages from SPs or web servers is not considered. In addition, ITSSv6 [18] focuses on its security aspects on the security and privacy of messages and users only in safety and traffic applications. According to [31], such applications require tight deadlines for message delivery (less than 100 ms). Furthermore, the data exchanged in these applications are usually not confidential. Hence, all proposed security systems rely on elliptical curve cryptography or ECC, because it produces less delay overhead than other schemes, particularly symmetric ones. However, the secrecy level of the exchanged data is sacrificed. According to [19], ECC keys should be twice the length of equivalent symmetric key algorithms to provide the same security level. Hence, it is better to use a symmetric scheme to encrypt data messages, because these messages do not have a delay restriction. Rather, a high security level is required, because very sensitive data could be exchanged between users and Internet servers through the RSUs (such as e-mails, money transfers, and criminal records). In this paper, we argue that the security of users should be accounted for, starting from the initial contact between a user and an RSU. Hence, we describe a web-based secure registration process that allows a user to create an account with RSUs. During the registration, users provide all required information that enables them to have the benefit of secure connectivity starting from the first packet that they send to the RSUs. We propose a novel cryptographic function that enables users and RSUs to apply the required security level of exchanged messages by adjusting the number of iterations of the function. 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 a set of encryption keys that are used to encrypt the next packet from part of the data in the current packet.

III. P ROPOSED F RAMEWORK A. System and Security Models The last decade has witnessed a rising interest in vehicular networks and their numerous applications. Although the primary purpose of VANET standards is to enable communication-based automotive safety applications, they allow for a range of comfort applications. Many services could be provided by exploiting RSUs as delegates to obtain data on the user’s behalf. These services span many fields, from officeon-wheels to entertainment, downloading files, reading e-mail while on the move, and chatting within social networks. In this paper, we design a service-oriented vehicular security system that allows VANET users to exploit RSUs in obtaining

various types of data. In REACT, users register once with the RSUs online (through the Internet) before they start connecting to the RSUs from their vehicle. After registration, the RSUs obtain from a trusted authority (TA) a master key (Km ) for the user. The users get their Km the first time they connect to an RSU from their vehicle. We describe a novel algorithm that uses the users’ password from their account to securely transfer their Km to them. Km will be used to encrypt the initial packet key, which is assigned to the user at the beginning of each session. Then, each packet will be encrypted by a set of derived keys. With regard to the assumptions, we presume that each vehicle is equipped with a positioning system (e.g., Global Positioning System) and a digital map and has an Electronic License Plate (ELP) [33] installed. We also assume a hybrid RSU architecture in which some RSUs are directly wired to each other, others connect to the RSU network through the Internet (using gateways), whereas a third group is both wired to other RSUs and has an Internet connection. In all cases, however, each RSU has a way of connecting to any other RSU (possibly through other RSUs). In addition, several TAs are connected to the RSUs through secure wired links. Similar to [15], we assume that TAs have powerful firewalls and other protections that prevent them from being compromised. In addition, the RSUs are supposedly equipped with trusted platform modules (TPMs), intrusion detection systems, and firewalls that enable them to resist software attacks. These assumptions were made by several works such as [16] and [22], which showed that RSUs can be well defended against software attacks. With respect to hardware attacks, RSUs can be monitored using hidden surveillance cameras such as digital video or analog CCTV cameras that report to a central station, in which observers can immediately notice a hardware attack and take the appropriate actions. The RSUs do not store sensitive data, but each RSU has a secure connection to a database server that stores the RSUs’ private information. Each RSU will have its own database to avoid the effect of failures. In addition, we assume that each RSU will be monitored by a TA, which, upon detecting a malicious behavior from the RSU, will isolate it from the network by informing other RSUs, which inform vehicles that are connecting to them. A secure protocol (such as IP tunneling) is assumed to connect RSUs to one another. For VANET users, we assume that each user will connect to a single RSU at a single time (to reduce overhead). Vehicles and RSUs exchange messages using unicast when they are within direct range and depend on the network-layer routing protocol when they are apart. For this purpose, we designed an efficient routing protocol that transfers messages between a vehicle and an RSU (and vice versa) through other vehicles in a reliable manner. Our routing protocol, called ROAMER [25], outperformed many routing protocols in terms of delivery ratio, delay, and bandwidth consumption. The details of ROAMER (which we used in the simulations of REACT) can be found in [25]. Fig. 1(a) illustrates the environment of REACT. B. Registration and Session Management Because vehicles might be occupied by several users, where each user might have his/her own interests, it is better to


Fig. 1. (a) Sample architecture of REACT. (b) Sample online registration scenario.

consider each user as a distinct member and give him/her a unique account with the RSUs. Hence, we require users to register with the RSUs at the beginning through the web before they start connecting from their vehicles. The registration is done by the user only once to create an account with the RSUs and to benefit from security measures that exist in Internet protocols. These measures will enable users and RSUs to exchange credentials and keys that will help them start their connection in the VANET in a secure way. 1) Registration: When users register using the RSU website, they specify their personal details (i.e., name, address, and phone) plus a username and password to use for authentication when they connect to the RSU network from their vehicle. Users also choose a default RSU, which will save their account in its database. Examples of users’ interests are web pages, certain news, traffic information in certain areas, and email messages (possibly from different email accounts). When they later connect to the VANET, they send a Hello packet to the nearest RSU, which will notify their default RSU, which, in turn, retrieves their interests from its database and collects the required data for them. This later operation might entail fetch-

539

ing certain news and grouping them, contacting web servers and saving their HTML files, contacting email servers on the user’s behalf, and downloading messages. User can choose any RSU as their default one, but it is best to select the nearest to their starting point in the VANET. Some user interests may require authentication, which means that the RSU needs to obtain from the users their credentials with the corresponding SPs so that it can connect to these SPs on the users’ behalf. In REACT, we require users to provide during registration their authentication data with these SPs in addition to a secret key Kc (e.g., a sequence of 12 random characters) that is used by the RSU to encrypt their authentication data and save them. The RSU does not save Kc , which remains a secret to the users. When the users connect to the VANET from their vehicle, they send Kc (encrypted with their master key) to the RSU, which will then use Kc to decrypt the user’s credentials with the SPs and obtain the data. However, the RSU in this last step does not save Kc , which is used by the RSU’s software only. This way, the user credentials with other systems remain hidden in the RSU database. Nevertheless, it uses them to obtain the users data as fast as possible after the users have connected to the VANET. In addition, the users provide, during registration, the ELP of the vehicle from which they will connect to the VANET. The ELP will enable the users to obtain their master key, as we will explain later. 2) Master Key: After the users have registered, their default RSU saves their account and contacts the TA to obtain a master key (Km ) for them. The users obtain Km the first time (after registration) they connect from their vehicle to one of the RSUs. To achieve this, we propose a technique (see Section III-C1) that depends on deriving a group of encryption keys from the users’ password (of their account with the RSUs) and using these key to securely transfer Km to them. To generate these keys, we propose a new key derivation and encryption function. One of the inputs to this function is an initial iteration count (IC1 ), which is an integer kept as a secret between the user and the RSU. After registration, the RSU generates IC1 and sends it to the user (online during the Internet session in which the user registers), who saves it and uses it as an input to the hierarchal password-based key derivation (HARDY) function (see Section III-C1) when he/she obtains and decrypts Km . Fig. 1(b) shows an example of a user’s registration. 3) Participating in a Session: Each time a user connects to an RSU, he/she starts a new session. To preserve users’ location privacy, we make an RSU assign to a user a new pseudonym in each packet (as we will explain in Section III-C3). A user starts a session by sending a Hello packet that contains his/her 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 systems, according to his/her interests in his/her profile. Interests that require authentication with other systems will be delayed until the RSU gets Kc from the user. Although the RSU prepares users’ data, it assigns them a pseudonym and sends it to them in an ID packet. The user replies with an “Identify” packet that contains his/her username, password, and Kc . Both packets will be encrypted using Km . The RSU authenticates users using

540


Fig. 2. Sequence diagram for participating in a session.

their password, and if successful, it retrieves from its database the user’s encrypted credentials with other SPs and uses Kc to decrypt them on the fly and sends them to the corresponding SPs on behalf of the user and obtains their data. Note that a user in REACT will authenticate the RSU implicitly. We thoroughly explain in Sections III-C2 and C4 that Km and the keys used to encrypt/decrypt other packets (which we call packet keys) will securely be transferred between the user and the RSU. Accordingly, we assume that only the RSU and the user will be able to encrypt/decrypt packets with the user’s master key or packet keys. If an attacker stores a packet from the RSU to the user and tries to send it later to the user, pretending that he/she is the RSU, the user will detect the attack from the timestamp. Hence, using timestamps and securely transferring keys will assure the users that they are receiving packets from the RSU and not from an attacker. After the RSU has authenticated the user, it obtains from the TA a packet key Ks (definition in Section III-C4), encrypts Ks with the user’s Km , and sends it to the user in a Packet Key packet. Ks will be used by the users to encrypt the first packet after they have received the Packet Key packet. Then, each packet will be encrypted using a new set of keys (see Section III-C4). Fig. 2 shows a sequence diagram of the operations explained in this section. One important note to clarify is that, in traditional infotainment applications, Internet access is provided to vehicles by

making a vehicle act as a mobile router (MR) that connects to the access router (AR) at the RSU. The AR then assigns to the MR an IP address, which is called a care-of address (CoA) that enables the vehicle to have a seamless Internet connectivity. In 2005, the Internet Engineering Task Force (IETF) proposed the Network Mobility Basic Support (NEMO BS) standard to enable IP mobility in VANETs. The GeoNet project [14] and the ongoing ITSSv6 project [18] deal with solving problems related to integrating IPv6 in VANETs. In REACT, we do not adopt the approach of assigning to each vehicle an IPv6 address that makes it directly connect to the Internet. As stated in [12], the end-to-end IP communication standardizes the network layer but increases the network overhead and generates serious problems for address autoconfiguration. Hence, in REACT, we adopt the concept of opportunistic V2I communications as proposed in [12], in which a vehicle sends requests toward the Internet through the nearest RSU using multihop. The RSU then obtains the answer from the Internet and sends it to the vehicle also through other vehicles. This approach requires an efficient routing protocol that ensures message exchange between vehicles and RSUs. Hence, we used the ROAMER protocol [25], which we specifically proposed for our data acquisition system and proved to reliably and efficiently deliver messages between vehicles and RSUs. 4) Switching Connection Between RSUs (Handover): A vehicle observes its current location at constant intervals of time and calculates its distance from all nearby RSUs using the digital map. When it finds that it is much closer to another RSU (e.g., closer by a factor of 30%), it switches to it. Contrary to handover in traditional wireless networks (such as cellular networks), where the communication between the mobile user and the access point is always through a single-hop connection, the communication between a vehicle and an RSU could traverse several vehicles (i.e., multihop). Hence, the packets exchanged between the vehicle and the RSU during a handover could be sent in a multihop manner. These packets are small in size and, hence, will take much less time to travel compared to data packets. We show in Section V-B5 that the handover delay in the simulations that we made is less than 20 ms. This is mainly due to using an efficient routing protocol (ROAMER [25]), which we specifically designed to route packets by combining store-and-forward and location-based routing techniques. The results in [25] prove the superiority of ROAMER over three recent VANETs routing protocol and its ability to route packets between far locations. We explain the handover process using the following scenario. Suppose that a user U is connecting with RSU R1 and wants to switch to RSU R2 . U sends to R1 a Handover Request that contains the ID of R2 . This prompts R1 to send to R2 a Handover packet that contains U ’s username, his next pseudonym with R1 (pn ), and his next packet key (Kn ). Next, R1 sends to U a Handover Confirm that contains pn and Kn . This last packet will be encrypted with the user’s current packet key at R1 (as we will explain in Section III-C4). U then sends to R2 a Hello message (encrypted with Kn ) that contains his username and pn . R2 decrypts the Hello message, checks that the username and pn are valid, and then assigns to U a new pseudonym and sends it to him in an ID packet.


Fig. 3.

Sequence diagram for switching connection between RSUs.

After R1 has sent the Handover Confirm, it waits for a short period of time τ before it sends U ’s data in its cache (if any) to R2 . This time allows requests in transit sent from U to R1 to arrive and allows replies being sent to R1 from data sources to reach R1 . Next, R1 sends all pending requests and data replies for the user to R2 , which, in turn, sends to U the replies that are ready and the pending requests to their SPs. That is, the services offered to U will not be interrupted. Fig. 3 shows the sequence of actions performed during handover. Note that K1 and K2 in Fig. 2 and K1 , K2 , and K3 in Fig. 3 are packet keys, which will be explained in Section III-C4. C. Security and Privacy 1) HARDY Function: To provide data confidentiality, encryption is used to allow only the legitimate user to read and process the transmitted data. Cryptographic schemes are either symmetric or asymmetric, where symmetric schemes use a single key for both encryption and decryption, whereas asymmetric schemes use a public key for encryption and a private key for decryption. Several cryptographic algorithms are currently used in various types of applications, such as RSA and ECC for asymmetric encryption and AES and Twofish for symmetric encryption. In VANETs, to secure vehicular communications, the Wireless Access in Vehicular Environments (WAVE) standard mandates the use of public-key infrastructure mechanisms, where service application messages are encrypted, and vehicle safety messages are digitally signed. All implementations of the IEEE 1609.2 standard shall support the elliptical curve digital signature algorithm (ECDSA) as the signing protocol and the elliptical curve integrated encryption scheme (ECIES) as the encryption protocol [31]. Although ECC was chosen for the stringent delay requirement in safety applications, it does not provide the best security and protection level for serviceoriented applications. This is particularly true with the fact that asymmetric encryption schemes are vulnerable to quantum

541

computing attacks [19] that might become possible in the future. In this paper, we design an algorithm for securing data messages based on using a symmetric scheme for cryptographic operations. The algorithm is used by the source to generate a sequence of keys from a secret input string (S) and uses these keys to encrypt the next packet. The input string (S) is specified as part of the data in the current packet. We also use this algorithm to transfer the master key of the user to him/her, where the input string (S) to the algorithm will be the user’s password. The idea of deriving an encryption key from a sequence of characters goes back to the 1970s, and the first standardization effort began in 1996 as the IEEE announced the P1363.2 supplement, which defines the “password-based public key cryptography” techniques. Currently, the P1363.2 standard contains a number of password-authenticated key agreement and key retrieval schemes such as PAK, SPEKE, SRP6, and PKRS. On the other hand, current research trends have focused on using password-based key derivation functions in designing modern password-based encryption schemes. For example, the PBKDF2 function (specified in RFC 2898) [32] uses a cryptographic hash function such as SHA, RIPEMD, or WHIRLPOOL a salt (e.g. 64 b) and a large iteration count (often 1000 or more) to generate a cryptographic key from a sequence of characters. Recently, there have been proposals to use algorithms that require large amounts of computing resources to make custom hardware attacks (which use parallel hardware) more difficult to mount. One concrete instance of such an algorithm is the scrypt() function [30], which is based on the concept of sequential memory-hard functions. The scrypt() function uses PBKDF2, in addition to a pseudorandom function (PRF), to generate p blocks of length L octets from the provided password and salt. These blocks are independently mixed using a mixing function, and the final output is then generated by once again applying PBKDF2 using the well-mixed blocks as salt. The authors in [30] claim that the scrypt() function will require an attacker a cost of 175 × 109 to crack a ten-character password in one year. The main drawback in [30] is that the authors do not study the additional overhead that memory-hard functions impose on encryption/decryption in case the key is changed very often. In REACT, we propose an algorithm that uses the PBKDF2 key derivation function in several iterations to strengthen the security of the encrypted message. The hardiness of cracking the final message is much increased at the expense of slight overhead in executing the algorithm. Our proposed algorithm (HARDY function), described in Fig. 4, is executed by the source to generate n encryption keys. The first key is calculated as K1 = PBKDF2 (S, S1 , IC1 , L). Each of the other n − 1 keys is calculated as Ki = PBKDF2 (Ki−1 , Si , ICi , L). In other words, the first key K1 is obtained by executing the PBKDF2 function that passes to it S (a secret sequence of characters of constant size, as explained in Sections III-C2 and C4, S1 (a random salt of size Ss b, e.g., Ss = 128), and IC1 (the initial iteration count). As clarified in Section III-B2, IC1 will be sent online by the RSU to the user and will be a common secret between them. Each of the other n − 1 keys (K2 up to Kn ) is

542


Fig. 4. HARDY function for encrypting and decrypting messages.

obtained by executing the PBKDF2 function that passes to it Ki−1 (which is the key from the previous iteration), Si (random salt), and ICi (random iteration count). After generating the n keys, the source executes a for loop, in which the last key (Kn ) is used to encrypt the plain-text message Mp , whereas each of the other keys is hierarchically used to encrypt the salt and iteration count of the next stage in addition to the last encryption. Hence, the final cipher message will be Mc = S1 EK1 [IC2 S2 EK2 [IC3 S3 . . . EKn−1 [ICn Sn EKn [Mp ]]

.

Note that the salt will have a constant size (e.g., Ss = 128 bits). Hence, when the destination (RSU or user) obtains Mc , he separates the first Ss b and saves them as S1 . Then, he uses the string S, S1 , and IC1 to calculate K1 . Next, he uses K1 to decrypt the rest of Mc to obtain IC2 S2 m2 . Again, he separates IC2 and S2 (each having a constant size) and uses them, in addition to K1 , to obtain K2 . He then uses K2 to decrypt m2 , and so on. When the destination calculates the final key (Kn ), he uses it to decrypt the final inner message (mn ) to obtain Mp . Suppose that an attacker obtains Mc and attempts to perform brute-force dictionary attacks on it to deduce Mp . First, the attacker can obtain S1 and m1 from Mc but will not know S and IC1 . Hence, the attacker will be forced to try all possible values of IC1 on each possible value of S in the dictionary. Suppose that IC1 can take values between 1000 and (231 − 1); then, the attacker will have to run the dictionary attack 1.073 × 109 times (on the average). The basic idea is that, each time the attacker

tries a combination of S and IC, he obtains a candidate key Kc . The only way for the attacker to find if Kc is equal to K1 is by trying to decrypt m1 using Kc . Now, because m1 contains IC2 S2 m2 , and S2 is a random sequence of bits, IC2 is a random integer, and m2 is a cipher block, the attacker should check if the result of decrypting m1 with Kc is a possible combination of the aforementioned three items. However, even if the attacker obtains a possible combination of (IC2 , S2 , and m2 ), he cannot be sure that Kc is equal to K1 , because many other keys that are different from K1 might produce such a combination. Hence, the attacker is obliged to execute the whole algorithm on each possible combination of S and IC to check if this combination produces a candidate value of Mp , which is a very expensive operation that could take more than 109 times than solving for a dictionary attack. According to [30], the dollar-year cost of performing a dictionary attack on PBKDF2 using ten random sequences of characters is about 160 × 106 dollars per year. The scrypt() function outperforms PBKDF2 by a factor of 4000, whereas our algorithm outperforms it by a factor of 109 , which means that it costs about 160 × 1012 dollars to crack a plaintext message encrypted using HARDY in one year. Note that, although there is a similarity between our encryption scheme and what is known as onion encryption, because both schemes use several iterations to encrypt a message, there is a major difference in that onion encryption depends on each intermediary node to uncover an iteration of the encryption, with the destination receiving the message encrypted in a single iteration only. In our scheme, we do not pay any concern to intermediate nodes whose roles will be only to forward the message, with the destination receiving the plain-text message encrypted with all n iterations. Another basic difference is that onion routing is only suitable for asymmetric encryption, whereas our approach uses symmetric encryption. 2) Transferring the Master Key to the User: After the users have registered, they need to obtain their master key Km from the RSUs. However, the RSU needs to authenticate the users to send Km to them. However, the users cannot send their password to the RSU in plain text. To solve this problem, we propose that the RSU will use HARDY to generate a sequence of encryption keys from the users’ password and uses them to safely transfer Km to them. The users use their password to generate the same keys and to decrypt Km . Note that we do not discuss the strength of the user’s password because it is outside the scope of this paper. However, we assume that RSUs accept only passwords with high entropy (e.g., above 60). Users start their initial session after registration by sending an Initiate packet to their nearest RSU. This packet contains the users’ username and ELP. According to [33], the ELP is a unique electronic identifier that is 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 to the TA, which authenticates the user and replies to the RSU. If the RSU receives a positive reply from the TA, it obtains from the user account the password, IC1 , and Km and executes the HARDY function. Here, the user’s password (P) will be passed to the HARDY function as the string S, and Km will be passed as the plain-text message Mp . The result of HARDY will be the cipher message Mc , which the


RSU sends to the user in a Master Key packet. The user executes the HARDY function, passing to it (P) and IC1 , to decrypt Mc and obtain Km . Note that, as long as the user’s password and IC1 are known only to the user, he/she is the only one who can decrypt Mc . Hence; the security of Km is coupled with the secrecy of the password and IC1 . For this reason, the user needs to keep these two in a very safe state and should obtain a new password and IC1 from the RSUs each time he/she changes his/her master key. Note that 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 highly sophisticated attacks will not be able to crack Km . 3) Ensuring Location Privacy: In Section II, we provided a summary of the methods proposed so far to provide the location privacy of users. We described the major disadvantages that exist in these methods, such as pseudonyms refill and unknown adversary locations. To deal with these disadvantages, we adopt the concept of ad hoc anonymity [20] in REACT while modifying it by making an RSU give the user a new pseudonym each time it sends a packet to him/her. Each RSU will have its own address pool, which can be viewed as a hash function that hashes the username to an integer within a certain range. Pseudonyms are made of the following two parts: 1) the RSU ID and 2) the random ID picked by the RSU from its address pool. If conflicts occur, a rehash of the obtained ID is performed. Because an RSU is expected to frequently send control and data packets to a vehicle during their connection, the pseudonym change frequency will be high. Each time a vehicle needs to change its pseudonym, it needs at least one neighbor that is ready to enter a mix zone with it. Then, multiple dummies can be created to ensure a powerful mix zone that can deceive the attacker, as proposed in [20]. Note that a pseudonym change should be accompanied with changing both the physical and medium access control (MAC) addresses so that the attacker will not be able to link the two pseudonyms together. ITSSv6 [18], which is an ongoing project for standardizing the use of IPv6 in VANETs, is expected to study the best possible methods for using pseudonyms in IPv6 and the required changes at the physical and MAC layers. In REACT, each RSU stores a table Tr that contains five fields, i.e., username, current_ID, next_ID, current_key, and next_key. Current_ID is the last pseudonym that the RSU sent to the user, whereas 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 users, it identifies them by looking up their 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 users as their new pseudonym. The RSU then generates a new pseudonym Pn and replaces the users’ current_ID with their next_ID and the current value of next_ID with Pn . 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, i.e., username, old_ID, old_cur_key, and old_next_key. In the future, if the RSU receives a packet from the user in which he/she uses his/her old pseudonym, it assumes that the user has not received the new pseudonym (due to lost packets). Hence,

543

the RSU resends current_ID (from Tr ) to the user in the next packet. Fig. 5(a) shows different scenarios of an RSU assigning pseudonyms to a user. Note that, although several users could share the same vehicle, each user will have his/her own username and assigned his/her own pseudonyms. To allow all users in a vehicle to communicate with the RSU, a simple table that maps each user (i.e., username and pseudonym) with his/her device ID can be stored at the vehicle’s onboard unit (OBU). The OBU updates the table each time a user acquires a new pseudonym. Hence, the OBU will forward a packet to the correct user by getting his/her pseudonym from the packet and then fetching his/her device ID from the table. 4) Packet-Based Keys: Many proposed systems for VANET security disagree on the best key-management method to be used when assigning encryption keys to vehicles. Using a single key to encrypt all messages in a session allows an eavesdropper to relate the key with its source, which violates the user’s privacy. Hence, short-lived keys are used to strengthen the confidentiality of data and preserve the user’s privacy. In [33], keys are preloaded by the TA and periodically renewed after all the keys have been used. In [34], it is proposed that the encryption keys should frequently change (e.g., every couple of minutes), depending on the driving speed. Another approach [17] assumes that the encryption key is changed whenever connecting to a new SP. A recent scheme [3] assumed that the keys should be changed depending on the frequency with which the vehicle joins the network. The approach of periodic key renewal is considered unsafe, because an attacker can eavesdrop the packet that contains the new keys and apply a brute-force attack [2] to get the keys. In REACT, we define the concept of packet-based keys, where each set of keys will be used to encrypt a single packet. In addition, a packet key is not sent from the RSU to the user in a specific packet; rather, it is derived from the encrypted content of the current packet. When a user U starts a new session with an RSU R, the RSU obtains from the TA a packet key Ks and sends it to U , encrypted with his Km . U uses Ks to encrypt the next packet that he sends to R. Then, each packet will be encrypted with a new set of keys. 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. A string S will be chosen starting from this byte. For example, if the size of S is 40 and if the value of start_of_key is 47, then U will count 47 B from the start of data and will save the next 40 characters as the new value of S with which the next set of packet keys will be derived. The user must check the entropy of S before sending the packet. If the resulting S has an entropy below a certain threshold (e.g., 60), U changes the value of start_of_key, checks the entropy of the new S, and so on. If U tries many values of start_of_key without finding a suitable S, he generates a suitable random value of S and adds it at the end of the packet. Fig. 6 illustrates this example. The value of S will be passed as an input to the HARDY function, along with IC1 and Mp . HARDY will encrypt Mp in n rounds, as described in Section III-C1. The result will be the cipher message Mc that will be sent to the destination. Each user stores a table Tu that consists of the following two fields:

544


Fig. 6.

Fig. 5. Sample examples of (a) assigning pseudonyms by the RSU to the user and (b) assigning packet keys by the RSU and the user.

Packet format in REACT.

1) current_key and 2) next_key. In addition, the table Tr at each RSU contains these two entries for each user, as illustrated in the previous section. When an RSU R obtains a packet key Ks from a TA for a user U , it stores Ks in the next_key field in U ’s entry in Tr . When the user receives Ks , he also stores its value in the next_key field in Tu . Then, when an RSU (or a user) receives an encrypted packet Mc , it uses the next_key field to decrypt the packet. Next, the RSU (or user) calculates the value of S from the received packet (S1 ) and uses it as an input to the HARDY function along with the next message that it needs to send (P1 ). P1 will also contain a value of start_of_key, which will correspond to a new S (S2 ) that will be used by the receiver of P1 to encrypt the next packet, and so on. Hence, the RSU (or user) will update its table by replacing current_key with S1 and by replacing next_key with S2 . Similar to the previous section, each user will have a table Ttem that contains the following two fields: 1) old_cur_key and 2) old_next_key. Each RSU also stores a table Ttem , as explained in the previous section. 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 a destination receives a packet and fails to decrypt it using next_key from Tr (or Tu ), it attempts to decrypt it using old_next_key from Ttem . If it succeeds, it assumes that the source has not received the last packet and reuses old_cur_key and old_next_key from Ttem instead of current_key and next_key from Tr (or Tu ). Fig. 5(b) shows different scenarios of exchanging packet keys. Note that one major advantage of using packet keys is to resist replay attacks. If an attacker tries to cache a message for a certain period and then sends it to its destination, he will fail, because the string S that was used to generate the packet keys that were used to encrypt the message will no longer exist in Tr (or Tu ) of the destination. Hence, the destination will fail to decrypt the message with next_key and old_next_key. Hence, the destination will deduce that the packet is old and will ignore it. One important factor that defines the security level and, consequently, the additional overhead is the choice of n, which is the number of phases in HARDY. A higher value of n means that an attack on Mc will be more difficult, at the expense of some additional time for the legitimate user to obtain Mp . However, n cannot indefinitely be increased, or else, the user will spend a lot of time executing HARDY. The time required to execute the PBKDF2 function depends on the PRF used (such as SHA256 and RIPEMD256). In addition, the time of the encryption (or decryption) process will depend on the cryptographic algorithm used. Suppose that a single iteration in HARDY (PBKDF2 + decryption) requires Sph s. If we consider


that the time for executing HARDY by the user should be a maximum of Sr s, then n can be set to Sr /Sph . Overall, the HARDY function is dynamic, because it takes the value of n as an input, which allows the user to specify the required security level. Another factor is the size of packet keys. According to an analysis made for effective lengths of symmetric keys, an 80-b key will take an attacker about one year to crack if he can build a machine that can check 1018 keys per second (which is stated in [2] as a very hard task). Hence, sensitive data can be encrypted using a 128- or 256-b symmetric key, whereas less sensitive data could be encrypted using an 80- or a 128-b key. IV. A NALYSIS A. Efficiency of the Proposed Cryptographic Scheme To analyze the efficiency of our proposed encryption scheme, we make use of the analysis that was done in [35], in which mathematical expressions were derived for the encryption and the decryption delays of AES. These delays were expressed as a function of the key size, the block size, and the number of processing cycles required for performing basic operations that are used in AES such as bytewise AND (Ta ), bytewise OR (To ), and bytewise shift (Ts ). The resulting general expression is TAES−Enc = (46Nb Nr − 30Nb )Ta + [31Nb Nr + 12(Nr − 1) − 20Nb ] To + [64Nb Nr + 96(Nr − 1) − 61Nb ] Ts (1) where TAES−Enc is the number of processing cycles required to encrypt one block of data, Nb is the block size, and Nr is the number of iterations (which is equal to 10 when the key size is 128 b). Assuming that each basic operation requires one processing cycle, i.e., Ta = To = Ts = 1, [41] derives the number of processing cycles to encrypt one block of data as TAES−Enc = 6168 processing cycles. Depending on the size of the packet to be encrypted and the number of million instructions per second (MIPS) of the processor, [41] derives the total encryption time of a packet of size Sd as 8 × Sd TAES−Enc (2) TAES−Enc (Sd , Cp ) = × 128 Cp where Sd is given in bits, and Cp is given in MIPS. In a similar way, [41] calculates the number of processing cycles to decrypt one block of data and the total decryption delay of a packet as TAES−Dec = TAES−Enc + (Nr − 1) × (96Nb Ta + 72Nb To − 32Nb Ts ) (3) 8 × Sd TAES−Dec . (4) tAES−Dec (Sd , Cp ) = × 128 Cp In our system, we have n encryption rounds for each packet. Suppose that the plain-text message Mp has a size equal to

545

Sd1 b (which is the encryption size of the first iteration). Each iteration will concatenate Si and ICi to the resulting cipher message from the previous iteration before encrypting the result. Hence, the message to be encrypted by iteration i will have a total size Sdi equal to round one : Sd1 (size of plain - text message) − of (salt) round two : Sd2 = Size + Size − of (IC) Sd1 + × Bl Bl − of (salt) + Size − of (IC) round three : Sd3 = Size Sd2 + × Bl Bl ··· ∴ Sdi = Size − of (salt) + Size − of (IC) Sd(i−1) + × Bl (5) Bl where Bl is the size of one encryption block in AES, which is equal to 128 b. Based on (5), we derive the total encryption time of a packet of size Sd1 as the summation of encryption times of n iterations as n 8 × Sdi TAES−Enc . (6) THARDY −Enc = × 128 Cp i=1 Because decryption in HARDY is the reverse process of encryption, we can deduce that the sizes of the n iterations in decryption will be the reverse of those of encryption (in other words, the size of the first iteration will be equal to Sdn , the size of the second iteration will be equal to Sd(n−1) , . . ., and the size of the last iteration will be equal to Sd1 ). Hence, the total decryption time can be derived as n 8 × Sdi TAES−Dec . (7) THARDY −Dec = × 128 Cp i=1 We validate the correctness of (6) and (7) by comparing their results with the simulation results in Section V-B4, in which n was varied between 1 and 20. B. RSU Deployment Cost One important design factor to consider is the density of RSUs in the VANET. It is obvious that increasing the number of RSUs (NRSU ) leads to more RSU coverage and, consequently, less packet delays and higher delivery success ratio. We proved these facts in our work in [25], in which we varied NRSU between 1 and 20 in a 9 × 9 km2 area, which corresponds to varying the RSU density between 0.012 and 0.25 RSUs per Km2 . The results showed that increasing NRSU from 5 to 20 increased the packet delivery ratio from 85% to 93% and decreased the packet delay from 8 s to 5 s. This, however, comes at the expense of increasing the cost of the RSU network deployment. Moreover, a vehicle in REACT will make a handover when it becomes much closer to a new RSU, and hence, a higher RSU density will lead to more handover occurrences and consequently increase the load on the network. Hence, there is

546


a tradeoff between improving the performance and reducing the deployment cost and network load. In the literature, there is a consensus that an RSU density between 0.16 and 0.4 would produce good system performance and acceptable packet delivery delay (0.4 RSUs/Km2 in [39], 0.25 in [40], and between 0.16 and 0.39 in [23]). There is another work ([27]) that supposed that the average distance between two neighboring RSUs could stretch to about 3 km, which corresponds to an RSU density of 0.05 RSUs/Km2 . If we simply consider the overall average density based on these works, we get about 0.23 RSUs/km2 . Our simulations in [25] involved scenarios in which NRSU was varied between 1 and 20 in a 9 × 9 km2 area and showed that, with 20 RSUs (0.25 RSUs/km2 ), the packet delivery ratio attained 80%, whereas the message delay reached 5 s. Both results are considered good according to the surveyed literature. If we roughly study the deployment cost needed to install our system, we can separate it into software and hardware costs. Software deployment costs such as the cost of installing security features at the RSUs (TPM, intrusion detection, and firewall) should not amount to more than 2000 U.S. dollars per RSU according to some online market costs. Hardware cost is dominated by the expenses of installing a CCTV system and should be less than $3000 per RSU (cost of installing camera and connecting the system to the operations center according to existing online prices). Hence, the overall additional cost for installing a network of 25 RSUs in a 10 × 10 km2 area will be about $125 000, which should be an acceptable cost for maintaining a firm network security and obtaining efficient performance. In the next section, we simulate scenarios on a map of 1.5 × 1.5 Km2 , in which five RSUs are deployed. The main reason for using such a high RSU density (2.22 RSUs/km2 ) is that our aim from the simulations is to test the performance of the security system (REACT) and not the used routing protocol (ROAMER). In this scenario, the maximum number of hops between a vehicle and an RSU will be small (less than 3, considering a transmission range of 300 m). Hence, the main factors that affect the values of the simulations results will be the operations of REACT, whereas the routing operations will have a less significant effect, because few routing procedures are needed. V. S IMULATIONS This section presents the simulations that we performed to evaluate REACT. We used the ns2 software (version 2.34 with the 802.11p amendment and the Nakagami propagation model), and we used SUMO [6] to generate the vehicle movement file that was input to ns2. The map that was 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 300 m, respectively. In the Nakagami model, we used an m-value of 3 for distances less than 50 m, 1.5 for distances between 50 and 150 m, and 1 for distances above 150 m. The default number of vehicles was set to 100, and their minimum and maximum speeds were set to 15 and 30 m/s. Each scenario was repeated ten times, and the final results are the average of the ten runs. Five RSUs were evenly deployed

Fig. 7.

City map used in the simulations.

across the map to balance their loads as much as possible. Fig. 7 shows the map and locations of RSUs. Two of the four corner RSUs were wired to the RSU at the center, whereas the other two corner RSUs and the one at 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 20 ms, and the delay for accessing the wireless SP was set to 50 ms. The delay for an RSU to send a message to another was uniformly distributed over the range [0.05, 0.1] s. Each vehicle generates every 5 s a new request that randomly targets one of the 15 SPs. Hence, the default value of the request rate (Rr ) was set to 12 requests per minute. The size of data packets was set to 350 B. This value was chosen to ensure that the size of the encrypted packet will be less than the maximum transmission unit (MTU) of 802.11 MAC (1500 B) after adding the necessary headers, as we noticed from the experiments that we made on AES using the Crypto++ package [10]. The Hello interval was set to 2 s. Finally, we used ROAMER [25] to route messages. ROAMER combines both geographic forwarding and carry-and-forward techniques and routes packets through the RSU network (if needed). Hence, it can efficiently transfer packets in various VANET conditions, as the results of ROAMER [25] prove. 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 different keys were implemented as functions in their corresponding agents. The cryptographic operations were implemented using the Crypto++ package [10]. The widely used AES algorithm was used for the encryption and decryption of messages. The number of phases in HARDY (n in Fig. 4) was set to a default value of 5. The size of the master key (Km ) was set to 256 b, whereas those of the secret key (Kc ), HARDY keys (K1 , K2 . . . Kn ), and packet key


547

(Ks ) were set to 128 b. The cryptographic operations were implemented in a separate ns2 agent that uses necessary classes from the Crypto++ package. A. Compared Protocol To compare our system with other security mechanisms that were proposed for service-oriented VANETs, we simulated the ABAKA protocol [17], which has recently been proposed as an authentication and key agreement scheme for VANETs. It uses ECC at the RSUs to authenticate requests from multiple vehicles at the same time. The basic difference between REACT and ABAKA is that our system does not require SPs to authenticate each message as ABAKA does (i.e., REACT does not require the use of certificates), because REACT relies on the RSUs to assign the next key from the contents of the packet. Hence, the use of the correct key to encrypt a message is equivalent to the verification message in ABAKA. In addition, ABAKA requires a tamper-proof device to be installed in the vehicle, whereas we do not. Finally, ABAKA requires the SP to generate a session key for each requested service, whereas 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 our system (128 b) 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 given as follows: 1) message success ratio (MSR), which is the percentage of messages that are successfully received at their destinations; 2) message response time (MRT), which is the total time required to send a request from a vehicle to an SP and to receive the answer; 3) initialization phase time (IPT), which is the system security initialization time, i.e., the average time between the instance a vehicle starts a session to the instance it sends the first packet encrypted with a session key (or packet key); 4) average overhead traffic (AOT), which is the extra traffic (mainly due to security packets and to the increase in the size of packets due to cryptographic operations) sent or received by a vehicle. Note that the IPT is calculated in REACT as the time between the user sends the first Hello packet and the time he receives the first packet key (i.e., Ks ), whereas in ABAKA, it is the time required for the “pseudoidentity generation” and the “batch authentication and key agreement” phases to complete (because a user and an SP need to complete these two phases before they agree on a mutual session key [17]). B. Simulation Results 1) Varying the Request Rate: Fig. 8(a) shows that the MSR of REACT is much higher than that of ABAKA when varying the request rate Rr . The main reason is that, in REACT, an RSU prepares the user’s data on his behalf. The probability of successful data retrieval through the fixed network is higher

Fig. 8. (a) MSR, (b) MRT, (c) IPT, and (d) AOT of REACT and ABAKA for different request rates.

than that through the wireless network. In addition, RSUs cache certain types of data (such as news, advertisements, and web pages). Whenever a user requests a data item that exists in the RSU cache, the RSU sends the item to him without contacting the SP (on the condition that the item has not expired). This fact increases the value of the MSR in REACT. Fig. 8(b) shows the total delay between the instance at which a vehicle issues a request packet and the instance at which it receives the answer. The total delay reflects the efficiencies gained by assigning keys from within the packets themselves and having RSUs contact SPs on behalf of the users. In ABAKA, each time a vehicle wants to contact an SP, it should send its authentication data and negotiate with it a session key. Fig. 8(b) shows that these operations considerably increase the delay of a packet. The two systems seem to have similar latencies when Rr is small, mainly because the network is relaxed, and the packets are directly sent without queuing. At Rr = 60 requests per minute, ABAKA produces a delay of 320 ms, which is approximately 1.5 times that of REACT. The main reason for this increase 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 (which can directly be done after the user has sent a Hello, i.e., considerable time is saved). The next parameter that we examine in Fig. 8(c) is the IPT, which in ABAKA includes the following: 1) sending the request to the SP through the RSU; 2) vehicle verification and key agreement (at the SP); and 3) mutual authentication and key agreement (between the vehicle and the SP). The IPT shows how much of the latency is due to security operations. The figure shows that REACT has a much lower IPT than ABAKA,

548


Fig. 9. (a) MSR, (b) MRT, (c) IPT, and (d) AOT of REACT and ABAKA for different numbers of vehicles in the network.

particulalry for high Rr . This indicates that the handshaking between the user and the RSU in REACT is faster than the three-way handshaking in ABAKA (between the user, RSU, and SP). Finally, we show in Fig. 8(d) the overhead traffic per vehicle (in kilobits per second), which is due to exchanging security messages and also to the increase in the sizes of messages because of encryption. The AOT was calculated by recording for each message type the total number of sent, received, and forwarded messages, multiplying each number by the message size, summing the results, and dividing by the total number of vehicles and by the simulation time. Fig. 8(d) shows that, when Rr is low, the two systems produce similar AOTs. As aforementioned, when Rr is low, the network is relaxed, and packets are directly sent without queuing. When Rr increases, network congestion is expected, and packets are delayed or dropped. For this reason, ABAKA experiences high overhead traffic due to its dependence on broadcasting operations (because “Hello,” “Request,” and “Reply” packets are broadcast in ABAKA), whereas REACT avoids broadcasting by using pseudonyms and unicasting. 2) Varying the Number of Vehicles: Fig. 9 illustrates how the four compared parameters vary when the number of vehicles in the network (Nv ) is varied between 30 (sparse) and 300 (dense). In Fig. 9(a), we notice that the MSR of REACT reaches 97% when Nv is between 110 and 200 vehicles but decreases to reach 86% at Nv = 300. On the other hand, the MSR of ABAKA reaches a maximum of 74% at Nv = 150, after which it sharply decreases to 31% at Nv = 300. These observations reflect the fact that the MSRs of the two systems increase with Nv until traffic congestion starts occurring, when the network becomes too dense. Fig. 9(b) shows that the two systems have

very similar MRTs when Nv is less than 200. Then, REACT produces a lower delay, given that a vehicle in ABAKA broadcasts a packet to the SP (using other vehicles) even if the SP is very far away. In dense conditions, a packet might be broadcast by many vehicles to far destinations, causing congestions and packet delays. In REACT, a vehicle sends packets to its nearest RSU, which is responsible for sending the request to the SP. Hence, packets with long routes are avoided in REACT. For this reason, we notice that the MRT of REACT increases with Nv , but at a much less rate that that of ABAKA. In addition to decreasing the delay, this property increases the MSR of REACT, because a packet will have a higher probability of reaching the RSU and, hence, the SP. The IPT of the two systems shares similar behavior with the MRT, as depicted in Fig. 9(c). However, we notice that the IPT of ABAKA is very high (268 ms) when Nv = 30. As Nv increases, the IPTs of the two systems decrease until they reach similar values when Nv is equal to 200. After that, the IPT of REACT barely increases, whereas that of ABAKA increases at a high rate to reach 42 ms. This means that the IPT of REACT is much less sensitive to congestion than that of ABAKA. In general, The MRT and IPT decrease as Nv increases (before congestion starts), because the increase in Nv means that a vehicle will have a higher probability that neighbors exist when it needs to forward a packet. Hence, packets remain in queues for smaller times, and the average delay decreases. Finally, Fig. 9(d) shows that the two systems have close AOTs when Nv is less than 150. When Nv is more than 100, ABAKA produces much higher traffic than REACT, which is due to the higher congestion that occurs in ABAKA because of the abundance of broadcasts, which results in great overhead when Nv is high (due to the large number of vehicles that forward a packet). 3) Varying the Maximum Speed of Vehicles: In the scenarios in this section (see Fig. 10), the maximum speed of vehicles (Sv ) was varied between 10 m/s (slow) and 60 m/s (very fast). In Fig. 10(a), the MSR of REACT drops from 97% to 63% as Sv increases from 30 m/s to 60 m/s, mainly because the cipher messages in REACT need long transmission times, which will not be available when the speed is high, because vehicles will contact each other for shorter periods of time. Based on this fact, we deduce that the size of a cipher message in REACT is higher than that in ABAKA, which is logical, because ABAKA uses simple encryption, whereas REACT uses hierarchical encryption. This fact is validated in Fig. 10(d), which shows that ABAKA produces less traffic than REACT when Sv is higher than 40. On the other hand, Fig. 10(b) shows that REACT produces less MRT when Sv is small to medium. ABAKA is less affected by the increase in speed than REACT, which can be noticed in Fig. 10(b), which shows that the MRT of ABAKA becomes less than that of REACT when Sv is higher than 40 m/s. REACT is more sensitive to the increase in speed, as we have noticed in Fig. 10(a), (b), and (d). In ABAKA, the problem of small connection times between vehicles is solved by using broadcasting. However, and opposite to the MRT, the IPT of REACT remains smaller than that of ABAKA for all values of Sv . Fig. 10(c), as well as Figs. 8(c) and 9(c), reflects that the initialization delay of REACT is lower than that of ABAKA for


549

Fig. 10. (a) MSR, (b) MRT, (c) IPT, and (d) AOT of REACT and ABAKA for different speeds of vehicles.

Fig. 11. (a) MSR, (b) MRT, (c) IPT, and (d) AOT of REACT and analytical encryption and decryption delays for packet sizes equal to 350 B (b) and 128 b (c) for different numbers of packet keys.

all network conditions. Hence, users in REACT will have the advantage of a faster security phase when they join the VANET than users in ABAKA. 4) Varying the Number of Iterations in HARDY: In this section, we test the performance of REACT while varying a very important parameter, which is the number of iterations in HARDY (n), which was changed between 1 (simple encryption) and 20. Rr was fixed at 20 req/min, and Sv was fixed at 25 m/s. The size of the plain-text message was fixed at 350 B. We recorded both the processing and the communication delays. The processing delay is the average of all encryptions and decryptions during the simulation, whereas the communication delay is the delay of routing a packet to its destination. The addition of these two delays produces the total delay. We also compare the processing delay with the analytical delays produced from (6) and (7) in Section IV-A. In Fig. 11(a), we notice that the MSR steadily decreases with the increase of n. In addition, Fig. 11(b) shows that the MRT slightly increases until the number of keys is equal to 7, after which the MRT rapidly increases. These results are due to two reasons. First, as the number of iterations of HARDY increases, the size of the resulting cipher message increases (the size slightly increases after each iteration). Hence, the size of the packet that is sent increases, and consequently, the delay increases. The second reason is that, when the size of the cipher message increases above the MTU, the message will be divided into fragments, and each fragment will be sent in a separate packet. Hence, the MSR will decrease, because it will become the minimum MSR of all fragments. In addition, the delay will become the maximum delay of all fragments. The first reason corresponds to the increase in the processing delay,

whereas the second reason corresponds to the increase in the communication delay. We also notice in Fig. 11(b) that the analytical encryption delay based on (6) increases from 0.05 s to 1.27 s, whereas the analytical decryption delay increases from 0.08 s to 2.28 s, which reflects the fact that decryption takes more time than encryption. The simulation processing delay, which was calculated as the average of all encryptions and decryptions in the simulation, varies between 0.06 and 1.82 s and is shown as an approximation of the average of the analytical encryption and decryption delays, which reflects that the analysis and simulation produce comparable cryptographic delays. With regard to the initialization delay, we notice in Fig. 11(c) that this delay is mostly due to the encryption and decryption of the first packet key that is sent by the RSU to the user at the beginning of each session. The processing delay increases as n increases, because each additional iteration adds an extra delay. On the other hand, the size of the resulting message remains small, regardless of the value of n, because we are encrypting a small size key (128 b), which means that the resulting cipher message will be much less than that of an ordinary data message. In addition, the initialization phase is usually performed while the user and the RSU are near each other. Hence, the communication delay will be small. These observations are verified by the results of (6) and (7) while setting the size of the plain-text message (Sd1 in Section IV-A) to 128 b (which is the size of the initial packet key Ks that is sent from the RSU to the user during the initialization phase). We notice that the processing delay in Fig. 11(c) is approximately the average of the analytical encryption and decryption delays (as it is supposed to be) and that the total delay is approximately

550


for the traffic). On the other hand, the delay and traffic of the master key operation follow similar trends to those of the handover operation. However, they are much smaller. The main tasks in the master key operation that produce delay are the encrypting and decrypting of the master key. In Fig. 12(c), we notice that these tasks take small times (maximum of 6.5 ms). In addition, the traffic is mainly due to the Master Key packet, which is also small (maximum of 78 b/s). As a brief summary of the results of REACT, we can deduce that REACT outperforms ABAKA in terms of the success ratio, total latency, and initialization delay in most scenarios. In addition, REACT generates less overhead traffic in most cases. When REACT produces high overhead traffic, its performance can be improved by decreasing the number of packet keys n used to encrypt a message. In addition, the main operations of REACT (obtaining the master key and handover) produce small delay and traffic.

VI. C ONCLUSION

Fig. 12. (a) and (c) MRT and (b) and (d) AOT of handover and master key operations in REACT for different numbers of vehicles.

equal to the processing delay, because the communication delay is very small. Finally, the overhead traffic increases with n, as depicted in Fig. 11(d), which is expected because of the following: 1) the average packet size and 2) the average number of packets increase. 5) Measuring the Delay and Traffic of the Handover and Master Key Operations: In the last set of scenarios, we test the performance of the following two main operations in REACT: 1) obtaining the master key and 2) doing a handover. For each operation, we recorded its start and end times to measure its delay. In addition, we recorded the number and type of packets exchanged during the operation to record its total traffic. The master key operation starts when the vehicle sends the Initiate packet and ends when the user decrypts the Master Key packet (see Section III-C2). The handover operation starts when the user sends the Handover Request packet and ends when the user receives the ID packet (see Section III-B4). Both operations were tested while varying Nv between 30 and 150 and for two vehicle speeds, i.e., 20 and 60 m/s. In Fig. 12(a), we notice that the handover delay decreases as Nv increases until it settles when Nv exceeds 130. In addition, the handover traffic [see Fig. 12(b)] steadily increases with Nv . This is because the MRT decreases, and the AOT increases as Nv increases [see Fig. 9(b) and (d)]. In general, as Nv increases, a vehicle will have a higher probability that it will find neighbors to forward the packet. In other words, the packet will be more forwarded and less queued. Hence, the delay decreases, and the traffic increases. We also notice that the delay and traffic of Sv = 60 are much higher than those of Sv = 20 because REACT is sensitive to speed, as we have noticed in Fig. 10. However, the delay and the traffic of the handover process are generally small (maximum of 34 ms for the delay and 320 b/s

How we can ensure security and privacy in service-oriented VANETs represents a challenging issue. In this paper, we have answered this question with our proposed privacy-preserving data acquisition and forwarding scheme by introducing a novel and provable cryptographic algorithm for key generation and powerful encryption. The evaluation of our proposed scheme confirmed its effectiveness compared to a recent security mechanism for VANETs. The ongoing work on REACT focuses on making the proposed system more scalable in terms of the number of users that can connect to an RSU. We are designing an RSU scheduling mechanism in which an RSU builds a schedule that is divided into time slots (TSs). In each TS, all users that are expected to connect to the RSU are specified. Hence, an RSU prepares users’ data and caches them during a free TS before the users connect. Using this scheme, the RSU distributes its load among the available TSs. An initial design of the RSUs scheduling system has recently been published in [26]. R EFERENCES [1] S. Biswas, J. Misic, and V. Misic, “ID-based safety message authentication for security and trust in vehicular networks,” in Proc. 31st ICDCSW, Minneapolis, MN, Jun. 2011, pp. 323–331. [2] “Brute-force attack,” Wikipedia. [Online]. Available: http://en.wikipedia. org/wiki/Brute-force_attack [3] S. Busanelli, G. Ferrari, and L. Veltri, “Short-lived key management for secure communications in VANETs,” in Proc. ITST, St. Petersburg, Russia, Aug. 2011, pp. 613–618. [4] L. Buttyan, T. Holczer, and I. Vajda, “On the effectiveness of changing pseudonyms to provide location privacy in VANETs,” in Proc. ESAS, Cambridge, U.K., Jul. 2007, pp. 129–141. [5] G. Calandriello, P. Papadimitratos, A. Lioy, and J. P. Hubaux, “Efficient and robust pseudonymous authentication in VANET,” in Proc. ACM Mobicom, Montreal, QC, Canada, Sep. 2007, pp. 19–28. [6] Centre for Appl. Inf. (ZAIK). (2011). Sumo—Simulation of Urban Mobility, Inst. of Transp. Res., German Aerosp. Centre, Berlin, Germany. [Online]. Available: http://sumo.sourceforge.net/ [7] D. Chaum and E. van Heyst, “Group signatures,” in Proc. EUROCRYPT, 1991, vol. 547, pp. 257–265. [8] T. W. Chim, S. M. Yiu, L. Hui, and V. Li, “SPECS: Secure and privacy enhancing communications schemes for VANETs,” Ad Hoc Netw., vol. 9, no. 2, pp. 189–203, Mar. 2011.


[9] E. Coronado and S. Cherkaoui, “Service discovery and service access in wireless vehicular networks,” in Proc. IEEE GLOBECOM Workshops, 2008, pp. 1–6. [10] Crypto++ 5.6.1 Library, Apr. 2011. [Online]. Available: http://www. cryptopp.com/ [11] X. Dong, L. Wei, H. Zhu, Z. Cao, and L. Wang, “EP2DF: An efficient privacy-preserving data-forwarding scheme for service-oriented vehicular ad hoc networks,” IEEE Trans. Veh. Technol., vol. 60, no. 2, pp. 580–591, Feb. 2011. [12] F. El Ali and B. Ducourthial, “A light architecture for opportunistic vehicle-to-infrastructure communications,” in Proc. MobiWac, Bodrum, Turkey, Oct. 2010, pp. 60–67. [13] J. Freudiger, M. Raya, M. Feleghhazi, P. Papadimitratos, and J. P. Hubaux, “Mix zones for location privacy in vehicular networks,” presented at the Int. Workshop Wireless Netw. Intell. Transp. Syst., Vancouver, BC, Canada, Aug. 2007 LCA-CONF-2007-016. [14] GeoNet Project. [Online]. Available: http://www.geonet-project.eu [15] Y. Hao, Y. Cheng, C. Zhou, and W. Song, “A distributed key management framework with cooperative message authentication in VANETs,” IEEE J. Sel. Areas Commun., vol. 29, no. 3, pp. 616–629, Mar. 2011. [16] L. Huang, K. Matsuura, H. Yamane, and K. Sezaki, “Enhancing wireless location privacy using silent period,” in Proc. IEEE WCNC, New Orleans, LA, 2005, pp. 1187–1192. [17] 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 Trans. Veh. Technol., vol. 60, no. 1, pp. 248–262, Jan. 2011. [18] ITSSv6 Project. [Online]. Available: http://www.lara.prd.fr/projects/ itssv6 [19] “Key size,” Wikipedia. [Online]. Available: http://en.wikipedia.org/wiki/ Key_size [20] H. Kido, Y. Yanagisawa, and T. Satoh, “An anonymous communication technique using dummies for location-based services,” in Proc. ICPS, Santorini, Greece, Jul. 2005, pp. 88–97. [21] C. Laurendeau and M. Barbeau, “Threats to security in DSRC/WAVE,” in Proc. ADHOC-NOW, 2006, vol. 4104, pp. 266–279. [22] C. T. Li, M. S. Hwang, and Y. P. Chu, “A secure and efficient communication scheme with authenticated key establishment and privacy preserving for vehicular ad hoc networks,” Comput. Commun., vol. 31, no. 12, pp. 2803–2814, Jul. 2008. [23] C. Lochert, B. Scheuermann, C. Wewetzer, A. Luebke, and M. Mauve, “Data aggregation and roadside unit placement for a VANET traffic information system,” in Proc. 5th ACM Int. Workshop VANET, San Francisco, CA, Sep. 2008, pp. 58–65. [24] Z. Ma, F. Kargl, and M. Weber, “Pseudonym-on-demand: A new pseudonym refill strategy for vehicular communications,” in Proc. IEEE 68th Veh. Technol. Conf., Calgary, AB, Canada, Sep. 2008, pp. 1–5. [25] K. Mershad, H. Artail, and M. Gerla, “ROAMER: Roadside Units as message routers in VANETs,” Ad Hoc Netw., vol. 10, no. 3, pp. 479–496, May 2012. [26] K. Mershad and H. Artail, “SCORE: Data scheduling at roadside units in vehicle ad hoc networks,” in Proc. ICT, Jounieh, Lebanon, Apr. 2012, pp. 1–6. [27] B. Mohandas, A. Nayak, K. Naik, and N. Goel, “ABSRP—A service discovery approach for vehicular ad hoc networks,” in Proc. IEEE 3rd APSCC, Yilan, Taiwan, Dec. 2008, pp. 1590–1594. [28] N. V. Vighnesh, N. Kavita, S. R. Urs, and S. Sampalli, “A novel sender authentication scheme based on hash chain for vehicular ad hoc networks,” in Proc. IEEE ISWTA, Langkawi, Malaysia, Sep. 2011, pp. 96–101. [29] P. Papadimitratos, L. Buttyan, T. Holczer, E. Schoch, J. Freudiger, M. Raya, Z. Ma, F. Kargl, A. Kung, and J. P. Hubaux, “Secure vehicular communication systems: Design and architecture,” IEEE Commun. Mag., vol. 46, no. 11, pp. 100–109, Nov. 2008. [30] C. Percival, “Stronger key derivation via sequential memory-hard functions,” in Proc. BSDCan, Ottawa, ON, Canada, May 2009, pp. 1–16.

551

[31] J. Petit and Z. Mammeri, “Analysis of authentication overhead in vehicular networks,” in Proc. WMNC, Budapest, Hungary, Oct. 2010, pp. 1–6. [32] B. Kaliski, “PKCS# 5: Password-Based Cryptography Specification Version 2,” RSA Lab., Cambridge, MA, 2898, Sep. 2000. [33] M. Raya and J. P. Hubaux, “The security of vehicular ad hoc networks,” in Proc. SASN, Alexandria, VA, Nov. 2005, pp. 11–21. [34] M. Raya, P. Papadimitratos, I. Aad, D. Jungels, and J. P. Hubaux, “Eviction of misbehaving and faulty nodes in vehicular networks,” IEEE J. Sel. Areas Commun., vol. 25, no. 8, pp. 1557–1568, Oct. 2007. [35] M. Razvi Doomun and K. M. S. Soyjaudah, “Analytical comparison of cryptographic techniques for resource-constrained wireless security,” Int. J. Netw. Sec., vol. 9, no. 1, pp. 82–94, Jul. 2009. [36] SafeSpot Project. [Online]. Available: http://www.safespot-eu.org/ [37] K. Sampigethava, L. Huang, M. Li, R. Poovendran, K. Matsuura, and K. Sezaki, “AMOEBA: Robust location privacy scheme for VANET,” IEEE J. Sel. Areas Commun., vol. 25, no. 8, pp. 1569–1589, Oct. 2007. [38] SeVeCom Project. [Online]. Available: http://www.sevecom.org/ [39] Y. Sun, X. Lin, R. Lu, X. Shen, and J. Su, “Roadside units deployment for efficient short-time certificate updating in VANETs,” in Proc. IEEE ICC, Cape Town, South Africa, May 2010, pp. 1–5. [40] O. Trullols, M. Fiore, C. Casetti, C. Chiasserini, and J. Ordinas, “Planning roadside infrastructure for information dissemination in intelligent transportation systems,” Comput. Commun., vol. 33, no. 4, pp. 432–442, Mar. 2010. [41] C. Xenakis, N. Laoutaris, L. Merakos, and I. Stavrakakis, “A generic characterization of the overheads imposed by IPsec and associated cryptographic algorithms,” Comput. Netw., vol. 50, no. 17, pp. 3225–3241, Dec. 2006. [42] H. Zhu, R. Lu, X. Shen, and X. Lin, “Security in service-oriented vehicular networks,” IEEE Wireless Commun., vol. 16, no. 4, pp. 16–22, Aug. 2009.

Khaleel Mershad received the B.E. degree (with high distinction) in computer engineering and informatics from Beirut Arab University, Beirut, Lebanon, in July 2004 and the M.E. and Ph.D. degrees in computer and communications engineering from the American University of Beirut (AUB), Beirut, Lebanon, in February 2007 and January 2012, respectively. He is currently a Postdoctoral Researcher with the Department of Electronics and Communications Engineering, AUB, where he is doing research in cloud computing and vehicular ad hoc networks. His research interests include mobile ad hoc networks, data management and availability, knowledge discovery, distributed computing, and intervehicle communications.

Hassan Artail received the B.S. (with high distinction) and M.S. degrees in electrical engineering from the University of Detroit Mercy, Detroit, MI, in 1985 and 1986, respectively, and the Ph.D. degree from Wayne State University, Detroit, in 1999. For 11 years, he was a System Development Supervisor with the Scientific Labs, DaimlerChrysler, where he worked on software and system development for vehicle testing applications. Since 2001, he has been with the Department of Electronics and Communications Engineering, American University of Beirut, Beirut, Lebanon, where he is currently an Associate Professor and is conducting research in Internet and mobile computing, distributed systems, and mobile ad hoc networks. During the last eight years, he has published more than 90 papers in conference proceedings and journals.

A Framework for Secure and Efficient Data Acquisition in ... - IEEE Xplore

A Framework for Secure and Efficient Data Acquisition in ... - IEEE Xplore

Suggest Documents

An Extensible Framework for Efficient Secure SMS - IEEE Xplore

A Secure and Efficient Data Aggregation Framework in Vehicular ...

Analysis and Improvement of a Secure and Efficient ... - IEEE Xplore

Secure and Efficient Data Acquisition in VANETs - Semantic Scholar

A Secure Threshold Secret Sharing Framework for ... - IEEE Xplore

Implementation of a data acquisition system for ... - IEEE Xplore

A Common Data Acquisition System for High-Intensity ... - IEEE Xplore

A Social-Aware Framework for Efficient Information ... - IEEE Xplore

A Framework for Hardware Efficient Reusable IP Core ... - IEEE Xplore

A Compressive Sensing Data Acquisition and Imaging ... - IEEE Xplore

Spectrally Efficient CSI Acquisition Approach for Large ... - IEEE Xplore

Secure Framework for Voice Transmission over ... - IEEE Xplore

Secure and Controlled Sharing of Data in Distributed ... - IEEE Xplore

Secure Data Aggregation and Intrusion Detection in ... - IEEE Xplore

Cryptanalysis of SIP Secure and Efficient Authentication ... - IEEE Xplore

Secure and Efficient Capability-Based Power ... - IEEE Xplore

Secure and Efficient Multi-Hop Mobile IP Registration ... - IEEE Xplore

A Policy-Based Framework for Managing Data Centers - IEEE Xplore

Big Data for Industry 4.0: A Conceptual Framework - IEEE Xplore

behaviorism : A Framework for Dynamic Data Visualization - IEEE Xplore

Secure Identities - IEEE Xplore

A Policy-Based Framework for Managing Data Centers - IEEE Xplore

Network Coding for Efficient Broadband Data Delivery in ... - IEEE Xplore

An efficient and secure data sharing framework ... - ACM Digital Library