Evaluating On-demand Pseudonym Acquisition Policies in Vehicular Communication Systems Mohammad Khodaei and Panos Papadimitratos Networked Systems Security Group (NSS) www.ee.kth.se/nss July 5, 2016 M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 1 / 20
Outline Secure Vehicular Communication (VC) System 1 System Overview 2 Pseudonym Acquisition Protocols 3 Performance Evaluation 4 Conclusion 5 M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 2 / 20
Outline Secure VC System 1 System Overview 2 Pseudonym Acquisition Protocols 3 Performance Evaluation 4 Conclusion 5 M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 3 / 20
Secure Vehicular Communication (VC) System RCA A certifies B A B Root Certification Authority (RCA) Cross-certification Communication link Long Term CA (LTCA) Message dissemination Domain A Domain B Domain C RA Pseudonym CA (PCA) RA LTCA RA LTCA LTCA Resolution Authority (RA) X-Cetify PCA PCA PCA Lightweight Directory Access LDAP LDAP Protocol (LDAP) Roadside Unit (RSU) 3/4/5G RSU {Msg} (P iv ) , {P i v } (PCA) Trust established with RCA, or through cross certification {Msg} (P iv ) , {P i v } (PCA) B M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 4 / 20
State of the art Standardization and Harmonization IEEE 1609.2 [1], ETSI [2] and C2C-CC [3]: VC related specifications for privacy-preserving architectures Projects SEVECOM, EVITA, PRECIOSA, OVERSEE, DRIVE-C2X, Safety Pilot, PRESERVE, CAMP-VSC3 Vehicular Public Key Infrastructure (VPKI) Cornerstone for all these efforts Consensus on the need and basic characteristics Acquisition of short-term credentials, pseudonyms How should each vehicle interact with the VPKI, e.g., how frequently and for how long? Should each vehicle itself determine the pseudonym lifetime? M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 5 / 20
Pseudonym Refilling Strategies Preloading schemes Preloading vehicles with required pseudonyms for a long period On-demand schemes More frequent vehicles interactions with the VPKI servers, e.g., once or multiple times per day Pseudonyms validity intervals Overlapping Non-overlapping ❵❵❵❵❵❵❵❵❵❵❵❵❵ Strategies Preloading & Overlapping Preloading & Nonoverlapping On-demand & Overlapping On-demand & Nonoverlapping Metrics ❵ Storage size large large small small Pseudonym quantity fixed & low volume fixed & high volume varying varying Pseudonym lifetime long short varying varying V-VPKI communication frequency low low high high Communication overhead low low high high Efficient pseudonym utilization very low very low high high Pseudonym revocation difficult & challenging difficult & challenging no need (lower risk) no need (lower risk) Pseudonym vulnerability window wide wide narrow narrow Resilience to Sybil-based misbehavior × � × � User privacy protection (probability of linking privacy protection: high privacy protection: low privacy protection: high privacy protection: low sets of pseudonyms based on timing information) (probability of linking: low) (probability of linking: high) (probability of linking: low) (probability of linking: high) User privacy protection (duration for which a pseudonym provider can trivially link sets of pseudonyms privacy protection: low privacy protection: low privacy protection: high privacy protection: high for the same vehicle; the longer the duration, (long duration) (long duration) (short duration) (short duration) the higher the chance to link sets of pseudonyms) Effect on safety application operations low low high high Deployment cost (e.g. RSU) low low high high C2C-CC [3], PRESERVE [4], SRAAC [8], V-tokens [9], VeSPA [11], SEROSA [12], Proposals & schemes SeVeCom [6], Safety Pilot [7] CAMP VSC3 [5] CoPRA [10] SR-VPKI [13], PUCA [14] M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 6 / 20
Problem Statement On-demand acquisition with non-overlapping pseudonym lifetimes (i) improved security, i.e., resilience to Sybil-based misbehavior, (ii) user privacy protection, i.e., shorter periods with linkable pseudonyms, and (iii) efficiency, i.e., no over-provisioning Contributions Proposing three generally applicable policies Evaluating overall VPKI performance, i.e., end-to-end latency Leveraging two large-scale mobility datasets Stronger adversarial model Increased protection against honest-but-curious VPKI entities Correct execution of protocols but motivated to profile users Concealing pseudonym provider identity and acquisition time, and reducing pseudonyms linkability (inference based on time) M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 7 / 20
Outline Secure VC System 1 System Overview 2 Pseudonym Acquisition Protocols 3 Performance Evaluation 4 Conclusion 5 M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 8 / 20
System Model A certifies B A B RCA Communication link Home Domain (A) Foreign Domain (B) LDAP RA RA F-LTCA H-LTCA I. f-tkt req. PCA PCA 1. LTC 2. n-tkt II. f-tkt III. n-tkt 3. psnym req. IV. psnym req. 4. psnyms acquisition V. psnyms acquisition Figure: VPKI Architecture M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 9 / 20
Pseudonym Acquisition Policies t start t end Unused Trip Duration Pseudonyms User-controlled policy (P1) } } } } } τ P τ P τ P τ P τ P Γ P2 Γ P2 Oblivious policy (P2) } } } } } } τ P τ P τ P τ P τ P τ P Γ P3 Γ P3 Γ P3 Expired Pseudonym Universally fixed policy (P3) } } } } } } } } τ P τ P τ P τ P τ P τ P τ P τ P System Time P1 & P2: Requests could act as user “fingerprints” ; the exact time of requests and all subsequent requests until the end of trip could be unique, or one of few P3: Requesting intervals fall within “universally” fixed interval Γ P 3 , and pseudonyms are aligned with PCA clock M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 10 / 20
Outline Secure VC System 1 System Overview 2 Pseudonym Acquisition Protocols 3 Performance Evaluation 4 Conclusion 5 M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 11 / 20
Ticket Acquisition Protocols Protocol 1 Ticket Request (from the LTCA) Protocol 2 Issuing a Ticket (by the LTCA) 1: procedure ReqTicket ( P x , Γ Px , t s , t e , t date ) 1: procedure IssueTicket (( msg ) σ v , LTC v , N , t now ) Verify(LTC v , ( msg ) σ v ) if P x = P 1 then 2: 2: ( t s , t e ) ← ( t s , t e ) IK tkt ← H (LTC v || t s || t e || Rnd IK tkt ) 3: 3: else if P x = P 2 then ζ ← ( SN , H ( Id PCA � Rnd tkt ) , IK tkt , Rnd IK tkt , 4: 4: ( t s , t e ) ← ( t s , t s + Γ P 2 ) t s , t e , Exp tkt ) 5: else if P x = P 3 then ( tkt ) σ ltca ← Sign ( Lk ltca , ζ ) 6: 5: P 3 ) , t date + Γ i +1 ( t s , t e ) ← ( t date + Γ i return (( tkt ) σ ltca , N + 1 , t now ) P 3 ) 7: 6: end if 7: end procedure 8: ζ ← ( Id tkt - req , H ( Id PCA � Rnd tkt ) , t s , t e ) 9: ( ζ ) σ v ← Sign ( Lk v , ζ ) 10: “ticket identifiable key” ( IK tkt ) binds a ticket to the return (( ζ ) σ v , LTC v , N , t now ) 11: 12: end procedure corresponding Long Term Certificate (LTC) Preventing a compromised LTCA from mapping a Run over Transport Layer Security (TLS) with mutual different LTC during resolution process authentication M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 12 / 20
Pseudonyms Acquisition Protocols Protocol 4 Issuing Pseudonyms (by the PCA) Protocol 3 Pseudonym Request (from the PCA) 1: procedure IssuePsnyms ( psnymReq ) 1: procedure ReqPsnyms ( t s , t e , ( tkt ) σ ltca ) for i:=1 to n do psnymReq → ( Id req , Rnd tkt , t s , t e , ( tkt ) σ ltca , 2: 2: { ( K 1 v , ..., ( K n Begin v ) σ k 1 v ) σ kn v } , N , t now ) 3: Generate( K i v , k i v ) 4: Verify( LTC ltca , ( tkt ) σ ltca ) 3: ( K i v ← Sign( k i v , K i v ) σ ki v ) 5: H ( Id this - PCA � Rnd tkt ) ? = H ( Id PCA � Rnd tkt ) 4: End 6: [ t s , t e ] ? = ([ t s , t e ]) tkt 5: psnymReq ← ( Id req , Rnd tkt , t s , t e , ( tkt ) σ ltca , 7: for i:=1 to n do 6: { ( K 1 v , ..., ( K n v ) σ k 1 v ) σ kn v } , N , t now ) Begin 7: return psnymReq 8: Verify( K i v , ( K i v ) σ ki v ) 8: 9: end procedure IK P i ← H ( IK tkt || K i v || t i s || t i e || Rnd IK i v ) 9: ζ ← ( SN i , K i v , t i s , t i e ) 10: v , IK P i , Rnd IK i Run over TLS with unidirectional (server-only) ( P i v ) σ pca ← Sign ( Lk pca , ζ ) 11: authentication End 12: return ( { ( P 1 v ) σ pca , . . . , ( P n v ) σ pca } , N +1 , t now ) 13: 14: end procedure “pseudonym identifiable key” ( IK Pi ) binds a pseudonym to the corresponding ticket Preventing a compromised PCA from mapping a different ticket during resolution process M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 13 / 20
Outline Secure VC System 1 System Overview 2 Pseudonym Acquisition Protocols 3 Performance Evaluation 4 Conclusion 5 M. Khodaei and P. Papadimitratos (KTH) MobiHoc IoV-VoI 2016 July 5, 2016 14 / 20
Recommend
More recommend
