VANET Security and Privacy - Carnegie Mellon...

VANET Security and PrivacyVANET Security and Privacy

V-Sec

April 2012

2

A Brief Introduction to VANETA Brief Introduction to VANET

Mobile Ad-hoc Network (MANET)

Vehicle to Infrastructure (V2I)

Vehicle to Vehicle (V2V)

http://sigma.ontologyportal.org:4010/sigma/Browse.jsp?kb=SUMO&term=Antennahttp://openclipart.org/image/800px/svg_to_png/109651/car_icon.png

3

ApplicationsApplications

Safety

Congestion

P2PI'm here.

I am incoming.

There's a lot of people over

here.

I've can haz internets

Hmmm...

911!

4

Physical Layer ChallengesPhysical Layer Challenges

Differences from classic MANET

QoS

Time

Variability in density

Delay Tolerant Networks

Store-carry-forward

CSMA

802.11a - 802.11p

Prevailing protocol for traffic simulations

Can be improved for flooding

Safety Routing

Constraints

Time

Flooding

Suggested Protocols

Core Assisted Mesh Protocol

On-Demand Multicast Routing Protocol

Multicast AODV

Multicast OLSR

An Example of Flooding

Geographic Aware Flooding

Accident

Site

Biswas et al. from VEHICLE AD HOC NETWORKS: APPLICATIONS AND RELATED TECHNICAL ISSUES

Data Dissemination Limitation

It's all about relevance

Limit by geographic area

Limit by hop count

Packet Storm

AODV

5.9 GHz, 10MHz channel, 20mW transmission

power, receiver sensitivity threshold -95dBm

N. WISITPONGPHAN et al. BROADCAST STORM MITIGATION TECHNIQUES IN VEHICULAR AD HOC NETWORKS

Introduction Questions

Questions on these topics?

Implementation

Application

Flooding

An Introduction to Security

Get your security hat on

Integrity

Privacy

Authenticity / Liability

Verification of Data Consistency

Availability (Timeliness)

Who is the adversary?

Insider vs Outsider (Not a Stephen King villain!)

Malicious vs Rational

Active vs Passive

Local vs Extended

M. Raya and J.-P. Hubaux / Securing vehicular ad hoc networkshttp://www.geekologie.com/2008/05/oh-man-i-need-one-duckhunt-hun.php

PKI

Every vehicle obtains trust from a trust authority

Do you see problems with this?

Key Storage and Management

Keys stored psuedo-securely within the vehicle

TPM

Identity

Electronic License Plate

Electronic Chassis Number

ID paired to Key

Anonymous Keys

Preserve Privacy

Define a set of authenticated psuedonyms

Key Revocation

Send a revocation message to the vehicle

Send a revocation to the region

Send a revocation to the world!

Do you see a problem here?

Alternate Keying Schemes

In short, why we don't use these.

Pairwise keys

Does not scale

Short connection times

Group Communication

Fast fragmentation

Fast join

Rekeying

Vehicles traveling in the opposite direction

Geographic Grouping

Group membership defined by road segment

Preloaded segments and GPS needed

Leader needed

No Non-repudiation

Anonymity

Key changing Interval

Lower bound

Upper bound

Number of Messages

– This makes no sense to me

drdv dr

datt

More Problems

Questions ?

Secure Geocast

DoS

Hopeless for now, but can we notify the driver?

Data Verification

This is the same as MANET node consensus

Secure GPS

Non-existent

Flooding-Resilient Broadcast Authentication for VANETs

Hsu-Chun Hsiao, Ahren Studer, Chen Chen, Adrian Perrig Carnegie Mellon University

Fan Bai, Bhargav Bellur, Aravind Lyer General Motors

�

Vehicular Ad Hoc Network (VANET)

!  Each vehicle possesses an On Board Unit (OBU) " Broadcast information for safety and convenience


Obstacle ahead

Obstacle ahead

Location, Speed

Location, Speed

Broadcast Signatures

! Secure wireless communications

! IEEE 1609.2 VANET security standard " Digitally signs every message using ECDSA algorithm

G at (x,y) G at (x’,y’)

G at (x,y)

G at (x’,y’)

1. Origin Authentication

2. Message Authentication

3. Non-repudiation

G at (x,y)

Flooding-Resilient Broadcast Authentication for VANETs �

�

Signature Flooding

!  Expensive verification "  22ms to verify ECDSA signature on 400MHz processor

!  Many messages may arrive in a short time period " Every vehicle broadcasts location every 100ms

Signature flooding severely limits effectiveness of VANET applications.


Signature-Flooding-

•  Expensive-verifica5on-–  22-ms-to-verify-ECDSA-signature-----on-400MHz-processor-

•  Many-messages-may-arrive-in-a-short-5me-period-–  Every-vehicle-broadcasts-loca5on-every-100ms-–  Verify-50-neighbors’-loca5on-=-1100%-processing-cycle--

⇒ Severely'limits'effec.veness'of'VANET'applica.ons'

4

Can we reduce overhead of VANET verification?


Outline

!  Background and Motivation

!  Entropy-aware authentication

!  Flooding-resilient schemes

" FastAuth: single-hop periodic messages

" SelAuth: multi-hop messages

!  Conclusion

�

Entropy-Aware Authentication

Scheme’s overhead should match the entropy of broadcast messages.

! Fast Authentication (FastAuth) --- exploits predictability of future messages "  Replaces expensive ECDSA sigs

! Selective Authentication (SelAuth) --- selective verification before forwarding "  Avoid checking sigs with high certainty of validity


Cryptographic Primitives

!  One-Time Signature (OTS) " To sign 1-bit messages m " Two key pairs: {pk0, sk0} and {pk1, sk1} (pk=H(sk))

!  Merkle Tree Signature " To sign 2-bit messages " v0=00, ……, v3=11

" Sig for v2 is {h0-1, h3, r2}


h0 h1 h2 h3

h0!1 h2!3

PK h0 = H(v0||r0)h1 = H(v1||r1)h2 = H(v2||r2)h3 = H(v3||r3)h0!1 = H(h0||h1)h2!3 = H(h2||h3)PK = H(h0!1||h2!3)

Figure 1: Example of a Merkle signature tree. The signature ofm= v1 is {h2!3,h0,r1}.

1, then S= sk1. 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 thispaper, we use the term hash to represent the process as well as theoutput of such a one-way function. Signing an x-bit message can beaccomplished by signing each of these x bits separately, resultingin 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 messagevalues using a Merkle hash tree, as shown in Fig. 1. The hash treeroot 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 itschildren. After constructing this Merkle hash tree, the signer canobtain a signature as follows: the signature of a message vx con-sists of the corresponding random value rx and all off-path verticesfrom the leaf node to the root. Off-path vertices are the siblingsto the ancestors of hx. Merkle signatures provide non-repudiationbecause of the computational infeasibility of finding another mes-sage with the same off-path values. Fig. 1 illustrates the Merklehash tree construction representing an OTS to sign a 2-bit mes-sage, which has four possible values: v0 = 00, v1 = 01, v2 = 10,and v3 = 11. r0,r1,r2,r3 are random values, and the arrows indi-cate inputs to the hash function H. Hence the signature of m = v2is S = {h0!1,h3,r2}. To validate this signature, the receiver re-computes the root of the hash tree from the received signature Sand the message m. Then the receiver verifies whether the rootequals PK, announced previously by the signer. In this paper, weuse this Merkle signature scheme as a cryptographic primitive toconstruct 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 extremedesigns in broadcast authentication: OTS enables fast verificationwith expanded signatures, whereas ECDSA signatures are short butrequire long verification time. Hence, the challenge is to enable fastauthentication with short signatures.

3. PROBLEM DEFINITIONOur 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 signa-ture verification requests overwhelm the receiver’s computationalresources. We consider signature-based broadcast authenticationschemes that guarantee message authenticity and non-repudiation.Threat Model. We consider signature flooding caused by “flashcrowds” [16] (i.e., a large number of benign vehicles broadcastingvalid signatures within the victim’s radio range) and by one or more

Per-signature overhead ECDSA-256 OTSGeneration 7 ms 320µsVerification 22 ms 160µsPublic key size 256 bits 320 hashes (1 hash)Signature size 512 bits 160 hashes (160 hashes)

Table 1: Signature generation and verification time reportedin VAST [37], assuming signing the SHA-1 hash of a message.Numbers in parentheses represent the overheads of the Merklesignature scheme, where the size of one hash is 160 bits in caseof the SHA-1 hash function.

colluding attackers sending invalid signatures. We do not considerattackers flooding other vehicles with a high volume of valid signa-tures since the receivers can quickly identify the attackers and thenblacklist them. For a given authentication scheme, the attackersmay also trigger unnecessary message verification by performingscheme-specific actions. A vehicle under signature flooding maybe unable to verify every received signature before the message’sdeadline due to limited computational resources. Jamming attackscan also prevent VANET participants from communicating but canbe addressed by jamming defenses [7, 23].Desired properties. VANET broadcast authentication has two de-sired properties: non-repudiation and timely verification. With thenon-repudiation property, the recipient can prove to a third partywho is accountable for creating a message. Non-repudiation alsoimplies authentication, such that the recipient can identify the senderand detect malicious injection or manipulation of packets. Timelysignature verification is required as well because each VANETmes-sage has an expiration time (or deadline) by which it should be ver-ified. Single-hop applications often have a shorter deadline thanmulti-hop applications.

4. FAST AUTHENTICATION (FastAuth)This section presents FastAuth, an efficient One-Time Signature

(OTS) scheme to authenticate beacon messages. The novelty inFastAuth is the design of a Chained Huffman Hash Tree (CHT),which leverages the predictability in vehicle mobility to generatesmall signatures.As introduced in Section 2.1, a VANET-enabled vehicle broad-

casts beacon messages at a rate of 10Hz to inform nearby vehiclesof its position and velocity, enabling safety applications to alertdrivers of potential accidents. Every beacon has to be verified uponits reception because the beacon may contain decisive and urgentsafety information. However, the current VANET signature stan-dard [15] (i.e., signing every beacon using ECDSA) is computa-tionally expensive, whereas conventional OTS enables instant veri-fication with increased communication overhead. Motivated by thisunique challenge, the goal of FastAuth is to achieve fast authenti-cation with short signatures.

4.1 Insights to Generate Short OTS SignaturesThe intuition on how predictability in vehicle movements helps

shorten OTS signatures is as follows. We observe that the entropyof a beacon is relatively low from the sender’s point of view. Inother words, the sender can predict what will be sent in subsequentbeacons with high probability. For example, the timestamp can bepre-determined given that beacons are sent regularly (every 0.1 sec-ond), 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 degreesof freedom. Fortunately, a prediction is possible because of the

h0 h1 h2 h3

h0!1 h2!3

PK h0 = H(v0||r0)h1 = H(v1||r1)h2 = H(v2||r2)h3 = H(v3||r3)h0!1 = H(h0||h1)h2!3 = H(h2||h3)PK = H(h0!1||h2!3)

Figure 1: Example of a Merkle signature tree. The signature ofm= v1 is {h2!3,h0,r1}.

1, then S= sk1. 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 thispaper, we use the term hash to represent the process as well as theoutput of such a one-way function. Signing an x-bit message can beaccomplished by signing each of these x bits separately, resultingin 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 messagevalues using a Merkle hash tree, as shown in Fig. 1. The hash treeroot 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 itschildren. After constructing this Merkle hash tree, the signer canobtain a signature as follows: the signature of a message vx con-sists of the corresponding random value rx and all off-path verticesfrom the leaf node to the root. Off-path vertices are the siblingsto the ancestors of hx. Merkle signatures provide non-repudiationbecause of the computational infeasibility of finding another mes-sage with the same off-path values. Fig. 1 illustrates the Merklehash tree construction representing an OTS to sign a 2-bit mes-sage, which has four possible values: v0 = 00, v1 = 01, v2 = 10,and v3 = 11. r0,r1,r2,r3 are random values, and the arrows indi-cate inputs to the hash function H. Hence the signature of m = v2is S = {h0!1,h3,r2}. To validate this signature, the receiver re-computes the root of the hash tree from the received signature Sand the message m. Then the receiver verifies whether the rootequals PK, announced previously by the signer. In this paper, weuse this Merkle signature scheme as a cryptographic primitive toconstruct 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 extremedesigns in broadcast authentication: OTS enables fast verificationwith expanded signatures, whereas ECDSA signatures are short butrequire long verification time. Hence, the challenge is to enable fastauthentication with short signatures.

3. PROBLEM DEFINITIONOur 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 signa-ture verification requests overwhelm the receiver’s computationalresources. We consider signature-based broadcast authenticationschemes that guarantee message authenticity and non-repudiation.Threat Model. We consider signature flooding caused by “flashcrowds” [16] (i.e., a large number of benign vehicles broadcastingvalid signatures within the victim’s radio range) and by one or more

Per-signature overhead ECDSA-256 OTSGeneration 7 ms 320µsVerification 22 ms 160µsPublic key size 256 bits 320 hashes (1 hash)Signature size 512 bits 160 hashes (160 hashes)

Table 1: Signature generation and verification time reportedin VAST [37], assuming signing the SHA-1 hash of a message.Numbers in parentheses represent the overheads of the Merklesignature scheme, where the size of one hash is 160 bits in caseof the SHA-1 hash function.

colluding attackers sending invalid signatures. We do not considerattackers flooding other vehicles with a high volume of valid signa-tures since the receivers can quickly identify the attackers and thenblacklist them. For a given authentication scheme, the attackersmay also trigger unnecessary message verification by performingscheme-specific actions. A vehicle under signature flooding maybe unable to verify every received signature before the message’sdeadline due to limited computational resources. Jamming attackscan also prevent VANET participants from communicating but canbe addressed by jamming defenses [7, 23].Desired properties. VANET broadcast authentication has two de-sired properties: non-repudiation and timely verification. With thenon-repudiation property, the recipient can prove to a third partywho is accountable for creating a message. Non-repudiation alsoimplies authentication, such that the recipient can identify the senderand detect malicious injection or manipulation of packets. Timelysignature verification is required as well because each VANETmes-sage has an expiration time (or deadline) by which it should be ver-ified. Single-hop applications often have a shorter deadline thanmulti-hop applications.

4. FAST AUTHENTICATION (FastAuth)This section presents FastAuth, an efficient One-Time Signature

(OTS) scheme to authenticate beacon messages. The novelty inFastAuth is the design of a Chained Huffman Hash Tree (CHT),which leverages the predictability in vehicle mobility to generatesmall signatures.As introduced in Section 2.1, a VANET-enabled vehicle broad-

casts beacon messages at a rate of 10Hz to inform nearby vehiclesof its position and velocity, enabling safety applications to alertdrivers of potential accidents. Every beacon has to be verified uponits reception because the beacon may contain decisive and urgentsafety information. However, the current VANET signature stan-dard [15] (i.e., signing every beacon using ECDSA) is computa-tionally expensive, whereas conventional OTS enables instant veri-fication with increased communication overhead. Motivated by thisunique challenge, the goal of FastAuth is to achieve fast authenti-cation with short signatures.

4.1 Insights to Generate Short OTS SignaturesThe intuition on how predictability in vehicle movements helps

shorten OTS signatures is as follows. We observe that the entropyof a beacon is relatively low from the sender’s point of view. Inother words, the sender can predict what will be sent in subsequentbeacons with high probability. For example, the timestamp can bepre-determined given that beacons are sent regularly (every 0.1 sec-ond), 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 degreesof freedom. Fortunately, a prediction is possible because of the

FastAuth: First Attempt

L1@T1 L2@T2 L3@T3 1. Predict location

FastAuth:-First-Acempt-Verifying-loca5on-updates-sent-at-10Hz-rate-•  Lightweight-hash-opera5on-(1us)-instead-of-expensive-ECDSA-verifica5on-(22ms)-

7

L0 L1 L2 L3

3. Broadcast ACK A1

P is signed & P = H(A1) so blue car indeed said L1

4. Verification

: Hash function H : public value : ACK of location Li : ECDSA signature

P Ai

Verify 22000x faster than Li Ai

A2 A1 P A3 2. Create verifiable ACK

Ai = H(Ai+1)


Location Uncertainty Loca5on-Uncertainty-

8

Ideal case: perfect prediction

A2 A1 A3 P Loc

Unfortunately… incorrect prediction requires re-prediction

P Loc

A1

P’ Loc’

A3’

Verification time : 1 us

: 22000 us Ai

Avg overhead >> 1 us

Challenge: commit all possible movements into ACKs

Avg overhead 1 us


! Challenge: commit all possible movements into ACKs

Location Predication

!  Sender predicts its own movements !  Narrow down possible movements for efficiency

" Laws of physics and road topology –  e.g., slower than 110mph cannot move > 5m per 0.1s

" Coarse-grained position

Flooding-Resilient Broadcast Authentication for VANETs ��

1.-Loca5on-Predic5on-

9

Possible Movement In 0.1s (Li+1 – Li)

Stay (DS)

Forward (DF)

Forward left (DL)

Forward right (DR)

…

… …

5m

•  Sender-predicts-it-own-movements--•  Narrow-down-possible-movements-for-efficiency-

–  Sender’s-speed-limits-•  e.g.,-slower-than-180km-or-112mile-per-hr--cannot-move->-5m-per-0.1s-

–  Sender’s-loca5on-measurement-accuracy-

following reasons: 1) The laws of physics and road topology re-strict the possible future locations. For example, a vehicle travelingslower 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 theroad rather than backward or sideway. 3) Due to the inherent posi-tioning inaccuracy introduced by positioning devices (e.g., 2 metersinaccuracy in commodity GPS devices), we can round a locationto a coarser-grained numerical representation to further reduce thenumber of candidate locations. For example, rounding location tometers only inflates the positioning inaccuracy from 2 meters to2.5 meters, which is still acceptable for safety applications. Con-sequently, a small number of positions will occur with high prob-ability and other positions are unlikely. Taking such a probabilitydistribution into account, we are able to construct a one-time sig-nature scheme using coding theory to shorten the signatures. Par-ticularly, FastAuth adopts Huffman coding [14], an encoding algo-rithm minimizing the expected length of encoded messages. Thatis, FastAuth explores a new trade-off point in the design space ofbroadcast authentication: the size of a FastAuth signature dependson how well the signer can predict its own message content.

4.2 Protocol OverviewAt a high level, each vehicle in FastAuth divides its timeline into

a sequence of prediction intervals. In each prediction interval, avehicle performs three steps: Beacon Prediction, Key Pair Con-struction, and Signature Broadcast. We provide an overview ofthese 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 thedistance vector between two consecutive beacons based on infor-mation of the past trajectory. For example, in Fig. 2(a), the vehiclepredicts that it will move forward (Df ) 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 publickey and one interval worth of OTS private keys. We propose achained Huffman hash tree (CHT), which ties these pre-computedkeys together in a fashion that minimizes the size of signatures andgenerates a single public key, as shown in Fig. 2(b).Signature Broadcast (Sec. 4.5) After beacon prediction and keyconstruction, a vehicle signs its OTS public key using ECDSA sig-natures and then broadcasts this ECDSA signed public key PKotsalong 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 Biwith this time and position information. Moreover, to maintain ahigh beacon update frequency during severe packet loss, we inte-grate Forward Error Correction [25, 33] into FastAuth to recoverlost beacons.

4.3 Beacon PredictionSince position is the main source of uncertainty in beacon mes-

sage contents, we discuss how the beacon sender can predict andencode its own future positions. Specifically, FastAuth requires thesender to model the probability distribution of themovement (or thedistance vector) between every two consecutive beacons, Bi!1 andBi. The output of this step is a prediction table Gi in which eachentry represents one possible movement between time Ti!1 and Tiand the probability of making this movement.Representing positions using a local coordinate. To compressthe amount of information, the sender expresses its future positionsusing a coarse-grained local coordinate. The origin of this localcoordinate is placed at the beginning position of the current predic-tion interval (i.e., L0). Then every future position Li in this interval

Prediction tablemovementDf = (1,0)Dl = (1,1)Dr = (1,!1)

probability0.50.250.25past trajectory

DlDf

Dr

!Δy!Δx

(a) Determine the prediction table.

h1,l h1,r

h1, f

h2,l h2,r

h2, f

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

Rt,d are 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

h1,l

h1,l

h1,r

h1,r

h1,r

h1, f

h1, f

h1, f

h2,l

h2,l

h2,l

h2,r

h2,r

h2,r

h2, f

h2, f

h2, f

PKots

Broadcast B0 at T0. In B0, m= {T0,L0,PKots,!Δx,!Δy}, S= ECDSA(m)

Broadcast B1 at T1. In B1, m= {T1,L1,R1,r}, S= !

Broadcast B2 at T2. In B2, m= {T2,L2,R2, f }, S= !

Dr

Df

(c) Beacon broadcast. To verify B2, the receiver reconstructs thetree root for T1 using the information in B1 and B2, and checks ifthe root matches the one signed in B1.

Figure 2: Example of FastAuth.

can be approximated by

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

•!Δx is a vector parallel with the instant velocity at T0,•!Δy is perpendicular to!Δx,• xi and yi are rounded to integers,• and the scalar of each vector (i.e., |!Δx| and |!Δy|) is chosen by thevehicle 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 representationwould contain more noise than useful information. Hence, eachmovement from time Ti!1 to Ti

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

can be encoded as a pair of integers (xi! xi!1,yi! yi!1).Constructing prediction tables. A prediction table Gi maps amovementDi in the new coordinate to a probability of making sucha movement. For example in Fig. 2(a), an entry [(1,1),0.25] in theprediction table means that the probability of moving one unit along

Verifiable ACK Construction 2.-Verifiable-ACK-Construc5on-Possible Movement

(Li – Li-1)

Stay (DS) Forward (DF)

Forward left (DL) Forward right (DR)

DS DF DL DR

L0

DS,1 DF,1 DL,1 DR,1

P

10

: Hash function H : public value : ACK of location Li : ECDSA signature

DS,2 DF,2 DL,2 DR,2

Commit movements using Merkle Hash Tree

H(DR)

H(H(DL)||H(DR))


Signed Location Broadcast

DL,2 A20

A3 A211

3.-Signed-Loca5on-Broadcast-

P L0

DS,2 DF,2 DL,2 DR,2

L0

DS,1 DF,1 DL,1 DR,1

P

DF,1 A11

A2 A100

DF,1

A100

A11

A2

DL,2

A211

A20

A3

11

Movement committed to ACK tree => No re-prediction needed! Flooding-Resilient Broadcast Authentication for VANETs ��

Verification


Further Improvement

!  Verification overhead reduced " Expensive ECDSA => lightweight Merkle tree sigs

!  How to reduce the communication overhead? " Location predictability


Further-Improvement-

• We-have-reduced-verifica5on-overhead-–  Expensive-sig-verifica5on-=>-lightweight-hash-ops-

•  Can-we-also-reduce-comm.-overhead?-–  Yes.-Not-fully-leveraged-loca5on-predictability-yet-

Possible Movement (Li – Li-1) Stay (Ds)

Forward (Df)

Forward left (Dl)

Forward right (Dr)

Probability

?

?

?

?

13

Huffman and Merkle Tree Huffman-Tree-+-Hash-Tree-Possible Movement

(Li – Li-1) Stay (DS)

Forward (DF) Forward left (DL)

Forward right (DR)

14

Probability

PS

PF

PL

PR

DS

DF

DL

DR

DS DF DL DR

Re-arrange based on probability (Huffman encoding)


Dealing with Packet Loss

!  Trade-offs " Pros: instant verification, low comp. & comm. Overhead

" Cons: low update frequency

!  Low update frequency due to verification dependency " Missing messages prevent verification of subsequent

msgs

!  Reed-Solomon Coding (RS(w,u)) " Beacon Bi " u out of w succeeding beacons (Bi+1, Bi+2, …, Bi+w)


Public Key Rebinding

!  Public key is broadcasted at the beginning of the predication period

!  Every IE beacons, vehicle signs its beacon by ECDSA in addition to OTS


4.-Verifica5on-

12

Sender

Receiver

A100

DF,1

Compute P’ Verify if P = P’ L1 = L0 + DF

DL,2

A211

A20

A2’ A3

Compute A2’ Verify if A2’ = A2 L2 = L1 + DL

DL,2 A20

A3 A211

DF,1 A11

A2 A100

P L0

Verify ECDSA sig

P

L0

A11

P’ A2

P’ = H(H(A100||H(DF,1))||A11||A2)

Evaluation Settings

!  Data collection "  4 traces, each by driving along a 2-mile path for 2 hours

"  default prediction model "  use the first half of each trace as the training data and

evaluate FastAuth using the second half of trace


behavior persists, y should block the identified malicious forwarderby 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 toretain high throughput by taking advantage of these bad nodes, i.e.,by permitting them to forward packets. To achieve this, SelAuthdelays the verification of messages from malicious nodes. Delayedsignature verification can help because a vehicle is likely to havereceived duplicated messages due to the broadcast nature. De-layed verification can address the case where a vehicle has onlyone neighbor but the neighbor is malicious. Rather than droppingall packets forwarded by the malicious neighbor and making itselfget disconnected from the network, the vehicle may want to sacri-fice some security for availability.

5.4 Preliminary AnalysisA full simulation of SelAuth can be found in Section 7. In this

analysis, we consider a simple line model where vehicles are placedat location 0, l, 2l, · · · . The communication range is ld, so thereare d next-hop vehicles that forward messages ahead. The initialverification probability is p for all vehicles. The attacker sends ninvalid signatures during each time interval. Hence the probabilitythat a receiver of the n invalid signatures does not catch any ofthem (and thus forward all of the messages) is α = (1! p)n. Weinvestigate the case with an attacker at the origin. Note that SelAuthalways checks the first message from a new neighbor, and thus theattacker’s optimal strategy is to behave at the beginning (t = 0) bysending 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 awayfrom 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!hi=0#

t!h!i2 $) = nα1/4(t!h)(t+h+1) (3)

where α(t!h)h represents the probability that none of the vehiclesin the first h hops check the attacker’s packets sent in the firstt ! h intervals. α∑

t!hi=0#

t!h!i2 $ expresses the probability that the h-

hop vehicles receive no pushback from other vehicles. This can berephrased as “vehicles between h+ 1 and # t!h!i+12 $ hops fail tocheck any bad packets sent during the first # t!h!i+12 $ 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), asthe 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 canonly cause local attacks congesting the neighbors’ wireless chan-nel within one-hop communication range, in contrast to large-scaleDoS attacks that affect communication multiple hops away.

6. EVALUATION: Fast AuthenticationTo evaluate FastAuth, we consider a sender vehicle sending bea-

cons and a receiver vehicle receiving these beacons with probabil-ity 1! ε , where ε is the packet loss rate. The sender moves alongreal traffic traces collected by General Motors. The GM datasetincludes four traces and each of them was generated by a vehicledriving along a 2-mile path for about 2 hours. Though the trajectoryis pre-defined for the purpose of simulation, the sender can onlyleverage its past trajectory to predict future location. We simulate

parameter sample valueECDSA generation time 7msECDSA verification time 22mshash operation time 1µs

beacon size 378 byteshash size 20 bytesRS 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.

33

5

555

66

6

7

7

777

7

88

8

8

88

99

99

!Δx

!Δy

2 35

6

6

7

7

8

8

9

9

9

11

1111

12

13

141414

14

1414

1414

!Δx

!Δy

(a) default (b) trained

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

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

6.1 Evaluation SettingsTable 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. Inpractice, car manufacturers or VANET application providers canapply advanced physics models and well-analyzed traffic statisticsto 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 movementsmade by a vehicle in one beacon interval (i.e., 0.1 second), giventhat 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 ofcommodity GPS systems. The first method considers the worst casewhere only a default prediction model is available, and allocatesthe probabilities using the principle of “the nearer the distance,the larger the probability”, as shown in Fig. 4(a). The other isto use the first half of each trace as the training data and evaluateFastAuth using the second half of trace. For each movement inthe prediction table, its probability is determined by how often thevehicle made such a movement in the training data. This predictiontable is shown in Fig. 4(b).

6.2 Simulation ResultsIn 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 ratioof FastAuth to ECDSA. Table 2 summarizes the parameters usedin the evaluation. We evaluate FastAuth using the following met-rics: 1) sender/receiver computational overhead, 2) communicationoverhead (which reflects the accuracy of our location predictionmodel), and 3) average beacon update frequency (defined as thenumber of beacons successfully verified per second).Fig. 5 shows the effectiveness of using trained and default ta-

Simulation—Comm. Overhead

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 c

omm

unica

tion

prediction interval (I)

trained, IE = 20default, IE = 20trained, IE = 50default, IE = 50

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

bles. Both models enable FastAuth to save more than a half of thebandwidth 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 usingthe one-hour past trajectory without context is only a rough estima-tor. Hence, in the following we evaluate FastAuth using the defaultprediction table.Fig. 6 shows the performance of FastAuth with various RS cod-

ing settings and rebinding intervals. Compared to ECDSA, signa-ture generation in FastAuth (i.e., the sender’s computation) is 20times faster and verification (i.e., the receiver’s computation) is 50times faster. Also the communication ratio is only 20% – 40%.With a smaller rebinding interval (IE = 20), the beacon update fre-quency is higher than using ECDSA because of the RS error cor-rection coding. However, a small IE increases communication andthe sender’s computational overhead. Also, more redundancy inthe error correction code helps improve the update frequency at thecost of bandwidth consumption.Fig. 7 shows the impact of the packet loss rate ε on the bea-

con update frequency and the sender’s computational overhead; theother two metrics are constant with respect to ε . As ε increases,the ratio of the average beacon update frequency drops and the re-ceiver’s computational overhead increases. The result shows thatFastAuth 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 com-

putational overhead for both the sender and receiver. Specifically,our signature verification is 50 times faster and signature generationis 20 times faster than it using ECDSA. The communication over-head is reduced to 60% as well. Furthermore, FastAuth can achievethe same level of update frequency as ECDSA with the help of theerror correction and key rebinding mechanisms.

7. EVALUATION: Selective AuthenticationTo evaluate SelAuth, we compare the performance of five sig-

nature verification schemes in multi-hop networks. We simulatethese schemes using NS-2 [26] with the IEEE 802.11p MAC layerand Nakagami physical layer model [6], and synthesize vehicles’traces on a realistic road topology using SUMO [17]. We evaluatethe performance of five signature verification schemes in multi-hopnetworks. 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 s

ende

r com

p. RS(5,2), IE = 20RS(3,2), IE = 20RS(5,2), IE = 50RS(3,2), IE = 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 r

eceiv

er co

mp.

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 c

omm

.

0.25

0.5

0.75

1

1.25

1.5

0 10 20 30 40 50 60 70 80 90 100ratio

of u

pdat

e fre

quen

cy


Figure 6: Evaluation based on real traffic traces.

scheme probabilistic per forwarder probabilisticverification probability pushback

SelAuth ! ! !

Verify-AllFI ! !

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-forwarderverification probability without pushback warnings, while Push-back only (PB) provides pushback warnings without a per-forwarderverification probability (i.e., a shared verification probability forevery neighbor). In Adaptive Message Authentication (AA), neitherpushback nor forwarder identification is supported [34, 38].

7.1 Evaluation SettingsWe 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, 100static vehicles are placed every 30 meters in a line and an attackermoves at a constant speed of 10m/s along the line. The simula-tion time is 50 seconds. The real-world scenario uses a road topol-ogy reconstructed from a 1km"1km downtown area of Manhattan.We simulate 336 vehicles with random traffic patterns generated bySUMO (average speed is 10m/s), and one attacker travels along amanually selected path to circle within the area. The simulation


Fig. 1 Communication Overhead compared to ECDSA

Simulation—Comp. Overhead

0.3

0.4

0.5

0.6

0.7

0.8

0 10 20 30 40 50 60 70 80 90 100

ratio o

f com

munic

ation










0

0.1

0.2

0.3

0.4

0.5

0 10 20 30 40 50 60 70 80 90 100

ratio o

f sender

com

p.

RS(5,2), IE = 20RS(3,2), IE = 20RS(5,2), IE = 50RS(3,2), IE = 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 o

f re

ceiv

er

com

p.

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 o

f com

m.

0.25

0.5

0.75

1

1.25

1.5

0 10 20 30 40 50 60 70 80 90 100ratio o

f update

fre

quency




SelAuth ! ! !

Verify-AllFI ! !

PB ! !

AA [34,38] !





0.3

0.4

0.5

0.6

0.7

0.8

0 10 20 30 40 50 60 70 80 90 100ra

tio

of com

munic

ation










0

0.1

0.2

0.3

0.4

0.5

0 10 20 30 40 50 60 70 80 90 100

ratio

of sende

r com

p.

RS(5,2), IE = 20RS(3,2), IE = 20RS(5,2), IE = 50RS(3,2), IE = 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 o

f re

ceiv

er

com

p.

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 o

f com

m.

0.25

0.5

0.75

1

1.25

1.5

0 10 20 30 40 50 60 70 80 90 100ratio

of

up

da

te fre

qu

ency




SelAuth ! ! !

Verify-AllFI ! !

PB ! !

AA [34,38] !





Outline

!  Background and Motivation

!  Entropy-aware authentication

!  Flooding-resilient schemes

" FastAuth: single-hop periodic messages

" SelAuth: multi-hop messages

!  Conclusion

SelAuth Overview

!  Promptly isolates malicious parties !  Quickly adjusts Pxy s.t.

" Pxy = Pr{y verifies signatures forwarded by x}

" Pxy goes to 0 for benign x and goes to 1 for malicious x


SelAuth-Overview-•  SelAuth-is-about--

–  Finds-balance-between-Verify?on?Demand'&-Verify?All'–  Promptly-isolates-malicious-par5es-

•  Invalid-sigs-cannot-spread-out-consuming-comm.-bandwidth-–  Quickly-adjusts-Pxy-s.t.--

•  Pxy-=-Pr[y-verifies-signatures-forwarded-by-x]-•  Pxy--0-for-benign-x-&-Pxy--1-for-malicious-x--

20

Verify SA Relay SA Send invalid sig SA

Relay SA

A Y G B

1.  Increase PYG 2.  Pushback [SA is bad] 1.  Increase PAY

2.  Pushback [SA is bad]

1.  Increase PGB 2.  Pushback [SA is bad]

…… PAY = 1 PYG 0 PGB 0

Fast Isolation Fast-Isola5on-of-Mobile-Acacker-

21

NS-2 simulation

Pro

paga

tion

of in

valid

sig

natu

res

(hop

s)

One verification prob. for all neighbors 2

4

6

8

0 10 20 30 40 50 60 70 80 90 100time (sec) One verification prob. for all neighbors

+ Pushback warning 2

4

6

8

0 10 20 30 40 50 60 70 80 90 100time (sec) Per-neighbor verification prob.

2

4

6

8

0 10 20 30 40 50 60 70 80 90 100time (sec)

SelAuth Per-neighbor verification prob.

+ Pushback warning 2

4

6

8

0 10 20 30 40 50 60 70 80 90 100time (sec)

Verify every signature with p = 1 2

4

6

8

0 10 20 30 40 50 60 70 80 90 100time (sec)


SelAuth: Low Overhead

SelAuth:-Low-Overhead-

NS-2 simulation: 336 vehicles in 1kmx1km downtown Manhattan

0 20000 40000 60000 80000

100000 120000 140000 160000 180000 200000

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

ove

rall

com

pu

tatio

n (

# o

f ve

rific

atio

n)

initial probability

200 400 600 800

1000 1200 1400 1600 1800 2000 2200 2400

0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1

ove

rall

com

mu

nic

atio

n (

KB

)

initial probability

SelAuthVerify-All

one-prob-for-all-neighbors

22 Flooding-Resilient Broadcast Authentication for VANETs ��

Conclusion

!  Flooding-resilient broadcast signature " Required for timely verification of safety messages

" Unachievable in current standard even in benign settings

!  Entropy-aware authentication to mitigate flooding " FastAuth: instant verification for on-hop messages

" SelAuth: selective authentication for multi-hop messages


Questions?

2012/04/05�

Click to edit Master subtitle style

Providing VANET Security Through

Active Position Detection

Gongjun Yan, Stephan Olariu, Michele C. Weigle

Department of Computer Science, Old Dominion

University

Introduction

Assumption:

Majority (~85%) of vehicles are honest and behave

responsibly.

Main contribution:

Detect and isolate malicious cars using GPS and

radar-provided data.

Key Points:

Achieve local security

– On-board radar

Extend to global security

– Preset position based groups and dynamic challenges

Measured results using simulations

Related work

Cryptography based methods

Significant overhead using PKI

Using hard thresholds to detect false locations

Not flexible because of uncertainties in VANETs

Measure signal strength

Could be forged, bounced off another car, etc..

–

VANET Applications

Two categories of VANET applications:

Non-Position Related

– Online payment services

– Online shopping

Position Related

– Traffic condition reports

– Collision avoidance

– Emergency alert

– Cooperative driving

– Resource availability

Position Related Attacks

Dropping packets

Accidents

Modifying existing or inserting bogus packets

Traffic Jam Illusion

Replaying packets

Pretend to be at a fake position

Well-known, dangerous attack:

Sybil Attack

– Forge multiple identities to create illusions

o Could trigger collision warning

–

Proposed Solution

“Seeing is Believing”

“Hear”: Report of GPS coordinates

“See”: on-board radar

– Reduce fender-benders, advanced cruise control

– Limited by short range

Compare the two:

– Corroborate real positions

– Isolate malicious vehicles

Result: Achieve local security in a cell

Cells

Preset position-based cell

Within cell:

– Vehicles can directly communicate

– Verify position of specific vehicle in cell

Outside of cell:

– Radar not strong enough

– Use radar in oncoming traffic to challenge and confirm

Acquired Data

Each vehicle has three types of data:– Local radar-detected data from itself

– Remote radar detected data from oncoming traffic

– Agreed-upon data from cell neighbors

Achieve global security:– Apply cosine similarity, using defined thresholds

– Construct history of vehicle movement

o Help determine if newly received data is valid

Cell Positioning

Creating the preset position-based cell:

Compare GPS coords with pre-set maps

Broadcast GPS coords to other cars

– Creates rough topology

Cars in overlap act as routers, notify cell leaders

Cell Leaders

Responsibilities:

Verifies GPS position of all vehicles in cell

Aggregates the data

Broadcasts it intra-cell

– Other cars now know of all cars in their cell

Sends it inter-cell

Picking a Cell Leader

Closest to Center

Approaching current cell leader

Cell Routers

Routers

2 per cell – forward and backward

Communicate aggregate data

Picked by proximity to overlap region and traveling

direction

Leader and Routers are watched by cell

members and neighbors

Silence if all is good

Send out protest packets otherwise

– Leader put into question table

– Majority vote determines if leader is malicious --> distrust

table

Radar Detection

Radar gives us:

Relative velocity

Angle

Position

Two events trigger radar detection:

Reactive: Timeout threshold

Proactive: Randomly during communication

Both combine to give us Active Position Detection

Position Verification

Active Position Verification

Need Overlap of GPS and Radar with tolerance

– Accept/Reject

Global Security Attacks

Global Security:

An adversary can launch three types of attacks:

– Sybil attack

– Continually lying about position

– Occasionally lying about position

To detect latter two: Message routing

Preventing Sybil Attacks

Vehicle claims to be several vehicles at the same

time or in succession.

Very detrimental:

o Example: 100s of vehicles worth of network

overhead

Even more dangerous: Sybil + position attack

Possible when:

– Local vehicle has no direct physical knowledge of remote

car

– In other words, only has abstract data.

Solution proposed:

– Using weighted data:

o When radar is working: highest weight

o When radar isn’t working: neighbor data has

highest weight

Map History

Purpose:

Classify new data as “real” or “fake”

Basic idea:

Any vehicle without history is highly suspect

Build database of history on local car

Don’t trust new cars with router or leader position

Once it behaves for quite a while and falls within

probably speeds and distances travelled, trust it

Isolating Malicious Cars

Isolating malicious vehicles using tables:

Trust, Question, Distrust Tables

Procedure:

1. New vehicle broadcasts “HELLO”

2. Cell Leader responds with IDs:

– It’s own, routers’, cell members;

3. Members put new car in question table

– Builds history

4. If it behaves, members promote to trust table

5. if it misbehaves, it gets put into distrust table

Simulation and Testing

Parameters: Two direction, 3km highway with two lanes in each

direction

Cell radius = 100m

Traffic arrival rate = 1600 cars/h

Mean velocity = 33.3 m/s

Transmission radius = 100m

16 malicious cars, a single observer, varying number of other cars

Procedure: Observer enters road

Initiates request to find malicious vehicles

Ends when it reaches 3 km traveled

Results of Simulation

Metric: Time required to detect 16 adversaries

Varying Transmission RangeVarying Total Car Number

Future Work

Future work:

Effective Size of Map History

Impersonating a long-standing honest vehicle that

just let the highway

Colluding groups of malicious vehicles

Questions?Questions?

2012/04/05

Date post:	07-Feb-2018
Category:	Documents
Upload:	dohuong
View:	219 times
Download:	2 times

VANET Security and Privacy - Carnegie Mellon...

Documents