vanet security and privacy - carnegie mellon...
TRANSCRIPT
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
Flooding-Resilient Broadcast Authentication for VANETs
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.
Flooding-Resilient Broadcast Authentication for VANETs
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?
Flooding-Resilient Broadcast Authentication for VANETs �
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
Flooding-Resilient Broadcast Authentication for VANETs
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}
Flooding-Resilient Broadcast Authentication for VANETs
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)
Flooding-Resilient Broadcast Authentication for VANETs
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
Flooding-Resilient Broadcast Authentication for VANETs �
! 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))
Flooding-Resilient Broadcast Authentication for VANETs ��
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
Flooding-Resilient Broadcast Authentication for VANETs ��
Further Improvement
! Verification overhead reduced " Expensive ECDSA => lightweight Merkle tree sigs
! How to reduce the communication overhead? " Location predictability
Flooding-Resilient Broadcast Authentication for VANETs ��
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)
Flooding-Resilient Broadcast Authentication for VANETs ��
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)
Flooding-Resilient Broadcast Authentication for VANETs ��
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
Flooding-Resilient Broadcast Authentication for VANETs �
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
Flooding-Resilient Broadcast Authentication for VANETs �
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
prediction interval (I)
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
Flooding-Resilient Broadcast Authentication for VANETs ��
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
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 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
prediction interval (I)
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
Flooding-Resilient Broadcast Authentication for VANETs ��
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
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 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
prediction interval (I)
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
Flooding-Resilient Broadcast Authentication for VANETs ��
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
Flooding-Resilient Broadcast Authentication for VANETs ��
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)
Flooding-Resilient Broadcast Authentication for VANETs ��
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
Flooding-Resilient Broadcast Authentication for VANETs ��
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