Flooding-Resilient Broadcast Authentication for VANETs

(1)

Flooding-Resilient Broadcast Authentication for VANETs

^∗

Hsu-Chun Hsiao, Ahren Studer, Chen Chen, Adrian Perrig

CyLab/Carnegie Mellon University

{hsuchunh, astuder, chenche1, adrian}@ece.cmu.edu

Fan Bai, Bhargav Bellur, Aravind Iyer

General Motors Research

{fan.bai, bhargav.bellur, aravind.iyer}@gm.com

ABSTRACT

Digital signatures are one of the fundamental security primitives in Vehicular Ad-Hoc Networks (VANETs) because they provide authenticity and non-repudiation in broadcast communication. How- ever, the current broadcast authentication standard in VANETs is vulnerable to signature flooding: excessive signature verification requests that exhaust the computational resources of victims. In this paper, we propose two efficient broadcast authentication schemes, Fast Authentication (FastAuth) and Selective Authentication (Sel- Auth), as two countermeasures to signature flooding. FastAuth secures periodic single-hop beacon messages. By exploiting the sender’s ability to predict its own future beacons, FastAuth enables 50 times faster verification than previous mechanisms using the Elliptic Curve Digital Signature Algorithm. SelAuth secures multi-hop applications in which a bogus signature may spread out quickly and impact a significant number of vehicles. SelAuth provides fast isolation of malicious senders, even under a dynamic topology, while consuming only 15%–30% of the computational resources compared to other schemes. We provide both analytical and experimental evaluations based on real traffic traces and NS-2 simulations. With the near-term deployment plans of VANET on all vehicles, our approaches can make VANETs practical.

Categories and Subject Descriptors

C.2.0 [General]: Security and protection; C.2.1 [Network Archi- tecture and Design]: Wireless communication

∗This research was supported in part by CyLab at Carnegie Mellon under grants DAAD19-02-1-0389 and W911NF-09-1-0273, and MURI W 911 NF 0710287 from the Army Research Office, grants CNS-1040801 and CNS-1050224 from the National Science Foun- dation, and by support from General Motors through the GM-CMU Collaborative Research Laboratory. The views and conclusions contained here are those of the authors and should not be inter- preted as necessarily representing the official policies or endorse- ments, either express or implied, of ARO, CMU, GM, NSF, or the U.S. Government or any of its agencies.

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.

MobiCom’11, September 19–23, 2011, Las Vegas, Nevada, USA.

General Terms

Algorithms, Design, Security

Keywords

Broadcast authentication, flooding resilience, signatures, VANETs

1. INTRODUCTION

Vehicular Ad-Hoc Networks (VANETs) enable inter-vehicle communication to improve road safety and driving experience. For example, in the Cooperative Collision Warning (CCW) application, vehicles exchange their location and speed to avoid accidents through periodic beacon messages. For efficiency, the Congested Road Notification (CRN) application enables vehicles in a traffic jam to alert approaching vehicles of the congestion [2]. VANET applications rely on vehicles’ On-Board Units (OBUs) to broadcast outgoing messages and validate incoming messages. An OBU should be able to verify a message before the vehicle needs to act upon it (i.e., before the message’s deadline).

One of the biggest concerns for VANET deployment is security. An attacker can not only cause financial loss but also threaten drivers’ lives. The recent successes in attacking vehicular systems [8, 20, 35] have demonstrated the need to design vehicular networks with security in mind. An indispensable security prim- itive in securing vehicular networks is broadcast authentication, because it ensures that vehicles only accept messages from legitimate senders and the messages are unaltered during transmission.

In addition to authentication, non-repudiation is required to prevent vehicles from denying the creation of sent messages and to enable the report of malicious participants to the legal authorities. Non- repudiation is especially important for resolving insurance cases after accidents happened. Though the IEEE 1609.2 standard [15]

achieves both broadcast authentication and non-repudiation using the Elliptic Curve Digital Signature Algorithm (ECDSA), verifying every signature using ECDSA causes high computational overhead on the standard OBU hardware, which has limited resources due to manufacturers’ cost constraints. A typical OBU with a 400MHz processor requires 20 milliseconds to verify one ECDSA signature.

Consequently, VANET authentication is vulnerable to signature flooding, where a vehicle receiving many signed messages in a short time period is unable to verify all of the messages before their respective deadline given the vehicle’s constrained computational power. Despite the significant impact on availability, signature flooding can be triggered easily even without any malice.

For example, a vehicle having more than five vehicles within radio range would be overwhelmed by its neighbors’ beacon messages, sent 10 times per second as dictated by the current standard [15].

(2)

Such a flooding problem is exacerbated under the presence of attackers and/or multi-hop communication.

In this work, we observe that signature flooding can be miti- gated by broadcast authentication schemes whose overheads match the entropy of the broadcast messages. We study this approach in the context of VANETs and propose two flooding-resilient broadcast authentication schemes, FastAuth and SelAuth, for different VANET applications. Our schemes are based on digital signatures thus providing non-repudiation. To the best of our knowledge, prior work on lightweight broadcast authentication either lacks the non-repudiation property or fails to operate efficiently in dynamic VANET environments. We briefly summarize our schemes.

Fast Authentication (FastAuth) enables real-time, lightweight au- thentication by exploiting the predictability of future beacon messages. In FastAuth, the lower the entropy of a future beacon (from the sender’s point of view), the smaller the beacon message is. We design a new structure called chained Huffman hash trees, which supports a one-time signature scheme whose verification is 50 times faster and whose generation is 20 times faster than ECDSA. Also, FastAuth reduces the communication overhead to half.

Selective Authentication (SelAuth) provides fast isolation of ma- licious senders. As a result, invalid signatures are contained to a small area, without impacting the rest of the network. SelAuth en- joys a short convergence time because vehicles intelligently select which signed messages to verify before forwarding. This selection is performed in a way that signatures with an unknown state (low certainty on the validity, or high “entropy”) are more likely to be checked. Specifically, we propose warning pushback to share in- formation about flooding vehicles, and forwarder identification to distinguish benign neighbors from misbehaving ones. The evaluation shows SelAuth imposes 10%–35% computational overhead compared to other closely related schemes while containing 99%

of invalid signatures to one hop.

Contributions. The main contributions of this work are:

• We identify that the current broadcast authentication standard for VANETs fails to operate under signature flooding, which occurs frequently even in benign settings.

• We propose two novel flooding-resilient schemes enabling timely and efficient signature verification; FastAuth leverages beacon predictability to secure safety beacons, and SelAuth utilizes neighbor information to secure multi-hop messages.

• Analytical and experimental results show that VANETs can be made practical with our schemes, which provide substantial performance advantages over prior work.

Organization. Section 2 provides background on VANET settings and cryptographic primitives. Section 3 presents the problem definition and the threat model. We introduce FastAuth and SelAuth schemes in Sections 4 and 5, respectively. We then evaluate Fast- Auth and SelAuth in Sections 6 and 7. Section 8 summarizes the prior work on broadcast authentication. We conclude in Section 9.

2. BACKGROUND

Before describing our proposed broadcast authentication schemes, we give an overview of the VANET setting as dictated by the IEEE 1609.2 standard [15] and provide background on basic cryptographic primitives we use.

2.1 VANET Standard

Public key infrastructure. As proposed by the IEEE 1609.2 stan- dard, VANETs are required to have a Public Key Infrastructure (PKI) for key management. Each vehicle has a pair of ECDSA

keys: a private signing key and a public verification key. The verification key is certified by a certificate authority (CA). Auto manufacturers or regional Department of Transportation agencies can act as CAs. Each key pair will then be stored in the vehicle’s OBU, with tamper-resistant protection to protect the private key from compromise. To protect privacy and prevent location track- ing, a VANET-enabled vehicle can obtain multiple certified key pairs with non-overlapping periods of validity and change its public key periodically (e.g., every five minutes) [32].

VANET message format. A VANET message contains a times- tamped message body m, the sender’s signature S(m) on m, and the sender’s public key certificate.

"m, S(m), cert# (1)

The timestamp states the creation time of this message, which helps the receiver determine this message’s deadline. A vehicle should act upon a received message before the message’s deadline. The signature ensures that the sender is accountable for sending this message, and thus deters selfish drivers from broadcasting bogus information for self-interest.

Application types. VANET applications can be classified into two types based on how frequent messages are sent and the distance these messages need to be propagated [12]. In single-hop relevant applications, vehicles periodically exchange beacons with nearby vehicles that are one hop away from each other. Beacons contain the sender vehicle’s kinematics information such as position and velocity to enable timely reaction to unsafe conditions. The IEEE 1609.2 standard instructs vehicles to broadcast beacons 10 times per second. Message information is obtained from on-board devices such as GPS. Commodity GPS devices can provide meter- level positioning accuracy and nanosecond-level timing accuracy [1].

Many VANET applications rely on the information embedded in beacons. For example, in the Cooperative Collision Warning (CCW) application, vehicles continuously monitor their neighbors’ current position and speed to warn the driver of potential accidents. In this paper, we denote B_t(x) as a beacon sent by vehicle x at time t. When there is no ambiguity in terms of the sender’s identity or time, Btor B is used for brevity. In contrast to the single-hop rele- vant applications, in multi-hop relevant applications, messages are sent on demand and to vehicles that are potentially multiple hops away. For example, when sensing congestion, the Congestion Road Notification (CRN) application will create a message indicating the location, time, and congestion level to warn distant vehicles of the jammed segment.

2.2 Cryptographic Primitives

In the remainder of this section, we provide background on One- Time Signatures (OTS) and an OTS scheme called Merkle tree signatures. The core ideas of applying OTS to VANET authentication are detailed in Section 4.

One-Time Signature (OTS). A One-Time Signature [21, 27, 30] is a special type of public key cryptosystem whose signature generation and verification are thousands of times faster than other signature schemes like ECDSA. However, OTS suffer from longer keys and signatures (thus higher communication overhead) and their signing key can only be used once to sign a single message.

For example, to sign a 1-bit message m, the OTS signer generates two key pairs: {pk₀, sk₀} and {pk₁, sk₁}, where the private keys sk₀ and sk₁ are chosen at random, and the public keys are com- puted as pk0= H(sk0) and pk1= H(sk1), where H(·) is a one-way function without trapdoors, and thus it is computationally infeasi- ble to recover sk_bfrom H(sk_b). If the message to be signed is 0, the signer publishes its signature S = sk0. If the message to be signed is

(3)

h0 h1 h2 h3

h₀₋₁ h₂₋₃

PK h0= H(v0||r0)

h₁= H(v₁||r₁) h₂= H(v₂||r₂) h₃= H(v₃||r₃) h₀₋₁= H(h₀||h₁) h2−3= H(h2||h3) PK = H(h₀₋₁||h₂₋₃)

Figure 1: Example of a Merkle signature tree. The signature of m = v₁is {h₂₋₃, h₀, r₁}.

1, then S = sk₁. Hence when receiving a signature S on a 1-bit mes- sage m, the receiver can verify whether H(S) = pkm. In practice, we can use cryptographic hash functions, such as SHA-1, to imple- ment such one-way functions. For convenience, in the rest of this paper, we use the term hash to represent the process as well as the output of such a one-way function. Signing an x-bit message can be accomplished by signing each of these x bits separately, resulting in an overhead linear to the size of the message.

Merkle tree signatures. An alternative to processing each bit sep- arately is to create a common public key over all possible message values using a Merkle hash tree, as shown in Fig. 1. The hash tree root is the public key PK and each leaf is the hash of the concate- nation of one of the possible message values and a random value.

Each inner vertex represents the hash of the concatenation of its children. After constructing this Merkle hash tree, the signer can obtain a signature as follows: the signature of a message v_xcon- sists of the corresponding random value r_xand all off-path vertices from the leaf node to the root. Off-path vertices are the siblings to the ancestors of hx. Merkle signatures provide non-repudiation because of the computational infeasibility of finding another message with the same off-path values. Fig. 1 illustrates the Merkle hash tree construction representing an OTS to sign a 2-bit mes- sage, which has four possible values: v₀= 00, v₁= 01, v₂= 10, and v₃= 11. r₀, r₁, r₂, r₃are random values, and the arrows indi- cate inputs to the hash function H. Hence the signature of m = v2

is S = {h₀₋₁, h₃, r₂}. To validate this signature, the receiver re- computes the root of the hash tree from the received signature S and the message m. Then the receiver verifies whether the root equals PK, announced previously by the signer. In this paper, we use this Merkle signature scheme as a cryptographic primitive to construct one of our flooding-resilient signature schemes.

Tradeoffs in broadcast authentication. Table 1 shows the over- head of OTS and ECDSA signatures, which represent two extreme designs in broadcast authentication: OTS enables fast verification with expanded signatures, whereas ECDSA signatures are short but require long verification time. Hence, the challenge is to enable fast authentication with short signatures.

3. PROBLEM DEFINITION

Our goal is to design signature schemes with fast verification to mitigate signature flooding in the context of VANETs. Signa- ture flooding describes a scenario where a large number of signature verification requests overwhelm the receiver’s computational resources. We consider signature-based broadcast authentication schemes that guarantee message authenticity and non-repudiation.

Threat Model. We consider signature flooding caused by “flash crowds” [16] (i.e., a large number of benign vehicles broadcasting valid signatures within the victim’s radio range) and by one or more

Per-signature overhead ECDSA-256 OTS

Generation 7 ms 320µs

Verification 22 ms 160µs

Public key size 256 bits 320 hashes (1 hash) Signature size 512 bits 160 hashes (160 hashes) Table 1: Signature generation and verification time reported in VAST [37], assuming signing the SHA-1 hash of a message.

Numbers in parentheses represent the overheads of the Merkle signature scheme, where the size of one hash is 160 bits in case of the SHA-1 hash function.

colluding attackers sending invalid signatures. We do not consider attackers flooding other vehicles with a high volume of valid signatures since the receivers can quickly identify the attackers and then blacklist them. For a given authentication scheme, the attackers may also trigger unnecessary message verification by performing scheme-specific actions. A vehicle under signature flooding may be unable to verify every received signature before the message’s deadline due to limited computational resources. Jamming attacks can also prevent VANET participants from communicating but can be addressed by jamming defenses [7, 23].

Desired properties. VANET broadcast authentication has two de- sired properties: non-repudiation and timely verification. With the non-repudiation property, the recipient can prove to a third party who is accountable for creating a message. Non-repudiation also implies authentication, such that the recipient can identify the sender and detect malicious injection or manipulation of packets. Timely signature verification is required as well because each VANET message has an expiration time (or deadline) by which it should be verified. Single-hop applications often have a shorter deadline than multi-hop applications.

4. FAST AUTHENTICATION (FastAuth)

This section presents FastAuth, an efficient One-Time Signature (OTS) scheme to authenticate beacon messages. The novelty in FastAuth is the design of a Chained Huffman Hash Tree (CHT), which leverages the predictability in vehicle mobility to generate small signatures.

As introduced in Section 2.1, a VANET-enabled vehicle broadcasts beacon messages at a rate of 10Hz to inform nearby vehicles of its position and velocity, enabling safety applications to alert drivers of potential accidents. Every beacon has to be verified upon its reception because the beacon may contain decisive and urgent safety information. However, the current VANET signature standard [15] (i.e., signing every beacon using ECDSA) is computationally expensive, whereas conventional OTS enables instant verification with increased communication overhead. Motivated by this unique challenge, the goal of FastAuth is to achieve fast authentication with short signatures.

4.1 Insights to Generate Short OTS Signatures

The intuition on how predictability in vehicle movements helps shorten OTS signatures is as follows. We observe that the entropy of a beacon is relatively low from the sender’s point of view. In other words, the sender can predict what will be sent in subsequent beacons with high probability. For example, the timestamp can be pre-determined given that beacons are sent regularly (every 0.1 second), and the velocity is largely deterministic given the trajectory.

However, predicting the trajectory is non-trivial. It is difficult to determine a definite future position due to a vehicle’s degrees of freedom. Fortunately, a prediction is possible because of the

(4)

following reasons: 1) The laws of physics and road topology re- strict the possible future locations. For example, a vehicle traveling slower than 80 miles per hour can move at most 3.3 meters in 0.1s.

2) Most of the time the vehicle is likely to move forward along the road rather than backward or sideway. 3) Due to the inherent positioning inaccuracy introduced by positioning devices (e.g., 2 meters inaccuracy in commodity GPS devices), we can round a location to a coarser-grained numerical representation to further reduce the number of candidate locations. For example, rounding location to meters only inflates the positioning inaccuracy from 2 meters to 2.5 meters, which is still acceptable for safety applications. Con- sequently, a small number of positions will occur with high probability and other positions are unlikely. Taking such a probability distribution into account, we are able to construct a one-time signature scheme using coding theory to shorten the signatures. Par- ticularly, FastAuth adopts Huffman coding [14], an encoding algorithm minimizing the expected length of encoded messages. That is, FastAuth explores a new trade-off point in the design space of broadcast authentication: the size of a FastAuth signature depends on how well the signer can predict its own message content.

4.2 Protocol Overview

At a high level, each vehicle in FastAuth divides its timeline into a sequence of prediction intervals. In each prediction interval, a vehicle performs three steps: Beacon Prediction, Key Pair Con- struction, and Signature Broadcast. We provide an overview of these steps as follows.

Beacon Prediction (Sec. 4.3) At the beginning of a prediction in- terval, each vehicle predicts its beacon messages for the next I bea- cons. To do so, vehicles model the probability distribution of the distance vector between two consecutive beacons based on information of the past trajectory. For example, in Fig. 2(a), the vehicle predicts that it will move forward (D_f) with probability 0.5.

Key Pair Construction (Sec. 4.4) Before sending any beacon mes- sage in this interval, the vehicle needs to construct an OTS public key and one interval worth of OTS private keys. We propose a chained Huffman hash tree (CHT), which ties these pre-computed keys together in a fashion that minimizes the size of signatures and generates a single public key, as shown in Fig. 2(b).

Signature Broadcast (Sec. 4.5) After beacon prediction and key construction, a vehicle signs its OTS public key using ECDSA sig- natures and then broadcasts this ECDSA signed public key PKots

along with the first beacon in this prediction interval. When a ve- hicle moves to a position Li at time Ti, it sends out a beacon Bi

with this time and position information. Moreover, to maintain a high beacon update frequency during severe packet loss, we integrate Forward Error Correction [25, 33] into FastAuth to recover lost beacons.

4.3 Beacon Prediction

Since position is the main source of uncertainty in beacon message contents, we discuss how the beacon sender can predict and encode its own future positions. Specifically, FastAuth requires the sender to model the probability distribution of the movement (or the distance vector) between every two consecutive beacons, B_i−1and Bi. The output of this step is a prediction table Giin which each entry represents one possible movement between time Ti−1and Ti

and the probability of making this movement.

Representing positions using a local coordinate. To compress the amount of information, the sender expresses its future positions using a coarse-grained local coordinate. The origin of this local coordinate is placed at the beginning position of the current predic- tion interval (i.e., L0). Then every future position Liin this interval

Prediction table movement

Df= (1, 0) Dl= (1, 1) Dr= (1, −1)

probability 0.5 0.25 past trajectory 0.25

Dl

Df

Dr

!Δy

!Δx

(a) Determine the prediction table.

h_1,l h1,r

h_{1, f}

h_2,l h_2,r h_{2, f}

PKots ht,d= H(Tt||Dd||Rt,d)

Rt,dare random numbers

(b) Construct a chained Huffman hash tree. Each tree corre- sponds to one future beacon, and each leaf node in a tree cor- responds to one entry in the prediction table. In this example, the signer constructs the OTS keys for the next two beacons.

h1,l

h_1,l h_1,l

h_1,r h_1,r

h1,r

h1, f

h_{1, f} h_{1, f}

h_2,l h_2,l

h_2,l

h_2,r h2,r

h_2,r

h_{2, f} h2, f

h_{2, f} PKots

Broadcast B₀at T₀. In B₀, m = {T₀, L₀, PK_ots,!Δx,!Δy}, S = ECDSA(m)

Broadcast B₁at T₁. In B₁, m = {T₁, L₁, R_1,r}, S = !

Broadcast B₂at T₂. In B₂, m = {T₂, L₂, R_{2, f}}, S = ! D_r

D_f

(c) Beacon broadcast. To verify B₂, the receiver reconstructs the tree root for T₁using the information in B₁and B₂, and checks if the root matches the one signed in B₁.

Figure 2: Example of FastAuth.

can be approximated by

Li!L0+ xi!Δx+ yi!Δy, where

• !Δxis a vector parallel with the instant velocity at T₀,

• !Δyis perpendicular to !Δx,

• xiand yiare rounded to integers,

• and the scalar of each vector (i.e., |!Δx| and |!Δy|) is chosen by the vehicle to achieve a desired level of positioning accuracy.

For example, |!Δx| and |!Δy| can be set to 2 meters, which is the accuracy of commodity GPS devices, because a finer representation would contain more noise than useful information. Hence, each movement from time T_i−1to T_i

Di= Li− Li−1= (xi− xi−1)!Δx+ (yi− yi−1)!Δy

can be encoded as a pair of integers (x_i− x_i−1, y_i− y_i−1).

Constructing prediction tables. A prediction table Gi maps a movement D_iin the new coordinate to a probability of making such a movement. For example in Fig. 2(a), an entry [(1, 1), 0.25] in the prediction table means that the probability of moving one unit along

(5)

!Δxand one unit along !Δyis 0.25. A vehicle may have different prediction tables from other vehicles. The prediction tables can also vary with time, location, and speed. However, accurately modeling a vehicle’s mobility is outside the scope of this paper; our focus is to design a broadcast signature scheme that performs better as the prediction accuracy increases. For illustration purposes, we discuss two possible approaches to generate a prediction table in Section 6.

Efficient Probabilistic modeling of future positions. A predic- tion table models a vehicle’s movement in one beacon interval. By combining several prediction tables, we are able to model the vehicle’s position not only in the next beacon but in many succeeding beacons. Let a prediction table G_ibe a random variable represent- ing the distance vector from Li−1 to Li, and thus ∑^i=Ii=1Gi is the random variable representing the movement from L0to LI.

To see the advantage of encoding movements in a local coordinate, consider a simple scenario where a vehicle either moves forward 1 unit or stays at the same location during each beacon interval. In FastAuth, only 1-bit information (moving or staying) needs to be announced in each beacon. However, without consid- ering the dependency between beacons, the vehicle has to encode i possible positions for beacon B_iat T = i, because the vehicle can be anywhere between position 0 and i.

4.4 OTS Key Construction

Before sending any beacons, a vehicle needs to generate OTS private keys for signing and the public verification key. Given the estimated future locations obtained in the previous step, our pro- posed Chained Huffman Hash Trees (CHT) structure minimizes the signature size by leveraging Huffman coding.

Combining Merkle and Huffman trees. A Merkle hash tree is a binary tree in which each leaf is assigned a value and the value for an inner node is the hash of its children. As discussed in Sec. 2.2, we can construct an OTS scheme using Merkle trees. Similarly, a Huffman tree is a binary tree data structure. In contrast to having values at leaves, each leaf node in a Huffman tree is associated with a probability. The sum of all leaves’ probabilities adds up to one.

For any pair of leaves in a Huffman tree, the leaf with a higher probability is never located deeper than the other leaf associated with a lower probability. Huffman trees provide the property of minimal expected depth of leaves. Hence, we can integrate these two trees into one Huffman hash tree, in which each leaf is assigned a proba- bility p and a value h, since Huffman coding determines the organi- zation of a tree and Merkle hash construction determines the value of tree vertices. The tree organization follows the rules of building Huffman trees and the value of each inner node is determined as in Merkle trees. In the VANET context, for each entry [Dd, p] in the prediction table G_t(which means that from T_t−1to T_t, the vehicle will move to location L_t−1+ D_dwith probability p), there is a leaf in the Huffman hash tree labeled with (p, H(Tt||D_d||R_t,d)), where R_t,dis a random value to prevent signature forgery.

Chaining Huffman hash trees. A CHT contains I Huffman hash trees linked together to further reduce the computational overhead in verifying signed beacons. The roots of these trees are chained together chronologically and the anchor of the chain is the public key PKotsfor the current prediction interval. Fig. 2(b) illustrates the resulting chained tree structure. While the root of a single hash tree is computed by hashing the concatenation of its two children lctand rct(roott= H(lct||rct)), in the chained structure

roott= H(lct||rct||roott+1) (2) for all 1 ≤ t ≤ I − 1. Then the public key PKots, or the hash anchor, is PKots= root1.

4.5 Signature Broadcast

After constructing the prediction table using a local coordinate and generating the OTS public key PKots, the vehicle broadcasts its first beacon containing its public key and the parameters of its local coordinate system, i.e., the first beacon in a prediction inter- val is B₀= {m₀, S(m₀), cert}, where m₀= {T₀, L₀, PK_ots,!Δx,!Δy} is signed using ECDSA.

To sign a beacon for position Liand time Ti, the vehicle locates the leaf node corresponding to L_iand T_i, and broadcasts the off- path hash values of this leaf as the signature. Off-path nodes are defined as the siblings of nodes on the path from this leaf to rooti. Fig. 2(c) illustrates which hashes should be selected as the signature at each time. The car indicates the leaf associated with the current time and location. The nodes labeled with “!” are the off-path nodes that “sign” the current message. In this example, at T1the signer has moved to L₁= L₀+ Dr, associated with h_1,r. Hence, B₁’s signature includes the off-path hashes: h_1,l, h_{1, f}, and the root of the next hash tree, root2. To verify the signature, a receiver of B1

reconstructs h_1,rfrom the message and computes the current hash tree root, rooti, from the off-path hashes. If the root matches PKots, the receiver is convinced that the sender moves Drdistance from T₀ to T₁ thus being located at position L₀+ D_r. Similarly, B₂’s signature is the sibling node of h_{2, f}. Generally to verify signed Bi, the receiver reconstructs the current tree root, rooti, and checks whether Equation (2) holds given the hash values in the previous hash tree.

Dealing with packet loss. One drawback of the CHT structure is that once the receiver misses a beacon, it cannot verify any subsequent beacons in the current prediction interval, because the verification of the current beacon relies on the root of the previous beacon. Hence on average missing one beacon prevents verifica- tion of I/2 beacons. In contrast, when using ECDSA missing one beacon has no impact on verifying the future beacons. Unfortu- nately, packet loss is common in wireless networks. Especially in VANETs, the loss rate can be up to 30% in a benign environment, and up to 60% in a congested environment [3]. Hence it is important to deal with packet loss to reduce the number of unverifiable beacons. To mitigate the impact of packet loss, FastAuth adds redundancy into beacons using Reed-Solomon coding [33] such that when a beacon Bi is missing, the reception of u out of the suc- ceeding w beacons (i.e., Bi+1, Bi+2..., Bi+w) can help reconstruct B_i. Let RS(w, u) be the Reed-Solomon coding process, e.g., encod- ing Biusing RS(3, 2) generates three codeblocks, r₁, r₂, r₃, and any two of them together can reconstruct Bi. The size of a codeblock is

|B_i|/2. To enable error correction, the vehicle broadcasts r₁along with B_i+1, r₂ with B_i+2, and so on. The higher the loss rate is, the more redundancy should be added into beacons, which can be achieved by increasing w/u at the cost of higher communication overhead. Hence, vehicles can adjust the RS code parameters to achieve a desired level of performance given an estimated packet loss rate.

Public key rebinding. PKotsis only sent at the beginning of a pre- diction interval. If a vehicle X encounters vehicle Y after Y broad- casts its current OTS public key, X will be unable to verify Y ’s bea- con until the next interval, which may take several seconds and X could already physically encounter Y . To overcome this drawback, every IEbeacons vehicle Y signs its beacon by ECDSA in addition to OTS. Hence, the receiver can initiate authentication from this additional trust anchor. Moreover, this mechanism can bound the beacon update frequency in face of high loss rate.

Dynamic interval. If a vehicle moves outside the area covered by its prediction table, the corresponding OTS will not exist in the CHT. For example, in Fig. 2(c), if the vehicle remains stationary

(6)

between T1and T2, no OTS signature exists for B2due to the ab- sence of the corresponding entry (i.e., (0, 0)) in the prediction table. Hence, instead of having a fixed interval, we allow vehicles to evoke a new predication process whenever the current position deviates outside the coverage of the prediction table. Terminating the current prediction interval and restarting a new one greatly increases the computational overhead. Fortunately, early termination of an interval is unlikely to occur when the prediction table cov- ers most of the possible displacements in one beacon interval, as designed in Fig. 4.

4.6 Preliminary Analysis

The bandwidth saving in FastAuth depends on the accuracy of the location prediction. Hence in the rest of this section we discuss and quantify how the position prediction accuracy affects Fast- Auth’s signature size. In section 6 we perform an evaluation using real traffic traces.

We denote by Φ the trajectory prediction function used by a vehicle, and by L_ithe actual position of a vehicle at time T_i. Φ(Ti, x) returns the probability that the vehicle will be at position x at time T_i. On one extreme, when Φ is a prefect prediction function (i.e., Φ(Ti, L_i) = 1) the vehicle consumes the minimum possible bandwidth because for each beacon the vehicle only needs to send one hash to acknowledge that it is still moving along the estimated trajectory. On the other extreme, when Φ outputs a completely wrong prediction (i.e., Φ(Ti, Li) = 0), the vehicle has to perform re-prediction and send an ECDSA signed beacon every time.

Now we consider a general case where Φ(Ti, L_i) = p (0 < p < 1) with n non-zero values in the prediction function’s input domain (i.e., n possible movements). An accurate prediction function has a high p and a small n. To simplify the analysis, we assume ex- cept Li, every position is associated with the same probability

1−p

Taken together, we can conclude that an inaccurate prediction func- tion (i.e., a low p or a large n) results in longer signatures.

5. Selective Authentication (SelAuth)

In Section 4, we presented FastAuth, a signature scheme sup- porting instant verification of single-hop messages (beacons) by exploiting the low entropy of beacons. In this section, we switch our focus to multi-hop VANET applications, in which messages often traverse multiple hops before expiration. In multi-hop applications, vehicles only need to check a signature when the message needs to be acted on (verify on demand). Hence for most messages vehicles can forward them without verification to preserve their limited computational resources. However, such a verify-on-demand approach is vulnerable to communication-based denial of service attacks where the attacker sends a large number of bogus signatures to exhaust the available bandwidth, because a single invalid signature is likely to be relayed and duplicated many times before being detected at the destination(s). On the other hand, checking every signature (Verify-All) blocks invalid signatures as close to the source as possible but is computationally expensive.

In response to the challenge for designing an efficient verification scheme for multi-hop applications, we present SelAuth, a signature verification protocol that can quickly block the spread of invalid signatures without checking all incoming signatures at every hop.

In essence, we observe that when the receiver knows more about a received signature, i.e., high certainty (low entropy) on the sig-

nature’s validity, the signature can be checked with a lower proba- bility. In particular, SelAuth uses neighbor identification to avoid impersonation and per-neighbor verification probability, adjusted dynamically as wrong signatures are received, to achieve isolation.

Neighbors of a vehicle can directly communicate with the vehicle.

Let pxy denote the probability that vehicle y checks a packet for- warded by vehicle x. x and y are neighbors. The goal is to update p_xyso that p_xy→ 0 for legitimate x, and p_xy→ 1 for malicious x.

After a short period of time the network should converge to a state where neighbors of malicious vehicles check everything whereas others check nothing. SelAuth also uses warning pushback to ac- celerate the isolation of malicious vehicles.

As in many other probabilistic verification schemes [10, 19, 34, 38], vehicles running SelAuth verify an incoming message with a certain probability in order to help detect invalid signatures. How- ever, an important difference is that in prior work such a probability depends solely on the local status of the receiver, regardless where this message is from or whether other vehicles have verified this message. In contrast to having the vehicle at each hop making its authentication decision independently, SelAuth leverages auxiliary information shared between neighbors to facilitate the probability adjustment for fast and efficient isolation.

5.1 Protocol Overview

The core components of SelAuth are forwarder identification and warning pushback, enabling SelAuth to converge faster than other probabilistic verification schemes and be more resource-efficient than the Verify-All approach.

Forwarder identification. Forwarder (or neighbor) identification enables the receiver of a message to efficiently identify which of its neighbors sent or forwarded this message. Digital signatures provide this property but are computationally expensive. As a result, we achieve forwarder identification using symmetric cryptographic operations, as described in Section 5.2. Moreover, forwarder identification holds vehicles accountable for their forwarding behavior and enables a deployment of per-forwarder verification proba- bility. For example, if A receives m_bforwarded by B and mcfor- warded by C, A will verify mb with probability pba and mcwith probability p_ca. These probabilities get updated over time; eventu- ally the links incident to malicious nodes have a high verification probability, and a bad node that has forwarded too many invalid signatures is punished by being blocked from communication.

Warning pushback. In SelAuth, vehicles detecting an invalid sig- nature will initiate a Complaint message to warn vehicles at the previous hop. If a vehicle at the previous hop agrees, it will issue a Complaint as well. As a Complaint propagates back to the originator of the invalid signature, every vehicle that had forwarded this signature can be warned and then increases its verification proba- bility accordingly. Hence, it is also called a Pushback message as it is pushed towards the originator.

Protocol flow. Fig. 3 shows SelAuth’s protocol flow when y re- ceives a message from a neighbor x. Let p_xybe vehicle y’s verifica- tion probability on messages forwarded by x. WLOG, we assume y is legitimate and x may be either legitimate or malicious. pxy

is undefined when y is malicious because y can behave arbitrar- ily. Let [M]xdenote a message forwarded by x. [M, IDR]x, where M = {m, S(m), cert} is a standard VANET message and IDRrepre- sents the one-hop receiver(s): ID_Ris the target ID for pushback and ID_R= ∗ otherwise for broadcast. y first checks whether M has been received before (e.g., sent by another neighbor) and identifies the forwarder. If M is new and sent by a known neighbor, y checks the signature S(m) with probability pxy. If S(m) is valid or the check is bypassed, y rebroadcasts the message and decreases pxy; otherwise

(7)

y ← [M, IDR]x

is M new?

x = known?

finish / wait for next incoming message IDR== ∗?

check(S, pxy)

increase pxy

check(S, 1)

send [M, x]y

send [M, ∗]y

increase payif

a forwarded M send [M, a]y

decrease pxy

valid valid

unverified or invalid

invalid no

no

no no

yes

yes yes

Figure 3: Flowchart of SelAuth. We discuss how probabilities are initialized and adjusted in Sec. 5.2.

pxy increases. We discuss the details of probability initialization and adjustment in Sec. 5.2. If M is a pushback from a known for- warder complaining about an old message, y checks whether the complaint is true: if S(m) is really invalid, y finds out who had for- warded M to it and increases the probability accordingly; if S(m) is in fact valid, y increases p_xyto punish x for lying.

5.2 Realizing Forwarder Identification

Forwarder identification can be achieved using authentication.

At first glance, this sounds like a circular problem: our SelAuth authentication scheme relies on forwarder identification, which requires authentication as well. However, the difference is that Sel- Auth is a signature mechanism for multi-hop applications, whereas forwarder identification requires only single-hop authentication without non-repudiation, because for forwarder identification, a vehicle only needs to prove its identity to its one-hop neighbors rather than a third party.

For such single-hop authentication, a digital signature is too expensive to generate and verify. Also, FastAuth is inapplicable to be applied directly because messages in multi-hop relevant applications are infrequent and hard to predict. Fortunately, we observe that the TESLA authentication scheme [31] can be applied here with few modifications. TESLA requires loose time synchro- nization, which is naturally supported in VANETs where messages are timestamped with nanosecond accuracy by GPS-equipped vehicles. TESLA constructs self-authenticating one-way hash chains, in which each value can be authenticated efficiently using the previous value in its hash chain. The anchor of a hash chain is dig- itally signed as a root of trust for bootstrapping. Specifically, in SelAuth, we leverage FastAuth to sign trust anchors, since these anchors can be pre-computed thus known to the sender before constructing beacons. For simplicity, in the following we assume the hash values are revealed in sequence in beacons, i.e., B_i contains ai−1and ai−1= f (ai), where f is a one-way function. One benefit of including each hash-chain value in beacons is that a vehicle can start the forwarder identification process even if the vehicle misses the initial trust anchor of the hash chain. In practice, hash-chain

values can be sent independently from beacons. A vehicle uses ai

to derived a cryptographic forwarder ID for each packet it sends between B_i−1 and Bi. A cryptographic ID for a message M sent between Bi−1 and Biis MAC_f⁽_(a_i₎(M), where MAC is a Message Authentication Code and f⁽is a one-way function different from f . A cryptographic forwarder ID is appended to its associated mes- sage to make the message’s forwarder identifiable. After receiving MAC_f⁽_(a_i−1₎(M) and Bi, the receiver can be convinced that M for- warded by the sender of and B_i. Using TESLA for forwarder identification, SelAuth introduces verification delay because a receiver has to wait for the disclosure of hash-chain values for verification.

However, a small delay is acceptable in flooding-based multi-hop communication where timing is not critical.

5.3 Implementation Decisions

Memory-efficient message status checking. To identify previ- ously forwarded messages, each vehicle maintains one Bloom Fil- ter [4] for valid messages and one for invalid messages, and keeps per-neighbor Bloom Filters for unverified messages from each of the neighbors. Hence when getting a Complaint about a previ- ously received but unverified message M, the vehicle can identify the forwarder of M and increases the probability accordingly. Each vehicle also keeps a Bloom Filter for Complaints to prevent re- play attacks that would further increase the verification probability.

Also, the filters are reset periodically to remove stale messages. A Bloom Filter is a space-efficient data structure enabling fast mem- bership checking. If a message M has been added into a Bloom Filter BF, checking BF(M) will always return true (match found);

if a message M⁽has never been added into the Bloom Filter, check- ing BF(M⁽) will return false (no match) with very high probability.

It is called a false positive when a Bloom Filter falsely returns a match. When a false positive occurs, vehicles may wrongly drop a new message. To prevent malicious vehicles from deliberately causing more false positives (e.g., by sending out a small number of properly crafted messages to fill the filter), every Bloom Filter should be kept private or keyed so that only the owner who picked the key k can evaluate the function BF_k(M). Although false positives have a similar effect as packet loss, they have a limited impact on SelAuth because the false positive rate (e.g., 1%) is often much lower than the packet loss rate (e.g., 30%).

Probability initialization and adjustment. There are many ways to assign an initial value p₀to p_xyand to adjust it after the initial assignment. For example, a vehicle can assign an identical initial probability to every newly identified neighbor. The adjustment function can be linear (the same amount of increment and decre- ment), MIAD (multiplicative increase and additional decrease), or a step function (jump to 1 and come back to p0when receiving a threshold number of valid signatures). We use a step function as suggested in the prior work [34] to accelerate the isolation process.

Probabilistic pushback. One invalid packet can trigger more than one pushback. However, only one pushback is needed to warn of the bad packet. To avoid unnecessary communication we imple- ment probabilistic pushback, in which a vehicle y sends a pushback complaining a packet previously forwarded by x with a probability 1 − p_xy, in contrast to initiating a pushback whenever detecting an invalid packet. The idea is that the lower the verification probabil- ity pxythe more likely that the vehicle x is benign and needs the warning of the presence of malicious entities, whereas a high veri- fication probability implies that x may be malicious and thus it will be a waste to send warnings to x.

Dealing with consistent attackers. To deal with consistent at- tackers who never send valid signatures, we always verify the first packet from a newly encountered neighbor. Moreover, if x’s mis-

(8)

behavior persists, y should block the identified malicious forwarder by dropping all the traffic from x or invalidate x’s certificate by re- porting x to an authority.

Delayed verification. On one hand, we want to block invalid traf- fic from malicious senders. On the other hand, we also want to retain high throughput by taking advantage of these bad nodes, i.e., by permitting them to forward packets. To achieve this, SelAuth delays the verification of messages from malicious nodes. Delayed signature verification can help because a vehicle is likely to have received duplicated messages due to the broadcast nature. De- layed verification can address the case where a vehicle has only one neighbor but the neighbor is malicious. Rather than dropping all packets forwarded by the malicious neighbor and making itself get disconnected from the network, the vehicle may want to sacri- fice some security for availability.

5.4 Preliminary Analysis

A full simulation of SelAuth can be found in Section 7. In this analysis, we consider a simple line model where vehicles are placed at location 0, l, 2l, · · · . The communication range is ld, so there are d next-hop vehicles that forward messages ahead. The initial verification probability is p for all vehicles. The attacker sends n invalid signatures during each time interval. Hence the probability that a receiver of the n invalid signatures does not catch any of them (and thus forward all of the messages) is α = (1 − p)ⁿ. We investigate the case with an attacker at the origin. Note that SelAuth always checks the first message from a new neighbor, and thus the attacker’s optimal strategy is to behave at the beginning (t = 0) by sending one valid signature and attacks after t = 1.

To quantify the impact level, let I(t, h) be the expected number of invalid signatures forwarded at time t by vehicles h hops away from the attacker. Note that I(t, h) is defined only when 0 ≤ h ≤ t.

Hence we can express I(t, h) as:

I(t, h) = n(α^(t−h)hα^∑^t−hⁱ⁼⁰⁾^t−h−i² ^*) = nα1/4(t−h)(t+h+1) (3) where α^(t−h)hrepresents the probability that none of the vehicles in the first h hops check the attacker’s packets sent in the first t − h intervals. α^∑^t−hⁱ⁼⁰⁾^t−h−i² ^*expresses the probability that the h- hop vehicles receive no pushback from other vehicles. This can be rephrased as “vehicles between h + 1 and )^t−h−i+1₂ * hops fail to check any bad packets sent during the first )^t−h−i+1₂ * intervals”.

Similarly the impact level without the pushback mechanism is:

IFI(t, h) = nα^(t−h)h. (4) The impact level in (3) decreases faster as t increases than in (4), as the pushback mechanism expedites the containment process.

The analysis shows that SelAuth can converge promptly to a state where no invalid signatures will be relayed; an attacker at best can only cause local attacks congesting the neighbors’ wireless chan- nel within one-hop communication range, in contrast to large-scale DoS attacks that affect communication multiple hops away.

6. EVALUATION: Fast Authentication

To evaluate FastAuth, we consider a sender vehicle sending beacons and a receiver vehicle receiving these beacons with probability 1 − ε, where ε is the packet loss rate. The sender moves along real traffic traces collected by General Motors. The GM dataset includes four traces and each of them was generated by a vehicle driving along a 2-mile path for about 2 hours. Though the trajectory is pre-defined for the purpose of simulation, the sender can only leverage its past trajectory to predict future location. We simulate

parameter sample value

ECDSA generation time 7ms ECDSA verification time 22ms

hash operation time 1µs

beacon size 378 bytes

hash size 20 bytes

RS code RS(5, 2)

prediction interval (I) 100 (10s) ECDSA rebinding interval (IE) 20 (2s)

packet loss rate (ε) 0.3 Table 2: Notation and sample values.

3 3 5 5

5 5

6 6 6

7 7 7 7

7 7

8 8 8 8

8 8

9 9

!Δx

!Δy

2 3

5

6 6

7 7 8

8

9 9 9

11 11 11

12

13

14 14

14 14 14 14

14 14

!Δx

!Δy

(a) default (b) trained

Figure 4: Signature size (in number of hashes) when the vehicle moves to a particular block.

FastAuth and SelAuth (shown in Section 7) separately to enable a clearer analysis.

6.1 Evaluation Settings

Table 2 lists the parameters and sample values commonly used in VANET simulations [11, 37]. In addition to these parameters, FastAuth requires a prediction table to model future location. In practice, car manufacturers or VANET application providers can apply advanced physics models and well-analyzed traffic statistics to construct the prediction table. For the purpose of simulation, however, we consider two methods to construct the table. For both, we build a prediction table large enough to cover most movements made by a vehicle in one beacon interval (i.e., 0.1 second), given that the maximum speed limit in US is 80 miles/h or 129 km/h.

The block unit is set to 2 meters given the positioning accuracy of commodity GPS systems. The first method considers the worst case where only a default prediction model is available, and allocates the probabilities using the principle of “the nearer the distance, the larger the probability”, as shown in Fig. 4(a). The other is to use the first half of each trace as the training data and evaluate FastAuth using the second half of trace. For each movement in the prediction table, its probability is determined by how often the vehicle made such a movement in the training data. This prediction table is shown in Fig. 4(b).

6.2 Simulation Results

In this simulation, we discuss the impact of the prediction in- terval (I), RS coding, packet loss rate (ε), and rebinding interval (IE) on FastAuth. In particular, we present the performance ratio of FastAuth to ECDSA. Table 2 summarizes the parameters used in the evaluation. We evaluate FastAuth using the following metrics: 1) sender/receiver computational overhead, 2) communication overhead (which reflects the accuracy of our location prediction model), and 3) average beacon update frequency (defined as the number of beacons successfully verified per second).

Fig. 5 shows the effectiveness of using trained and default ta-

(9)

0.3 0.4 0.5 0.6 0.7 0.8

0 10 20 30 40 50 60 70 80 90 100

ratio of communication

prediction interval (I) trained, I_E = 20 default, I_E = 20 trained, I_E = 50 default, I_E = 50

Figure 5: The effectiveness of trained and default tables as compared to ECDSA.

bles. Both models enable FastAuth to save more than a half of the bandwidth compared to ECDSA for I ≥ 10. Interestingly, the de- fault table performs better than using a short duration (one hour) of past trajectory as the indicator of future movement, since using the one-hour past trajectory without context is only a rough estima- tor. Hence, in the following we evaluate FastAuth using the default prediction table.

Fig. 6 shows the performance of FastAuth with various RS coding settings and rebinding intervals. Compared to ECDSA, signature generation in FastAuth (i.e., the sender’s computation) is 20 times faster and verification (i.e., the receiver’s computation) is 50 times faster. Also the communication ratio is only 20% – 40%.

With a smaller rebinding interval (IE= 20), the beacon update frequency is higher than using ECDSA because of the RS error cor- rection coding. However, a small I_E increases communication and the sender’s computational overhead. Also, more redundancy in the error correction code helps improve the update frequency at the cost of bandwidth consumption.

Fig. 7 shows the impact of the packet loss rate ε on the beacon update frequency and the sender’s computational overhead; the other two metrics are constant with respect to ε. As ε increases, the ratio of the average beacon update frequency drops and the receiver’s computational overhead increases. The result shows that FastAuth provides significant performance advantages even when ε is abnormally high, and the performance degrades gracefully as ε increases.

The result confirms that FastAuth can drastically reduce the computational overhead for both the sender and receiver. Specifically, our signature verification is 50 times faster and signature generation is 20 times faster than it using ECDSA. The communication overhead is reduced to 60% as well. Furthermore, FastAuth can achieve the same level of update frequency as ECDSA with the help of the error correction and key rebinding mechanisms.

7. EVALUATION: Selective Authentication

To evaluate SelAuth, we compare the performance of five signature verification schemes in multi-hop networks. We simulate these schemes using NS-2 [26] with the IEEE 802.11p MAC layer and Nakagami physical layer model [6], and synthesize vehicles’

traces on a realistic road topology using SUMO [17]. We evaluate the performance of five signature verification schemes in multi-hop networks. These five schemes are summarized in the table below:

0 0.1 0.2 0.3 0.4 0.5

0 10 20 30 40 50 60 70 80 90 100

ratio of sender comp.

RS(5,2), I_E = 20 RS(3,2), I_E = 20 RS(5,2), I_E = 50 RS(3,2), I_E = 50

0 0.05 0.1 0.15 0.2 0.25 0.3 0.35

0 10 20 30 40 50 60 70 80 90 100

ratio of receiver comp.

0.2 0.3 0.4 0.5 0.6 0.7 0.8

0 10 20 30 40 50 60 70 80 90 100

ratio of comm.

0.25 0.5 0.75 1 1.25 1.5

0 10 20 30 40 50 60 70 80 90 100

ratio of update frequency

prediction interval (I)

Figure 6: Evaluation based on real traffic traces.

scheme probabilistic per forwarder probabilistic verification probability pushback

SelAuth " " "

Verify-All

FI " "

PB " "

AA [34, 38] "

Verify-All is a naive approach in which vehicles verify every incom- ing packet. Forwarder identification only (FI) uses a per-forwarder verification probability without pushback warnings, while Push- back only (PB) provides pushback warnings without a per-forwarder verification probability (i.e., a shared verification probability for every neighbor). In Adaptive Message Authentication (AA), neither pushback nor forwarder identification is supported [34, 38].

7.1 Evaluation Settings

We analyze SelAuth in two scenarios: a linear scenario validat- ing the performance advantages and a real-world scenario demon- strating the practicability of deployment. In the linear scenario, 100 static vehicles are placed every 30 meters in a line and an attacker moves at a constant speed of 10m/s along the line. The simulation time is 50 seconds. The real-world scenario uses a road topology reconstructed from a 1km×1km downtown area of Manhattan.

We simulate 336 vehicles with random traffic patterns generated by SUMO (average speed is 10m/s), and one attacker travels along a manually selected path to circle within the area. The simulation