Group-based hybrid authentication scheme for cooperative collision warnings in VANETs

SECURITY AND COMMUNICATION NETWORKSSecurity Comm. Networks 2011; 4:1469–1482

Published online 8 February 2011 in Wiley Online Library (wileyonlinelibrary.com). DOI: 10.1002/sec.285

RESEARCH ARTICLE

Group-based hybrid authentication scheme forcooperative collision warnings in VANETsMarshall Riley, Kemal Akkaya* and Kenny Fong

Department of Computer Science, Southern Illinois University Carbondale, Carbondale, IL, 62901, U.S.A.

ABSTRACT

Cooperative collision warnings (CCWs) is one of the important applications of Vehicular Ad-Hoc Networks (VANETs)where secure and timely delivery of messages to the neighboring vehicles are needed. Secure communication is as importantas timely communication to take proper actions in order to avoid collisions and thus prevent fatal accidents. However, securityand delay are two competing metrics since security brings additional processing overhead, increasing the packet delays.While symmetric-key-based security techniques can be more efficient as opposed to public-key cryptography (PKC) interms of delay, they introduce significant key maintenance overheads with the increased number of vehicles in VANETs.To alleviate this overhead and take the advantage of faster processing, we exploit the natural group behavior in CCWapplications. We propose a delay efficient authentication scheme for VANETs which is based on group communication.Groups are created and maintained dynamically led by leader vehicles. Since the data communication within the groupswill be dominating the overall packet traffic, we utilize symmetric-key techniques within each group which is handled bythe group leader. Group creations on the other hand are less frequent events and thus are done by PKC. We analyzed thesecurity properties of our proposed scheme and tested it with real-world vehicle data. Simulations results confirmed theefficiency in terms of delay with respect to other existing techniques. Copyright © 2011 John Wiley & Sons, Ltd.

KEYWORDS

VANETs; authentication; privacy

*Correspondence

Kemal Akkaya, Department of Computer Science, Southern Illinois University Carbondale, Carbondale, IL 62901, U.S.A.E-mail: [email protected]

1. INTRODUCTION

Vehicular Ad-Hoc Networks (VANETs) have started toreceive increasing interest recently due to their potentialto be used in Intelligent Transportation Systems (ITS)in the upcoming years. In VANETs, vehicles equippedwith a wireless transmission device (i.e., IEEE 802.11p[1]) can send and receive messages with significantlyhigher speeds compared to traditional Mobile Ad-HocNetworks (MANETs) [2]. Vehicles exchange traffic infor-mation among themselves and Road Side Units (RSUs)which have access to a network infrastructure. Such com-munication allows drivers to adjust their routes to avoidcongestion, obtain road-condition warnings and be warnedin advance for potential traffic accidents as seen in Fig-ure 1. Typical applications of VANETs include life-criticalsafety applications, safety warnings, traffic optimization,electronic toll collection, Internet Access, platooning forroad efficiency, and road-side service finding [3,4].

Our particular interest in this paper is one of the specificclass of life-critical safety applications of VANETs which

is called cooperative collision warnings (CCWs). The ulti-mate goal in CCWs is to prevent the vehicular collisionsby realizing the concept of 360◦ driver situation aware-ness [5]. Vehicles broadcast short messages about theirlocation, velocity, and control settings via on-board sen-sors to warn the other drivers of an impending collision.For instance, a vehicle uses the messages it receives andknowledge of its own status to compute the likelihood of acollision with the vehicle directly in front of it [5]. Similarly,a vehicle uses control status information in the messages itreceives to determine if one or more leading vehicles arebraking.

In each of these cases, status messages must be trans-mitted quickly and securely. Quick transmission is requiredfor taking appropriate actions on time given that even a fewmilliseconds of delay may cause fatal accidents. Securityis important due to several reasons. For instance, all statusmessages sent by a vehicle must be verified by the recipientfor its authenticity and integrity in face of adversaries thatmay inject messages containing bogus information to thenetwork, yet the privacy of the driver sending those mes-

Copyright © 2011 John Wiley & Sons, Ltd. 1469

Group-based hybrid authentication M. Riley, K. Akkaya and K. Fong

Figure 1. Example of a VANET.

sages against unauthorized observers must be guaranteed.However, the anonymity service should be made condi-tional, meaning that it can be revoked for law enforcementpurposes whenever necessary.

Most of the prior works on VANET security makeexclusive use of public-key cryptography (PKC), requiringthat every message be digitally signed and attached withpublic-key certificates. This incurs significant overhead interms of delay and bandwidth in CCW applications. Whilesymmetric-key cryptography, which is much more efficientthan public-key techniques, can be used for CCW applica-tions, it is infeasible to have every two vehicles share a secretsession key due to the huge scale of VANETs. To addressthis problem, we propose a group-based approach giventhat in CCW applications vehicles form natural groupsto exchange status messages. Each group will be formedgeo-dynamically meaning that a group leader is electeddynamically, group membership is changed dynamically,and the group boundary also moves dynamically alongthe road with the vehicles in the group. To the best ofour knowledge, this is the first approach utilizing dynamicgrouping in VANETs which is different than the existinggroup interpretations in VANETs that are formed based onthe transportation authorities’ regions.

Nonetheless, the design of secure VANETs is furthercomplicated if groups are allowed to form. In particular,the overhead associated with the formation and manage-ment of geodynamic groups poses a significant challengein designing efficient security schemes (i.e., secure groupcommunication). Our authentication approach utilizes PKCfor creating geo-dynamic groups while provides securecommunication among the members of the groups viasymmetric-key cryptography. Therefore, we refer to it asgroup-based hybrid authentication protocol (GHAP), here-after. The authentication process in GHAP is much fasteras it employs symmetric-key cryptography within eachgroup. Group keys in GHAP are created and distributedby group leaders providing efficiency in key distribution

and maintenance. Groups are managed via a small set ofcontrol messages. The scheme not only guarantees privacyand authentication of the senders, but it also ensures non-repudiation. We implemented GHAP in ns-2. Simulationresults indicated that our protocol can achieve the desiredauthentication features with significantly less delay over-head compared to other existing authentication schemessuch as ECDSA [6] and VAST [7]. In addition, it maintainsa very low packet drop ratio compared to other works.

The rest of this paper is organized as follows. In the nextsection, we summarize the related work. Section 3 describesthe preliminaries including the threat model, security goalsand assumptions. GHAP is explained in details in Section4. Section 5 provides a detailed security analysis of GHAP.Section 6 is dedicated to experimental evaluation. Finally,Section 7 concludes the paper.

2. RELATED WORK

The authentication mechanisms for VANETs can bedivided into two groups. Authentication schemes utilizingasymmetric-key cryptography and symmetric-key cryptog-raphy will be discussed in this section. We also discusssecure group communication under a separate subsection.

2.1. Public-key authentication

The set of IEEE 1609 standards have been developed toenhance IEEE 802.11 standards for supporting wirelesscommunication both between vehicles (V2V) and betweenvehicles and the roadside infrastructure (V2I). In particu-lar IEEE 1609.2 dictates that confidentiality, authenticity,and integrity must be provided within VANETs. AlthoughIEEE 1609.2 identifies the usage of symmetric (secret-key),asymmetric (public-key), and hash functions as being ableto provide these requirements, as far as authentication is

1470 Security Comm. Networks 2011; 4:1469–1482 © 2011 John Wiley & Sons, Ltd.DOI: 10.1002/sec

M. Riley, K. Akkaya and K. Fong Group-based hybrid authentication

concerned, IEEE 1609.2 identifies the utilization of publickey infrastructure (PKI) for establishing authenticity. Assuch, for authentication purposes, IEEE 1609.2 is based onPKC standards, such as elliptic curve (EC) cryptography(ECC), as well as public standards for other PKI adminis-tration functions thereof, such as certificate revocation. Toensure user privacy, each vehicle is preloaded with a largeset of short-lived pseudonym certificates used for messagesigning at the expense of storage.

Several other earlier works have also followed PKC toprovide authentication in VANETs [7--12]. Among these,Refs. [8--10] follow a group-based approach to utilize groupsignatures. A group signature scheme based on a grouppublic key and corresponding set of private keys allowsthe group manager to determine which private key signsa message. However, the groups defined here are differ-ent than ours. Typically, the groups are formed based onthe RSU or transportation authority which act as CertificateAuthority (CAs). We consider very small groups which canchange dynamically during their movement. The groups areformed in an ad-hoc manner and they are maintained by thevehicles. We do not depend on any central authority to cre-ate groups. Finally, as opposed to these works which relysolely on PKC, we use much more efficient symmetric-keytechniques for data communication.

2.2. Symmetric-key authentication

While there has not been any specific authentication pro-tocol for time-critical CCW applications, recently a fewapproaches considered the use of symmetric-key crypto-graphic techniques for message authentication in generalVANET applications. For instance, the TESLA proto-col [13] uses symmetric-key techniques for broadcastauthentication and relies on time to create the asymmetricknowledge between the sender and the recipient. In TESLA,the sender precomputes a long hash chain of keys, whoseroot is given in a certificate signed by an authority. Eachkey is used for only a short period of time to generate theMAC of messages. When a key expires, it is revealed sothat recipients can verify that key using the root certificateand use it to authenticate previously received messages.However, Studer et al. [7] observed that TESLA is sub-ject to memory-based DoS attacks against the recipient inVANET settings due to the storage of previously receivedmessages. Therefore, they proposed TESLA++, a modifiedversion of TESLA, which requires the recipient to store aself-generated MAC of the message’s MAC received. Themessage itself as well as the key will not be revealed untilthe key expires. However, the property of “delayed key dis-closure” inherent in TESLA++ hampers the readiness ofmessage data and therefore limits its use in time-criticalapplications such as CCW. In contrast, GHAP results invery little message delay time as will be shown in Section6.

Using TESLA, TSVC is proposed in Ref. [14]. While thiswork also deals with a similar problem using groups, our

work differs from it in several ways. First of all, since Ref.[14] uses the idea from TESLA which has the key disclosuredelay, a packet delay of at least 100 ms is still expected. Inour work, since we do not use TESLA authentication, thedelays are much smaller than 100 ms (i.e., <10 ms). Sec-ond, their idea of grouping is also very different than ours.Each node creates a group with the nodes that are within itstransmission range. In a sense, this is similar to broadcastingand results in lots of groups. They do not take into accountany group key authentication, to reduce the overhead. Incontrast, our work uses groups to reduce the overhead ofkey management. A group key is used among the membersof a group. Third, in Ref. [14] a node in a group may notbe able to reach other group members directly except theleader. In addition, the group maintenance is not addressedexplicitly. Our work on the other hand addresses the com-munication problem among the group members via goingthrough the leader. We provide a detailed algorithm to formand maintain the groups. Finally, Ref. [14] does not addressany attack regarding the compromise of the OBUs.

Another approach utilizing symmetric-key approach isreported in Ref. [15]. This approach depends on RSUs inorder to generate symmetric keys. When an RSU is detecteda vehicle attempts to associate with it. The RSU assigns aunique shared symmetric secret key and a pseudo ID whichcan be released to other vehicles. To ensure anonymitythis pseudo ID is associated with k vehicles. Utilizing thesymmetric key and pseudo ID, the vehicle can generate asymmetric MAC code for any message that it sends to othervehicles (together with the RSU). Upon receiving a messagethe receiver must buffer the message until the RSU verifiesthe message’s MAC and notifies its authenticity through theperiodic broadcasts of an aggregate of the hashes of authen-ticated messages. This approach, however, heavily dependson the existence of RSUs which may not be possible at alltimes. While, another approach to solve this problem hasbeen proposed in the same work, the proposed approachdoes not guarantee self-verification of a signature for a vehi-cle when there are not any neighbors. Our approach on theother hand relies minimally on infrastructure support andutilizes groups-based approach for CCW applications. Nogroups were considered in Ref. [15].

Utilizing the group concept discussed in the previoussubsection [16], proposes the privacy preserving groupcommunication scheme for VANETs to satisfy forward andbackward secrecy, authentication, protection against col-lusion, and privacy. The authors consider all the vehiclesregistered with the same authority as the same group. Asa result, some initial keys, a common group key and otherfunctions are loaded to each vehicle. When the group keyneeds to be changed, a database server is assumed to beavailable and distribute the keys. None of these are assumedin our work. First, we do not consider fixed groups. Ourgroups are geo-dynamically formed as needed by CCWapplications. Second, no central key server is assumed.Only certificates are refreshed whenever an RSU is hit.Third, unfortunately the approach is not implemented andthus no delay performance was provided in Ref. [16]. Our

Security Comm. Networks 2011; 4:1469–1482 © 2011 John Wiley & Sons, Ltd. 1471DOI: 10.1002/sec


work on the other hand tests the delay performance of theauthentication via realistic simulations.

2.3. Secure group communication

As far as the secure group communication and multicast-ing is concerned, there exists a large number of works inother wired and wireless networks [17--21]. The works forMANETs mainly focus on key management issues as thereis no assumed infrastructure support in MANETs. In addi-tion, there are several other differences from MANETs:First, VANETs have real-time constraints which is notalways the case in MANETs; second, speeds of the nodesare higher in VANETs; and third, the security of on-boardunits (OBUs) is not an issue in MANETs. As a result, thesecurity requirements of MANETs are very different andthus the authentication mechanisms for MANETS cannotbe directly applied to VANETs.

Only a few papers address secure group communicationin the context of VANET applications. However, most ofthem focus on different purposes such as data aggregationand location privacy other than authentication [22--24]. Ourapproach is the first to adapt this idea to the problem ofauthentication for CCW applications in VANET.

3. PRELIMINARIES

3.1. Assumptions

We assume that the OBU of each vehicle is a tamper-proofdevice (TPD) [25] which securely stores all cryptographiccredentials and performs all cryptographic computations.While most of these TPDs are assumed to erase sensi-tive information they have when the devices are tamperedwith, we still consider the possibility of TPD compromiseand strive to minimize the consequences of such a case.Each vehicle has a unique identifier V, such as an electroniclicense plate that relates to other information about the vehi-cle and its registered owner. Furthermore, each vehicle hasa unique pseudonym PV whose mapping with the vehicleidentifier V is kept solely by the transportation authority.Both V and PV as well as the public-key certificate of lawenforcement are preloaded into the OBU by the transporta-tion authority at the time of vehicle registration.

Furthermore, the transportation authority is assumed tomaintain a huge pool of certificates, and each vehicle ispreloaded with a randomly selected subset of certificates(including both the public key and private key) drawn fromthis certificate pool at the time of vehicle registration. Thetransportation authority should regularly flush the pool withnew certificates, and any vehicle should download freshcertificates to replace expired ones whenever it is withinthe communication range of an RSU. In the description ofour protocol that follows, whenever a node’s certificate isreferenced, it is assumed that the node selects a random oneout of its certificate store.

3.2. Threat model and security goals

We identified the following attacks and corresponding secu-rity goals in group-based CCWs:

• Attack: An outside non-registered node (i.e., not reg-istered with transportation authority) tries to join agroup.Security goal 1: To prevent untrusted nodes from join-ing any group.

• Attack: A malicious node tries to inject bogus messagesinto the network or to intercept, modify and replayother messages without being detected.Security goal 2: To provide message authenticationand integrity to ensure that the messages are indeedcoming from the group members without corruption.

• Attack: An insider or outsider tries to find out the iden-tity of the sender of a safety-related message againstprivacy.Security goal 3: To provide privacy for the drivers.

• Attack: An insider node tries to send a valid messagewhich cannot be traced back to its identity by lawenforcement agency.Security goal 4: To provide non-repudiation so that lawenforcement agency can identify the sender of a validmessage.

• Attack: A malicious node which compromised an OBUand retrieved a group key, tries to join any group of itsown choosing at any time and sends bogus messages.Security goal 5: To minimize and localize the impactof compromised OBUs.

In addition to security-related goals, we also have twoother goals:

• Meet the VANET real-time constraints: Given thenature of CCW applications, it is always crucial to min-imize the packet delay as much as possible in order toprovide more time for the drivers to take action andprevent collisions [5].

• Minimize access to an Infrastructure when perform-ing the authentication: This is particularly importantin CCW applications since accessing an RSU for cer-tificate renewals and CRL checks may add additionaldelay. Moreover, RSUs may not be widely available tobe accessed on demand.

3.3. Entity key agreement

As the IEEE 1609.2 standard suggests the utilization of ECCto secure communications within a VANET, the proposedGHAP utilizes the elliptic curve Diffie-Hellman (ECDH)key agreement protocol in dealing with communicationbetween two nodes when a certificate is involved. Thisallows two entities, each of which has a public/private keypair, to securely establish a shared secret through a possiblyinsecure medium. Briefly, this process is as follows: Sup-pose there are two nodes U and V which have previouslyagreed on a set of EC domain parameters. Each node has an



EC public/private key pair, say (QU, dU ) for U and (QV , dV )for V where Q is the public key and d is the private key. Theprivate key d is a randomly selected integer over a specificinterval and Q = d × G, where G is a generator point. Ufinds a shared secret, K, by taking V’s public key and findingits scalar product with V’s private key as the scalar. Simi-larly, V computes the same secret using U’s public key andits own private key. Formally, the two results are equivalentas shown:

K = dU × QV = dU × (dV × G)

= dV × (dU × G) = dV × QU = K

Note that ECDH can be turned to an encryption schemeas done in our approach since the sender can compute theshared secret K given the receiver’s public key and useK as a symmetric key to encrypt a message. Similarly,the receiver can decrypt the message by first reconstruct-ing the same shared secret K given the sender’s publickey.

4. PROPOSED AUTHENTICATIONPROTOCOL: GHAP

4.1. GHAP overview

GHAP makes use of both PKC and symmetric-key cryp-tographic techniques to authenticate messages sent amongnodes of a CCW group. As mentioned earlier, there aretwo major motivations for such an authentication protocol.First, by the nature of CCW applications vehicles move ingroups where an action can affect all the group memberssimultaneously. Therefore, rather than dealing with pair-wise communication issues among the vehicles, it is moreefficient and faster to communicate in groups. Second, wefollow a symmetric-key-based protocol within each groupto reduce the delay associated with authentication. Groupcreation is performed via PKC. Besides message authen-tication, GHAP guarantees user privacy in face of passiveadversaries, yet provides non-repudiation for law enforce-ment purposes.

In GHAP, first the groups are created based on adistributed algorithm among the vehicles within a neigh-borhood. Each node is in one of the following three roles atany moment: Non-member, group leader, and group mem-ber. A non-member node is not associated with any group.A group leader is associated with a single group only,whereas a group member belongs to one or more groupsyet cannot be the leader of a group. The idea of GHAP isbased on identifying group leaders so that non-memberscan join one of the groups nearby. Specifically, the nodeswithin the transmission range of a group leader form agroup.

Any node that is not currently associated with any groupsconstructs a search message S which also includes its cer-tificate and periodically broadcasts it to all of its neighbors.

Table I. Notation for keys used.

Key Description

KG Symmetric group key created by the groupleader

KGU Shared secret between group leader and a nodeU generated by ECDH

certU Certificate for a node U’s public key QU

certLAW Certificate for Law Enforcement Agency’s publickey QLAW

KUL Symmetric key between a node U and LawEnforcement Agency

This message is used for contention with others to becomea leader. Once a node assumes the role of a group leader, itwill begin periodically broadcasting a GL message whichincludes the necessary information for others to join thegroup securely. Any vehicle receiving such a message isaware of the existence of a group leader, and can thereby jointhe group by decrypting that message as will be explainedshortly.

Once the groups are created, each node within a groupcan broadcast status (data) messages periodically via theleader using a symmetric group key. The leader also updatesthe group status periodically for the leaving/joining nodes.Next, we describe in detail the group construction andmaintenance algorithms along with the control messagesused.

4.2. Geo-dynamic group construction

In creating and maintaining the groups, we describe the roleof non-members, members, and group leaders under differ-ent subsections. In the descriptions, we use the notation inTable I for the keys.

The overall group construction and maintenance algo-rithm pseudo-code is depicted in Algorithm 1. We describegroup construction and maintenance under different sub-sections by referring to Algorithm 1. In each instance, wefurther divide the sections into the actions performed byboth group leaders and non-group leaders under each sce-nario.

4.2.1. Non-member nodes.

Any node U not associated with any group periodicallyconstructs and broadcasts a search message S consistingof a randomly generated number NU , a randomly chosensecret KUL encrypted with the preloaded public key QLAW

of the law enforcement agency using ECDH, and its ownpublic-key certificate certU .

S = 〈NU, {KUL}QLAW , certU〉This will be periodically broadcast as seen in line 7 of

Algorithm 1.When a receiving node, V, is a non-member and receives

an S message, a contention will be performed as seen in



line 3 of Algorithm 2. That is, the random number NU in Swill be extracted and compared versus V’s random numberNV . If V’s random number is greater than the sender’s, Vpromotes itself to group leader status, generates a group keyKG, and then unicasts the grouping information via a GLu

message, the contents of which are detailed shortly, to theother nodes as seen in lines 10--12 of Algorithm 2. ShouldV’s number be smaller, it will simply continue broadcastingS messages and doing contentions. The range of the numberis irrelevant so long as there exists a number which is higherthan another.

4.2.2. Group leaders.

When a node assumes group leader status, it begins peri-odically broadcasting GLb messages as shown in line 10of Algorithm 1 to update group status. GLb consists of atriple including the timestamp T, a possibly new group key,denoted as K′

G, and a metadata field m, encrypted with thecurrent group key KG.

G → ∗ : {T, K′G, m}KG

Since the GLb message’s primary function is to freshengroup information on nodes within the group, its encryptionwith the current group key KG works as all group membersalready have this key. The group key KG should be chosenrandomly by a node when it first becomes a group leader. Itshould also be continuously changed by itself in the view ofa single node as the node leaves and joins different VANETgroups, while a group leader can choose to periodicallyrenew the group key and distribute it to all group members.The metadata field m can be used to store any control datafor group management. The timestamp T is verified to checkfor message integrity.

Upon receipt of an S message a group leader G willextract the sender U’s certificate information and utilize thisto construct the ECDH shared secret KGU . G then createswhat is known as a GLu message (i.e., unicast version).Note that while GLb message is utilized for group informa-tion updates, GLu is utilized for allowing nodes to join thegroup. That is, G encrypts the group information with KGU ,appends its certificate certG, and then unicasts, as shown inline 12 of Algortihm 1, it to the node that sent the originalS message:

G → U : {T, KG, m}KGU, certG



Upon receipt of a GLu message, a non-group membernode will extract G’s certificate, and then use it to findthe shared secret KGU utilized to encrypt the group infor-mation. Once KGU is reconstructed using ECDH, it candecrypt the remainder of the GLu message and then extractthe group key KG and verify the timestamp. In GHAP,Each node keeps a group member list. Therefore, before thegroup information is added to V’s group member list, thetimestamp T in the group information is checked to ensurefreshness. Only if everything succeeds does join the group.

Upon becoming a group leader, a node, V, only dropsthis status when another group leader is encountered or thesystems become inactive (e.g., the vehicle is turned off).In the case of another group leader, say U, V will hear aGLb message from U. V will respond with an S message toinitiate the process of getting the group information fromU, as depicted in line 14 in Algorithm 1. U will send aGLu message to V. V extracts the control data encoded inthe metadata field m from U’s GLu message and performs acontention. Should V have a larger control value, then it willcontinue to function as a group leader. However, should thevalue be lower, than V will demote itself to a group memberof U’s group. As this process is taken, V does not have toissue any additional messages to retrieve the group key KG

from U. It can immediately join the group and begin datacommunication within the group.

4.2.3. Group members.

A node which currently has group member status, say V,will join another group when a GLb message, for a groupit is not currently a member of, is overheard. As depictedin line 23 of Algorithm 1, when this situation occurs, Vconstructs an S message as if it was a non-member andunicasts it to the group leader who sent the GLb message.As the group leader does not differentiate between actualnon-member nodes and member nodes when dealing withan S message, the processing is handled the same way. Valso handles the GLu message sent by that group leaderin reply to the S message in the same manner as if it hadnon-member status.

We would like to note that GHAP supports multiple groupmemberships. Every node maintains a group-info list L forstoring group membership information of its groups. When-ever a node joins a group, a list element will be constructedconsisting of the timestamp T, the group key KG, and thegroup leader’s address, all of which are initially extractedfrom the GLu message. The grouping information is theninserted to the top of L and as such, L is sorted by times-tamp freshness. Line 28 of Algorithm 1 shows that a nodeperiodically performs a check on the most recent groupinformation, which is at the top of the list L. Should thetimestamp T be past a threshold then the node revokes allremaining group memberships by emptying L. As such, thenode changes its status to be that of a non-member andbegins the process of broadcasting S messages again.

Upon receiving a GLu or GLb message from a groupleader, the list L is checked to see if the group informationcorresponding to that group leader can be found in L. Ifthe information is already present, the old information isremoved from L and the new information is inserted atthe top of L. The capacity of L is additionally kept smallto ensure any iterative search of L can be performed inconstant time.

4.3. Data communication andauthentication

Every node should regularly send updated safety data mes-sages to other nodes within the same group, for each grouprecorded in the group-info list L. The data D of a safetymessage M would typically contain such information asthe current speed, location and trajectory of the node. Anode V can send a safety message to a particular group asfollows:

1. Construct a law enforcement access field (LEAF)by concatenating V’s pseudonym PV with the groupkey KG obtained from L, padding the result withtimestamp T split into two portions T1 and T2, andencrypting it with the law enforcement key KUL:

LEAF = {T1||PV ||KG||T2}KUL

2. Construct the safety message M, consisting of thedata D, the LEAF, and the timestamp T:

M = 〈D, LEAF, T 〉

3. Compute the HMAC [26] of the message M usingthe group key KG, and send the message-MAC pairvia unicast to the group leader, G (unless V is thegroup leader itself). For this unicast, V should usea fake source address (i.e., at the link layer) gen-erated randomly using a pseudo-random numbergenerator:

V → G : M, HMACKG(M)

4. G would broadcast that message-MAC pair receivedfrom V to the entire group. Note that the groupleader’s message can reach to every node within thegroup:

G → ∗ : M, HMACKG(M)

Any node within the same group receiving such amessage-MAC pair would authenticate the data D byverifying both the timestamp T and the MAC (recom-puting it using the group key KG). The LEAF would bediscarded.



5. PROTOCOL SECURITY ANALYSIS

In this section, we discuss how GHAP addresses the securitygoals listed in Section 3.

5.1. Security goal 1 -- group creation

The use of public-key certificates in the group cre-ation/joining process of GHAP prevents a malicious nodefrom forming or joining any valid group. A malicious nodeis assumed to have its identity checked by the certificateauthority and so should never be issued any valid certificatesof public/private key pairs. Therefore, a malicious node thatattempts to join a group would fail because it does not havea certified private key to decrypt a GLu message. A mali-cious node that attempts to form a group for others to joinwould also fail because it does not have a certified privatekey to construct a valid ECDH shared secret to encrypt thetimestamp properly. Of course, in order for this to work anynode receiving an S message or a GLU message must firstverify the certificate authority’s signature on the certificatereceived.

5.2. Security goal 2 -- messageauthentication

Provided that a secure underlying hash function is used andthe key length is sufficiently long, the HMAC algorithm ofGHAP provides message authentication and integrity, andis provably secure against forgery attacks. The length of KG

should be at least 80 bits in today’s standard.In addition, GHAP prevents replay attacks by the inclu-

sion of timestamps in GLu, GLb, data safety messages andthe LEAF. Since a data message goes through a group leaderbefore being forwarded to the recipients, the timestamp of adata message should sustain a slightly longer lifetime thanthat of any GLu message. If a higher level of security isdesired such that a dedicated adversary is prevented frominstantly replaying a captured GLu message within the nar-row timeframe before its timestamp expires, every GLu

message received and verified can be checked against eachentry of the group-info list L. Any such GLu message that isfound as a replay (whose timestamp and group key exactlymatch one of the entries in L) is rejected and L will notbe updated. The probability that two distinct group leaderssend a GLu message with identical group keys and identicaltimestamps should be negligible. For this check to execute atconstant time, a cap should be put for the maximum numberof group memberships allowed for a vehicle.

We would like to note that adversaries can obviouslyinject falsified and malicious data by other means, for exam-ple, by cheating the vehicle sensors. This threat can bemitigated through the use of data crosschecking and scoringtechniques [27], and is out of scope of this paper. However,our approach can be complemented with such an approach.Specifically, the vehicle can check the validity of the data

by comparing it with the data coming from other nearbyvehicles. If an inconsistency is seen, then the message canbe sent to Law Enforcement via one of the RSUs. The lawenforcement can then extract the LEAF and find the identityof the vehicle sending malicious messages.

5.3. Security goal 3 -- privacy

GHAP preserves privacy, as no vehicle identifiers areincluded in any GHAP messages. First, since the encryptedKUL in an S message is decryptable by law enforcementonly, no eavesdroppers are able to construct KUL and useit to decrypt the LEAF to obtain the vehicle pseudonym,which could be used as an alternative label for identifyinga particular vehicle. In addition, KUL is generated before anode joins a group and is different for each node joins. Thisfurther decreases the chance of cryptanalysis on LEAF.

Obviously, if the LEAF were a function of solely thevehicle pseudonym PV and the group key KG, both ofwhich typically remain unchanged for a certain period oftime, then the same vehicle would generate multiple identi-cal LEAFs, which again could serve as an alternative labelfor that vehicle. To eliminate this problem, timestamp pads(i.e., T1 and T2) are appended to PV and KG before encryp-tion in the LEAF construction process. In other words, theLEAF encryption function is practically made probabilis-tic, resulting in different LEAF values given the same PV

and KG. Finally, the degree of message anonymity is furtherincreased with use of fake source addresses when sendingsafety messages to the group leader.

Finally, updating of the certificates at the nodes periodi-cally will aid with anonymity by decreasing the odds of anode being tracked based on where the associated certificateis seen. Additionally, as the public/private key informationis only utilized during group creation, no information needbe retained when flushing used certificates.

5.4. Security goal 4 -- non-repudiation

GHAP provides a mechanism that allows law enforce-ment to track the sender of a safety message. To uncoverthe identity of the vehicle sending a message-MAC pairthat was previously captured, the law enforcement agencycan decrypt the LEAF within that message using the lawenforcement key KUL. Since each node generates a dif-ferent KUL for each group joined, the law enforcementagency must be made aware of these keys. One way todo this would be for the group leader to save S messageswhen nodes attempt to join the group and then send themto an RSU whenever possible (however, the group leadershould discard an S message after certain time to avoid anymemory-based DoS attack). The RSU can then relay thisinformation to the law enforcement agency which can useits private key to retrieve KUL.

Once the LEAF is decrypted, the vehicle pseudonym PV

and the group key KG can be retrieved. Next, the agency



would use KG to verify the MAC to ensure the authentic-ity and integrity of the message, and then request a courtorder that would require the transportation authority to dis-close the vehicle identifier V corresponding to PV (as wellas other vehicle information and/or the registered ownerdeemed necessary by the judge). Notice that the vehicleregistration database (including the mapping from PV to V)is maintained only by the transportation authority, not thelaw enforcement agency. On the other hand, the transporta-tion authority does not possess KUL and so does not havethe ability to decrypt the LEAF. Such a design prevents asingle governmental agency from having too much power.This is similar to the concept of key escrow [28], and is anapplication of the security principle of separation of duties.

The use of T in a LEAF is due to the possibility that thevehicle OBU could be compromised and the group key KG

is exposed to a malicious node. In such a case, the maliciousnode can sniff a LEAF of some other node and construct itsown data D′, new timestamp T ′, then construct a new mes-sage M ′ = 〈D′||LEAF||T ′〉 and compute the HMAC of M ′

using KG. However, the LEAF sniffed contains a timestampwhich is much older than T ′. Therefore, if the law enforce-ment agency decrypts the LEAF from M ′ and finds that theold time within is not equal to T ′, it will know that LEAFwas stolen from somebody else, not really constructed bythe malicious node. Use of T in this case, provides authen-tication in the eye of the law enforcement agency and thusprevents us using a signature for the M as opposed to usingHMAC algorithm.

To demonstrate the theoretical strength of the LEAFagainst forgery attacks, consider a dishonest law enforce-ment officer who does not have the resources foreavesdropping but has access to KUL. In this case non-repudiation is still provided by GLAP without the useof PKC because the probability that the officer can suc-cessfully construct a LEAF with a valid pseudonym isnegligible. For example, since the number of possiblelicense plate numbers in the U.S. is <242 but each vehiclepseudonym is 112-bit long, the probability that the officercan successfully guess a valid pseudonym is <242/2112 =2−70. Of course, such an idealized adversarial model shouldnot occur in reality, because the law enforcement agencyshould securely store KUL in a tailor-made tamper-proofcryptoprocessor that only performs LEAF decryptions, notLEAF encryptions.

5.5. Security goal 5 -- forward secrecy

In the worst case that the OBU of a registered node is com-promised so that a malicious node has access to an activegroup key KG, then the most it can do is to join the particulargroup corresponding to KG and transmit bogus messageswithin the limits of that group. In order words, the impactof the malicious node is localized to a single group only.It cannot use KG to join another group at any time nowor in the future. The localized impact of the malicious nodewill eventually diminish due to the dynamic nature of group

Table II. Crypto++ library speed benchmarks [31].

Algorithm Speed

AES/ECB 109 MiB/sECDSA generation/verification 2.88 ms/8.53 msECDH key agreement 2.82 msRSA encryption/decryption 0.16 ms/6.08 msHMAC/SHA-1 147 MiB/s

memberships as other neighboring nodes of the maliciousnode join other groups.

However, we would like to note that if the whole OBU iscaptured and the vehicle is controlled by the attacker, thenthe vehicle can start insider attacks (i.e., send bogus infor-mation) without being detected. To handle those cases, Trusttechniques and Misbehavior Detection Schemes should beused [29,30]. Another solution to prevent these types ofinsider attacks would be to make the pseudonym carriedby the driver. That is, a driver will always carry a tokenwhich stores the pseudonym and the token will be insertedto the OBU in order for the car to operate. LEAF is basi-cally the pseudonym encrypted with the law enforcementsession key. In this case, the attacker still needs to inserthis/her pseudonym token to a compromised OBU to gen-erate a fake LEAF. However, since he/she uses his ownpseudonym, the generated LEAF will be different than theoriginal LEAF and thus the attacker will be caught and heldaccountable.

5.6. Other non-security goals

5.6.1. Efficiency.

In GHAP, ECDH is only utilized once per node duringthe group joining process; that is, once during the creationof an S message and once during the creation of GLu. Anode could save time by precomputing the shared secretutilized in the encryption of KUL for the S messages due tothe preloaded certificate of the law enforcement agency.We would like to note that the utilization of ECDH forperforming encryption rather than RSA is due to strongersecurity with smaller key sizes, yet providing comparabledelay performance. For instance, the delay incurred (i.e.,message processing, encryption, and decryption) when uti-lizing RSA with a 2048-bit key is 6.24 ms as seen in TableII [31]. On the contrary, with a ECDH 256-bit key, which isbasically equivalent to a 128-bit symmetric key or a 3072-bit RSA key in terms of security strength, it takes a totaltime of 2.82 × 2.82 = 5.64 ms to establish a key agreement.Adding the delay of advanced encryption standard (AES)shared secret encryption/decryption time which is 1 µs willnot make any difference at all.

In GHAP, symmetric-key techniques are utilized for GLb

and LEAF. Assuming that AES is used for encryption whichhas a block size of 128 bits, both a GLb message and theLEAF can typically fit within two AES blocks, i.e., 256 bits.In the case of constructing the LEAF, after allocating 64 bitsfor the timestamp pads T1 and T2 and 80 bits for the group



key KG, there are still 112 bits remaining for the vehiclepseudonym PV , and that is more than enough to representthe pseudonyms of all possible license plate numbers in anyjurisdiction (e.g., the number of possible license plates inthe U.S. is not more than 242). Since only two AES blocksare involved in any single encryption, the encryption can beperformed simply in the electronic codebook (ECB) modeof operation [32] without losing any security strength com-pared with other block cipher modes. A single two-blockAES/ECB encryption would cost <1 µs.

Since PKC is slower than symmetric-key cryptographyby orders of magnitude, GHAP’s use of symmetric-keycryptography for safety messages is guaranteed to be muchmore efficient than the IEEE 1609.2 standard, which pro-poses the use of ECDSA to digitally sign every safetymessage [33]. As an example, assuming that a GHAP safetymessage is 512-bit long (192 bits for the data D, 256 bitsfor the LEAF, and 64 bits for the timestamp T), it wouldcost only 0.5 µs to compute the HMAC of a safety mes-sage according to the speed benchmark from Table II,which is at least 5000 times faster than ECDSA signaturegeneration and 10 000 times faster than signature verifica-tion. Although this performance analysis does not take intoaccount the computational overhead of group management,such an overhead is unable to subdue the huge difference inperformance between ECDSA and HMAC.

5.6.2. Infrastructure dependence.

Since the group key is generated by the group leader, thereis no need for RSU access in the context of group key main-tenance. Nevertheless, the certificate store of each registerednode should be flushed periodically to replace expired cer-tificates with fresh ones from the certificate pool of thetransportation authority. However, this is not urgent andcan be done whenever an RSU is available to be accessed.Similarly, to check the certificates against revocation, theup-to-date CRLs can be downloaded whenever an RSU ishit. Thus, our scheme significantly minimizes dependencyto RSUs.

6. EXPERIMENTAL EVALUATION

We implemented our protocol in a simulation environmentto assess its performance under a variety of conditions.

6.1. Simulation setup

The simulations were evaluated on a single core of aneight core Intel Xeon E5450 3.00Ghz processor with 32GBof RAM. In evaluating GHAP, we have utilized the ns-2simulator [34] for simulating a VANET environment. Thetopography was generated utilizing the mobility model-ing software from Ref. [35]. It was a 2.4 km2 area whichresembled an urban environment. The vehicles would move,roughly, anywhere from 55 to 65 mph depending on the road

they were traveling on. The vehicles would also periodicallymake stops, simulating the need for stopping at appropri-ate traffic control devices. The results reported are averagedover 30 different runs.

For tests where node count varies the transmission rangewas set 200 m while for test where transmission range var-ied the node count was set to 130 nodes. We used 11 mpbsradio which is consistent with upcoming IEEE 802.11p [1]standard for VANETs. The data packet size was 512 bits.S messages were broadcast every 900 ms, both GLu andGLb messages were broadcast approximately every 1/3 ofa second, and safety data was broadcast every 100 ms. Thethreshold for checking the validity of GLu and GLb mes-sage timestamps was set to 100 ms. The other threshold forgroup information freshness (i.e., scanning the list L) waspicked as 700 ms. In our experiments, we allowed the mem-ber nodes to join up to two different groups which helpedto ensure inter-group connectivity.

6.2. Performance metrics and baselines

We have considered average end-to-end packet delay anddrop ratio for assessing the performance of GHAP as thesetwo metrics are very crucial for CCW applications for pre-venting collisions.

1. End-to-end delay includes the time it takes to formour message structure, encrypt and decrypt the mes-sage, parse the message structure, and the time ittakes for a packet to reach the destination after it hasleft the source node. Control packets are not includedin calculations for end-to-end delay.

2. Drop ratio is calculated as the total number ofdropped packets over the total number of packetssent. We also assumed a fixed 10% packet drop ratedue to wireless environment as in Ref. [7]. The onlydrop type not taken into account for the counting isrouting level packet drops as all communication inour protocol is single hop transmissions.

3. Throughput is calculated via counting the total num-ber of non-control packets which make it to their finaldestination for processing. The result is than dividedby the total length of the simulation run to give us ameasured value in packets per second.

6.3. Baselines for comparison

To establish a baseline for our own cryptographic solu-tions, we have implemented a version of GHAP without anyencryption or authentication. We denote this implementa-tion as insecure GHAP (IGHAP). This baseline allows usto judge the overall impact of our encryption and authenti-cation scheme on delay and drop ratio.

We have also implemented a relatively simplistic andbase version of an ECDSA scheme, which mimics IEEE1609.2, for comparison. In this scheme a node, say V, con-



structs a message consisting of the information to be sent,V’s signature of this information, and V’s ECDSA public-key. The node then broadcasts the message to surroundingnodes, who verify the signature based on the received key.These messages were sent approximately every 1/3 of a sec-ond. No grouping is performed in the ECDSA implementedscheme. In addition to ECDSA, we have also run experi-ments with VAST [7], which was also implemented in ns-2.In the implementation, the actual cryptographic operationswere simulated by adding in approximate benchmark delaytimes on both the sender and receiver. The packet’s size wasgenerated to simulate a packet containing a signature and/orMAC. As described in Ref. [7], packets are broadcast every100 ms.

6.4. Simulation results

6.4.1. End-to-end delay.

Figure 2 shows the average end-to-end delay of a typ-ical safety message within our simulation, in seconds,given various node densities. The transmission range ofthe radio device on the vehicle is fixed at 200 m in theseexperiments.

We see from Figure 2a that VAST suffers the highest aver-age packet delay. This is due primarily because, for messageMi, a node must wait for the next heartbeat message Mi+1,which is broadcast approximately every 100 ms, before thenode can verify Mi. From Figure 2a we can see that in

20 40 60 80 100 120 140 160 180 2000

0.02

0.04

0.06

0.08

0.1

0.12

# of Vehicles

Aver

age

Delay

Per

Pac

ket (

sec)

ECDSAIGHAPGHAPVAST

50 100 150 200 250 3000

0.02

0.04

0.06

0.08

0.1

0.12

Transmission Range (m)

Aver

age

Delay

Per

Pac

ket (

sec)

ECDSAIGHAPGHAPVAST

(a)

(b)

Figure 2. Average delay when varying vehicle count (a) and trans-mission range (b).

Table III. Number of groups.

Approach Configuration # of groups

GHAP 210 Nodes 27.6IGHAP 210 Nodes 28.8GHAP 300 m Range 24.5IGHAP 300 m Range 25.9

all tested scenarios, GHAP has less average delay than thegeneric implementation of an ECDSA scheme. ECDSA hasa relatively constant delay since all packets are broadcastand contention among vehicles increases only slightly asthe number of vehicles increase. In all cases GHAP is per-forming better than ECDSA and VAST which is expectedgiven that we utilize symmetric-key cryptography withineach group. We find the primary source of delay in GHAPand IGHAP is due to a bottleneck which is created from alldata being forced to flow through the group leader. This canbe seen in the relatively linear delay increase as the num-ber of nodes increases. As the number of nodes per groupincreases more messages passing through the group leaderis incurred.

Figure 2a has also revealed an interesting result in thesense that the IGHAP’s delay is even worse than the GHAP.This seemed contradictory with the fact that there is nooverhead of security in IGHAP and thus one would expecta lower packet delay. As a result of this result, we havedecided to investigate the number of groups created in bothschemes. In particular, we have looked at the number ofgroups created during the entire simulation. As seen in TableIII, the number of groups created in IGHAP is a little higherthan that of GHAP. This can be attributed to the fact thatin GHAP a shared secret should be created to join a groupwhich introduces a delay overhead for the nodes to join agroup. In the long run, this causes nodes to join less groups.This further tells us the number of nodes in a group will alsobe decreasing in GHAP. As a result, the groups leaders willneed to serve more number of vehicles in IGHAP comparedto GHAP. Since, the broadcast messages are first unicastto group leaders in GHAP and IGHAP, an IGHAP leaderwill need to wait more before the packets are broadcast toall group members. Thus, this brings a little more end-to-end delay for IGHAP packets in average as testified by theFigure 2a. Such processing overhead increases more withthe increased number of vehicles in such a way that IGHAPperforms even worse than ECDSA after 170 nodes. Giventhat the transmission range was 200 m in this experiment,the results suggest that smaller transmission ranges be usedfor better delay performance.

We have repeated this experiment with varying transmis-sion range and similar results to Figure 2a was obtained asseen in Figure 2b. VAST again has the highest average delaydue to the aforementioned need to wait for an additionalheartbeat message. From Figure 2b we see that the smallerranges would provide even less delay in GHAP due to mini-mizing the size of groups. In this experiment, the number ofnodes was 130 and thus the performance of IGHAP still out-



20 40 60 80 100 120 140 160 180 2000

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2x 104

# of Vehicles

Thro

ughp

ut (p

acke

t/sec

)

ECDSAIGHAPGHAPVAST

50 100 150 200 250 3000

0.5

1

1.5

2

2.5x 104

# of Vehicles

Thro

ughp

ut (p

acke

t/sec

)

ECDSAIGHAPGHAPVAST

(a)

(b)

Figure 3. Throughput under varying number of vehicles (a) andtransmission range (b).

performs ECDSA, indicating that with higher transmissionranges, the group sizes should be adjusted not to bottleneckthe group leader.

6.4.2. Packet throughput.

In addition to delay, we have also investigated thethroughput performance of each scheme as seen inFigure 3a and b. As expected the throughput increases for allschemes with the increased number of vehicles and trans-mission range. VAST and ECDSA broadcast messages andthus their throughput are higher than GHAP and IGHAPwhich send data to group members only. ECDSA’s trans-mission rate was lower than VAST and thus this resulted inmore throughput for VAST even though it has the issue ofkey delay disclosure. Since IGHAP serves more groups andgroup members, the throughput is slightly higher than thatof GHAP under varying number of vehicles and transmis-sion range.

6.4.3. Packet drop ratio.

We have assessed the drop ratio of packets within the sim-ulation given the various node densities and transmissionranges.

We see from Figure 4a and b that all algorithms droppedrelatively few packets, that is <10%. Majority of thesepacket drops are due to the wireless environment. This isin fact verified with almost constant drop ratios for all ofthe approaches. In other words, increased contention via

20 40 60 80 100 120 140 160 180 2000

2

4

6

8

10

12

# of Vehicles

Pack

et D

rop

Ratio

(%)

ECDSAIGHAPGHAPVAST

50 100 150 200 250 3000

2

4

6

8

10

12

Transmission Range (m)

Pack

et D

rop

Ratio

(%)

ECDSAIGHAPGHAPVAST

(a)

(b)

Figure 4. Packet drop percentages under varying number ofvehicles (a) and transmission range (b).

increased number of vehicles or transmission range doesnot cause major packet collisions. As consistent with thethroughput results, GHAP has the lowest drop ratio since ithas the less traffic compared to others. VAST and ECDSAhave no groups and each node broadcasts every packet cre-ating more room for collisions.

The results have indicated the reliability of GHAP evenunder increasing number of vehicles and transmissionrange. Therefore, even if a packet is dropped due to wirelessmedium, the retransmissions of such packets have not putany delay burden on GHAP at it was still able to keep thepacket delay below 10 msec as shown in Figure 2.

7. CONCLUSION

In this paper, we have proposed a delay efficient authenti-cation protocol, GHAP, for CCW applications of VANETsby exploiting the group-based behavior in such applica-tions. Our scheme maintains the privacy of an individualwhile allowing for non-repudiation of a message by lawenforcement if so needed. The performance of GHAP hasbeen tested under ns-2 using real-life traffic data. Simulationresults have shown that GHAP proves to be a fast and effi-cient protocol with all message delays being <10 ms withinour simulation environment and minimal packet drops dueto collision. Compared to ECDSA and VAST, GHAP cansignificantly reduce the end-to-end delay for packets whileproviding the desired authentication with privacy and non-repudiation.



In the future, we intend to add a trust component to GHAPto also handle data cheating attacks on vehicle sensors aswell as detecting insider malicious nodes due to capturingof OBUs.

REFERENCES

1. IEEE 802.11p standard for vanets. grouper.ieee.org/groups/802/11/Reports/tgp update.htm, 2009.

2. Toh CK. Ad Hoc Mobile Wireless Networks: Protocolsand Systems. Prentice Hall Publishers: Upper SaddleRiver, NJ, USA, 2002.

3. Qian Y, Moayeri N. Design of secure and application-oriented vanets. In VTC Spring, 2008, pp. 2794--2799.

4. Reumerman H-J, Roggero M, Ruffini M. Theapplication-based clustering concept and requirementsfor intervehicle networks. IEEE Communications Mag-

azine 2005; 43(4): 108--113.5. ElBatt T, Goel SK, Holland G, Krishnan H, Parikh

J. Cooperative collision warning using dedicatedshort range wireless communications. In VANET’06: Proceedings of the 3rd International Workshopon VANETs. ACM: New York, NY, U.S.A., 2006;pp. 1--9.

6. Raya M, Hubaux J-P. The security of vehicular ad hocnetworks. In Proceedings of SASN’05, 2005.

7. Studer A, Bai F, Bellur B, Perrig A. Flexible, extensible,and efficient vanet authentication. Journal of Communi-

cations and Networks (JCN), (Special Issue on SecureWireless Networks) 2009; 11(6): 574--588.

8. Bellovin SM, Gennaro R, Keromytis AD, Yung M. Ppaa:Peer-to-peer anonymous authentication. In Applied

Cryptography and Network Security, 6th International

Conference, ACNS 2008, New York, NY, U.S.A., June

2008. Proceedings, Ser. Lecture Notes in Computer Sci-ence, Vol. 5037, 2008.

9. Calandriello G, Papadimitratos P, Lloy A, Hubaux J-P. Effcient and robust pseudonymous authentication invanets. In Proceedings of VANET’07, 2007.

10. Lin X, Sun X, Ho P-H, Shen X. Gsis: a secure and privacypreserving protocol for vehicular communications. IEEE

Transaction on Vehicular Technology 2007; 56(6): 3442--3456.

11. Fischer L, Aijaz A, Eckert C, Vogt D. Secure revocableanonymous authenticated inter-vehicle communication(sraac). In Proceedings of Workshop on Embedded Secu-

rity in Cars (ESCAR), 2006.12. Kamat P, Baliga A, Trappe W. An identity-based secu-

rity framework for vanets. In VANET ’06: Proceedingsof the 3rd International Workshop on Vehicular Ad HocNetworks. ACM: New York, NY, U.S.A., 2006; 94--95.

13. Perrig A, Canneti R, Song D, Tygar JD. The TESLAbroadcast authentication protocol. RSA Cryptobytes

2002; 5(2): 2--13.14. Lin X, Sun X, Wang X, Zhang C, Ho P-H, Shen X.

Tsvc: timed efficient and secure vehicular communica-tions with privacy preserving. Wireless Communications,

IEEE Transactions 2008; 7(12): 4987--4998.15. Zhang C, Lin X, Lu R, Ho P-H, Shen X. An efficient

message authentication scheme for vehicular communi-cations. in IEEE Transactions on Vehicular Technology

2008; 57(6): 3357--3368.16. Wasef A, Shen X. PPGCV: privacy preserving group

communications protocol for vehicular ad hoc net-works. In Proceedings of IEEE ICC’08, 2008; 1458--1463.

17. Zou X, Ramamurthy B, Magliveras SS. Secure GroupCommunications Over Data Networks. Springer-VerlagTELOS: Santa Clara, CA, U.S.A., 2004.

18. Wang N-C, Fang S-Z, Huang Y-F. Hierarchy-based keymanagement for secure group communications in mobilead hoc networks. In IWCMC ’07: Proceedings of the2007 International Conference on Wireless Communi-cations and Mobile Computing. ACM: New York, NY,U.S.A., 2007; 571--576.

19. Basagni S, Herrin K, Bruschi D, Rosti E. Secure peb-blenets. In MobiHoc ’01: Proceedings of the 2nd ACMInternational Symposium on Mobile Ad Hoc Network-ing & Computing. ACM: New York, NY, U.S.A., 2001;156--163.

20. Wong CK, Gouda M, Lam S. Secure group communica-tions using key graphs. In Proceedings of SIGCOMM’98,1998.

21. Kaya T, Lin G, Noubir G, Yilmaz A. Secure multicastgroups on ad hoc networks. In Proceedings of SASN’03,2003.

22. Raya M, Hubaux J-P. Securing vehicular ad hoc net-works. Journal of Computer Security (Special Issue on

Security of Ad Hoc and Sensor Networks), 2007; 15(1):39--68.

23. Raya M, Aziz A, Hubaux J-P. Efficient secure aggrega-tion in vanets. In Proceedings of VANET’06, 2006.

24. Sampigethaya K, Huang L, Li M, Poovendran R, Mat-suura K, Sezaki K. Caravan: providing location privacyfor vanet. In Proceedings of ESCAR’05, 2005.

25. Kargl F, Papadimitratos P, Buttyan L, Muter M, SchochE, Wiedersheim B, Thong T-V, Calandriello G, HeldA, Kung A, Hubaux J-P. Secure vehicular commu-nication systems: implementation, performance, andresearch challenges. IEEE Communications Magazine

2008; 46(11): 110--118.26. Golle P, Greene D, Staddon J. Detecting and correcting

malicious data in vanets. In Proceedings of VANET’04,2004.



27. Krawczyk H, Bellare M, Canetti R. Hmac: keyed-hashing for message authentication. In RFC 2104,February, 1997.

28. Denning DE, Branstad DK. A taxonomy for key escrowencryption systems. Communications of the ACM 1996;39(3): 34--40.

29. Hong X, Huang D, Gerla M, Cao Z. Sat: situation-awaretrust architecture for vehicular networks. In MobiArch’08: Proceedings of the 3rd International Workshop onMobility in the Evolving Internet Architecture. ACM:New York, NY, U.S.A., 2008; 31--36.

30. Ghosh M, Varghese A, Gupta A, Kherani AA,Muthaiah SN. Detecting misbehaviors in vanet withintegrated root-cause analysis. Ad Hoc Networks 2010;

8(7): 778--790. www.sciencedirect.com/science/article/B7576-4YK7J4W-1/2/9da4b4bbdbf4bb799ee35ff75e23c317 =0pt.

31. Speed comparison of popular crypto algorithms.www.cryptopp.com/benchmarks.html, 2009.

32. Menezes A, van Oorschot P, Vanstone S. Handbook ofApplied Cryptography. CRC Press: Boca Raton, FL,USA, 1996.

33. IEEE 1609.2 -- standard for wireless access in vehicularenvironments (wave) -- security services for applicationsand management messages. In IEEE Standards, 2006.

34. The network simulator -- ns-2. www.isi.edu/nsnam/ns.35. Monarch Project. www.cs.rice.edu/amsaha/Research/

MobilityModel.


Group-based hybrid authentication scheme for cooperative collision warnings in VANETs

Documents

Transcript of Group-based hybrid authentication scheme for cooperative collision warnings in VANETs