Flooding-Resilient Broadcast Authen5ca5on for VANETs - PowerPoint PPT Presentation

Flooding-­‑Resilient ¡Broadcast ¡ Authen5ca5on ¡for ¡VANETs ¡ Hsu-­‑Chun ¡Hsiao, ¡Ahren ¡Studer, ¡Chen ¡Chen, ¡Adrian ¡Perrig ¡ Carnegie ¡Mellon ¡University ¡ Fan ¡Bai, ¡Bhargav ¡Bellur, ¡Aravind ¡Iyer ¡ General ¡Motors ¡

Vehicular ¡Ad ¡Hoc ¡Network ¡(VANET) ¡ • Each ¡vehicle ¡possesses ¡an ¡On ¡Board ¡Unit ¡(OBU) ¡ – Broadcasts ¡info ¡for ¡safety ¡& ¡convenience ¡ My Location My Speed Obstacle Ahead Obstacle Ahead Obstacle Ahead 2

Broadcast ¡Signatures ¡ • Secure ¡wireless ¡communica5on ¡ 1. Origin authentication G at (x’, y’) 2. Message authentication 3. Non-repudiation G at (x, y) G at (x’, y’) G claimed G at (x, y) G at (x, y) • IEEE ¡1609.2 ¡VANET ¡security ¡standard ¡ – Digitally ¡signs ¡every ¡message ¡using ¡ECDSA ¡algorithm ¡ 3

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 ¡ Can we reduce overhead of VANET verification? 4

Outline ¡ • Introduc5on ¡ • Core ¡idea: ¡entropy-­‑aware ¡authen5ca5on ¡ • Proposed ¡flooding-­‑resilient ¡schemes ¡ – FastAuth ¡secures ¡single-­‑hop ¡periodic ¡messages ¡ – SelAuth ¡secures ¡mul5-­‑hop ¡messages ¡ • Related ¡Work ¡ • Conclusion ¡ 5

Entropy-­‑Aware ¡Authen5ca5on ¡ Scheme’s ¡overhead ¡should ¡match ¡the ¡ ¡ entropy ¡of ¡broadcast ¡messages ¡ • FastAuth ¡– ¡exploits ¡predictability ¡of ¡future ¡messages ¡ – Replaces ¡expensive ¡ECDSA ¡sigs ¡with ¡efficient ¡hash ¡ops ¡ • SelAuth ¡– ¡selec5ve ¡verifica5on ¡before ¡forwarding ¡ – Avoid ¡checking ¡sigs ¡with ¡high ¡certainty ¡of ¡validity ¡ ¡ 6

FastAuth: ¡First ¡Acempt ¡ Verifying ¡loca5on ¡updates ¡sent ¡at ¡10Hz ¡rate ¡ • Lightweight ¡hash ¡opera5on ¡(1us) ¡instead ¡of ¡expensive ¡ECDSA ¡verifica5on ¡(22ms) ¡ : Hash function H L 1 @T 1 L 2 @T 2 L 3 @T 3 1. Predict location P : public value : ACK of location Li Ai L 0 : ECDSA signature 2. Create A 3 P A 1 A 2 L 1 verifiable ACK L 2 A i = H(A i+1 ) L 3 A 1 3. Broadcast ACK P is signed & P = H(A 1 ) 4. Verification so blue car indeed said L 1 Verify 22000x faster than Ai Li 7

Loca5on ¡Uncertainty ¡ Ideal case: perfect prediction Verification time : 1 us Ai Avg overhead  1 us : 22000 us P A 1 A 2 A 3 Loc Unfortunately… incorrect prediction requires re-prediction Avg overhead >> 1 us A 3 ’ P’ A 1 P Loc’ Loc Challenge: commit all possible movements into ACKs 8

1. ¡Loca5on ¡Predic5on ¡ • 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 ¡ Possible Movement In 0.1s ( L i+1 – L i ) 5m Stay (D S ) Forward (D F ) Forward left (D L ) Forward right (D R ) … … … 9

2. ¡Verifiable ¡ACK ¡Construc5on ¡ Possible Movement ( L i – L i-1 ) Stay (D S ) : Hash function H Forward (D F ) : public value Forward left (D L ) : ACK of location Li : ECDSA signature Forward right (D R ) L 0 Commit movements P using Merkle Hash Tree H(H(D L )||H(D R )) H(D R ) D S,1 D F,1 D L,1 D R,1 D S,2 D F,2 D S D F D L,2 D R,2 D L D R 10

3. ¡Signed ¡Loca5on ¡Broadcast ¡ L 0 A 2 A 3 P A 11 A 20 A 100 A 211 D F,1 D L,2 D S,1 D F,1 D L,1 D R,1 D S,2 D F,2 D L,2 D R,2 A 3 A 211 A 2 A 100 L 0 D L,2 A 20 P D F,1 A 11 Movement committed to ACK tree => No re-prediction needed! 11

4. ¡Verifica5on ¡ A 3 A 211 A 2 A 100 D L,2 A 20 L 0 Sender D F,1 A 11 P Compute P’ Compute A 2 ’ Verify if P = P’ Verify if A 2 ’ = A 2 Receiver Verify ECDSA sig L 1 = L 0 + D F L 2 = L 1 + D L P’ = H(H(A 100 ||H(D F,1 ))||A 11 ||A 2 ) L 0 P’ A 2 A 2 ’ A 3 P A 20 A 11 A 100 A 211 D L,2 D F,1 12

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 Probability ( L i – L i-1 ) Stay (Ds) ? Forward (Df) ? Forward left (Dl) ? Forward right (Dr) ? 13

Huffman ¡Tree ¡+ ¡Hash ¡Tree ¡ Possible Movement Probability ( L i – L i-1 ) Stay (D S ) P S Forward (D F ) P F Forward left (D L ) P L Forward right (D R ) P R Re-arrange based on probability (Huffman encoding) D F D L D S D F D L D R D S D R 14

Reduced ¡Communica5on ¡ L 0 P D F,2 D F,1 Df D L,2 D L,1 D S,2 D S,2 D R,2 D S,1 D R,1 L 0 Inaccurate probability model P D F,1 D S,2 ⇒ Larger sigs but still no re-prediction needed! 15

Discussion ¡ • Tradeoffs ¡ – Pros: ¡instant ¡verifica5on, ¡low ¡comp. ¡& ¡low ¡comm. ¡ ¡ – Cons: ¡low ¡update ¡frequency ¡ • Low ¡update ¡frequency ¡due ¡to ¡verifica5on ¡dependency ¡ – Missing ¡msg ¡prevents ¡verifica5on ¡of ¡subsequent ¡msgs ¡ • To ¡increase ¡update ¡frequency ¡ – Error ¡correc5on ¡codes ¡to ¡mi5gate ¡packet ¡loss ¡ – Occasionally ¡sign ¡messages ¡using ¡ECDSA ¡signatures ¡ 16

FastAuth: ¡Evalua5on ¡Seongs ¡ Does ¡FastAuth ¡mi5gate ¡Signature ¡Flooding? ¡ • Evaluate ¡receiver’s ¡& ¡sender’s ¡computa5onal ¡overhead ¡ • Data ¡collec5on ¡ – 4 ¡traces, ¡each ¡by ¡driving ¡along ¡a ¡2-­‑mile ¡path ¡for ¡2 ¡hours ¡ ¡ • Addi5onal ¡evalua5on ¡metrics ¡ – Communica5on, ¡update ¡frequency ¡ • Impac5ng ¡factors ¡ 1. Is ¡FastAuth ¡sensi5ve ¡to ¡ predic.on ¡accuracy? ¡ 2. How ¡does ¡ packet ¡loss ¡ affect ¡FastAuth? ¡ 17

FastAuth: ¡Computa5on ¡ Ratio of sender’s computation Ratio of receiver’s computation FastAuth/ECDSA FastAuth/ECDSA 0.5 0.35 FastAuth/ECDSA FastAuth/ECDSA 0.3 0.4 ratio of receiver comp. ratio of sender comp. 0.25 0.3 0.2 0.15 0.2 20x faster 50x faster 0.1 0.1 0.05 0 0 0 10 20 30 40 50 60 70 80 90 100 0 10 20 30 40 50 60 70 80 90 100 prediction interval (I) prediction interval 18

Outline ¡ • Introduc5on ¡ • Core ¡idea: ¡entropy-­‑aware ¡authen5ca5on ¡ • Proposed ¡flooding-­‑resilient ¡schemes ¡ – FastAuth ¡secures ¡single-­‑hop ¡periodic ¡messages ¡ – SelAuth ¡secures ¡mul5-­‑hop ¡messages ¡ • Related ¡Work ¡ • Conclusion ¡ 19

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 ¡P xy ¡s.t. ¡ ¡ • Pxy ¡= ¡Pr[y ¡verifies ¡signatures ¡forwarded ¡by ¡x] ¡ • Pxy ¡  ¡0 ¡for ¡benign ¡x ¡& ¡Pxy ¡  ¡1 ¡for ¡malicious ¡x ¡ ¡ A Y G B Send invalid Verify S A Relay S A Relay S A sig S A 1. Increase P GB 2. Pushback [S A is bad] 1. Increase P YG 1. Increase P AY 2. Pushback [S A is bad] 2. Pushback [S A is bad] …… P AY = 1 P YG  0 P GB  0 20

Fast ¡Isola5on ¡of ¡Mobile ¡Acacker ¡ NS-2 simulation 8 6 Propagation of invalid signatures (hops) One verification prob. for all neighbors 4 2 8 0 10 20 30 40 50 60 70 80 90 100 6 time (sec) One verification prob. for all neighbors 4 + Pushback warning 2 8 0 10 20 30 40 50 60 70 80 90 100 6 time (sec) Per-neighbor verification prob. 4 2 8 0 10 20 30 40 50 60 70 80 90 100 SelAuth 6 time (sec) Per-neighbor verification prob. 4 + Pushback warning 2 8 0 10 20 30 40 50 60 70 80 90 100 6 time (sec) Verify every signature with p = 1 4 2 0 10 20 30 40 50 60 70 80 90 100 time (sec) 21

SelAuth: ¡Low ¡Overhead ¡ NS-2 simulation: 336 vehicles in 1kmx1km downtown Manhattan 200000 2400 overall computation (# of verification) SelAuth 2200 180000 Verify-All overall communication (KB) one-prob-for-all-neighbors 2000 160000 1800 140000 1600 120000 1400 100000 1200 80000 1000 60000 800 40000 600 20000 400 0 200 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1 initial probability initial probability 22