Vehicular Communications (VC) Security on Wheels. Vehicular Communications (VC) (cont d) Vehicles equipped with. Efficiency. Safety.

Transcription

1 IEEE VNC 2011 Keynote Security on Wheels Vehicular Communications (VC) Vehicles equipped with Computers Sensors Including positioning systems (GPS, Galileo) Wireless transceivers Panos Papadimitratos 1 Vehicle illustration courtesy of Daimler 2 Vehicular Communications (VC) (cont d) Vehicular Communications (VC) (cont d) GPS GPS Illustration by the Car-to-Car Communication Consortium 3 4 Vehicular Communications (VC) (cont d) Safety Vehicular Communications (VC) (cont d) Efficiency Emergency vehicle approaching In area (X,Y,Z); Efficiency Congestion at (x,y,z) Traffic Update: Congestion at (x,y,z); Use alternate route Ambulance approaching at (x,y,z) Slow down and yield 5 6 1

2 Security and Privacy for VC Why? Safety (?) S&P for VC Why? (cont d) Efficiency (?) Emergency vehicle approaching In area (X,Y,Z); Efficiency (?) Congestion at (x,y,z) TOC Traffic Update: Congestion at (x,y,z); Use alternate route Ambulance approaching at (x,y,z) Slow down and yield 7 8 S&P for VC Why? (cont d) Privacy (?) S&P for VC Why? Without robust designs, VC systems may facilitate antisocial behavior The deployment of vulnerable VC systems may cancel out their envisioned benefits Abused, poorly defended VC systems can cause damages and high cost Attackers and adversaries will always be present Concerned users could opt out 9 10 Why is VC security different? Complex system Hybrid (ad hoc, infrastructure) networking Rich sensory inputs and data exchange Large scale Mobility Pre-VC transportation systems and legacy constraints and requirements Liability identification Tight coupling of users, applications, and network Strong privacy concerns P. P., V. Gligor, J.-P. Hubaux, Securing Vehicular Communications Assumptions, Requirements and Principles, ESCAR Securing VC Systems Basic building blocks Cryptographic keys and credential management Secure V2X communication Data-centric trust / security Privacy enhancing technologies In-car software and hardware security 12 2

3 Securing VC Systems (cont d) Baseline requirements Authentication Integrity Non-repudiation Access control Availability Privacy (Liability identification) Securing VC Systems (cont d) A CA A Secure Wire-line Communication CA B B Secure and Privacy-Enhancing V2V and V2I Single- and Multihop Wireless Communication Securing VC Systems (cont d) Payload Location: (x V,y V,z V ) Time: t V Signature with k V Cert CA (V,K V,A V,T) Securing VC Systems (cont d) Privacy concerns Safety messaging could be an always-on application Vehicle transmissions easy to eavesdrop Any two messages digitally signed by the same on-board unit (vehicle) and private key can be trivially linked Location traces can reveal other sensitive information Vehicle V Vehicle U Securing VC Systems (cont d) Practicality concerns Security is perceived as a constraint More on-board processing power Careful use of strong security Communication optimizations Adaptation to operational requirements Impact of security on VC-enabled applications IEEE VNC 2011 Keynote Secure Vehicular Communication P. P., "On the road - Reflections on the Security of Vehicular Communication Systems," IEEE ICVES,

4 Pseudonymous authentication Ideally, authentic and anonymous communications; but: High processing and communication overhead Often, messages from the same vehicle should be linkable Let messages generated by a given vehicle be linked at most over a protocol-selectable period of time The shorter this period, the harder to track a vehicle becomes 19 Pseudonymous authentication (cont d) Pseudonym Remove all identifying information from certificate Pseudonym format PNYM PSNYM-Provider ID Short-term Cert() Public Key K i PSNYM Lifetime PSNYM-Provider Signature Pseudonym provider: a trusted third party 20 Pseudonymous authentication (cont d) 1. Generate signature with SK 1 2. Append certificate 3. Send packet Beacon packet Header: H Payload: m Sig(SK 1, H, m) Cert(PNYM_K 1 ) 1. Validate certificate (if not previously done so) 2. Validate signature 3. Validate geo-stamp in the header 4. Accept/Reject packet Pseudonymous authentication (cont d) Equip vehicles with multiple pseudonyms Alternate among pseudonyms over time (and space) Sign message with the private key corresponding to pseudonym Append current pseudonym to signed message PSNYM_2 PSNYM_3 PSNYM_2 PSNYM_1 PSNYM_3 PSNYM_2 PSNYM_1 PSNYM_ Pseudonymous authentication (cont d) Credentials management Re-filling with or obtaining new credentials Roadside Unit Pseudonymous authentication (cont d) System setup (one option) Authority (CA) Long-term Identification Authority A Pseudonym Provider PSNYM_1,, PSNYM_k Re-filling with or obtaining new credentials Roadside Unit 23 Wire-line Connections Vehicle V 24 Set of pseudonyms for V 4

5 Pseudonymous authentication (cont d) Pseudonym resolution Pseudonymous communication transcript Authority O Vehicle V generated the transcript Pseudonymous authentication (cont d) Managing a pseudonymous authentication system is cumbersome Preload large numbers of pseudonyms or obtain them on-the-fly Costly computations at the side of the pseudonym provider Costly wireless communication to obtain pseudonyms Need reliable access to the pseudonym provider Solution: On-board generation of pseudonyms Group signatures Hybrid scheme Group A public key Valid signature from an unidentified member of Group A Group A Group member signing keys gsk_1 gsk_2 gsk_3 Combine Pseudonymous authentication (Baseline Pseudonym (BP) approach) and Group Signatures (GS) All legitimate vehicles belong to the same group Each node is equipped with a secret group signing key and the group public key G. Calandriello, P. P., A. Lloy, and J.-P. Hubaux, "Efficient and Robust Pseudonymous Authentication in VANET," ACM VANET Hybrid scheme (cont d) Each node Generates its own pseudonyms and signs them with a Group Signature GS act as a self-generated certificate Uses the private key corresponding to the pseudonym to sign messages As in the baseline approach Appends the self-generated certificate As in the baseline approach Hybrid scheme (cont d) Message formats Baseline (BP) Group Signature (GS) Hybrid m i (m) kv m ( ) CA m, V m i (m) k V K Cert i ( K CA V ) i V K H i ( K CA ) i V V

6 Secure VC: system overview Summary (cont d) P. P., L. Buttyan, T. Holczer, E. Schoch, J. Freudiger, M. Raya, Z. Ma, F. Kargl, A. Kung, and J.-P. Hubaux, "Secure Vehicular Communications: Design and Architecture," IEEE Communications Magazine, November 2008 F. Kargl, P. P., L. Buttyan, M. Müter, B. Wiedersheim, E. Schoch, T.-V. Thong, G. Calandriello, A. Held, A. Kung, and J.-P. Hubaux, "Secure Vehicular Communications: Implementation, Performance, and Research Challenges," IEEE Communications Magazine, November IEEE VNC 2011 Keynote Secure Vehicular Communication System scaling and effectiveness 33 Are Secure VC systems practical? Setup EC-DSA as basic signature algorithm Group Signatures as proposed in: D. Boneh and H. Shacham, Group Signatures with verifier-local revocation, ACM CCS 2004 Security level of 80 bits for message signatures and 128 bits for certificates Benchmarks Reference CPU: 1.5 GHz Centrino OpenSSL for EC-DSA Group Signatures implementation not available Calculated the number of 32-bit word multiplications required for GS and benchmarked the multiplication operation 34 Communication Overhead GS has a constant overhead of 225 bytes Values below in bytes Certificate attached to 1 every beacons Communication Overhead (cont d) α (msg) Scheme BP Hybrid P P G. Calandriello, P. P., A. Lloy, and J.-P. Hubaux, "Efficient and Robust Pseudonymous Authentication in VANET," ACM VANET Communication reliability (P) as a function of the neighborhood size (N); γ: beaconing rate 36 6

7 Processing Overhead Signature Scheme Sign (sec) Verify (sec) Sig. size (bytes) Pub. key (bytes) Priv. key (bytes) Processing Overhead (cont d) Processing delay computed over one pseudonym lifetime τ = 60 sec Ten safety messages per second (per vehicle) GS computed/verified once per τ EC-DSA 8e-4 4.2e GS 5.37e e Scheme Sign (sec) Verify (sec) 38 Overhead (bytes) BP 5e-4 3e GS 1.78e e Hybrid 5.9e-4 3.1e Processing Overhead (cont d) Sign (ms) Verify (ms) 39 Overhead (bytes) BP LONG Hybrid LONG SHORT G. Calandriello, P. P., J.-P. Hubaux, A. Lioy, Efficient and Robust Pseudonymous Authentication in VANET, VANET 2007 D. Boneh, H. Shacham, Group Signatures with verifier-local Revocation, CCS 2004 IEEE 1363a IEEE standard specifications for public-key cryptography, 2004 Processing Overhead (cont d) Packets per 100 ms BP LONG 13.9 Hybrid LONG 1.9 SHORT 33.3 Use of pure GS is not feasible Hybrid scheme One LONG message per vehicle and per pseudonym lifetime SHORT packets are the dominant factor System is at the limit of stability 40 Processing Overhead (cont d) Processing Overhead (cont d) Message arrival rate, short packets; α= 10, β= 0, τ= 60; HP scheme; λ for the same setup and for γ=10 beacons/sec 41 Message verification delay, short packets 2-class M/D/1 queue 42 7

8 Processing Overhead (cont d) SVC and transportation safety Emergency braking Platoon on 100 cars on one lane Average spacing: 20 m Average speed: 80 Km/h Wet road Braking capability: 4 m/s 2 Driver reaction s Pseudonym lifetime 60 s Emergency event at the head after 60 s No lane change SVC and transportation safety (cont d) 20 m SVC and Transportation Safety Emergency braking and floating data (event notification) applications 40 Intended transmission range = 200 m 45 P. P., G. Calandriello, A. Lioy, and J.-P. Hubaux, Impact of Vehicular Communication Security on Transportation Safety," IEEE INFOCOM MOVE 2008 G. Calandriello, P. P., J-P. Hubaux, and A. Lioy, "On the Performance of Secure Vehicular Communication Systems, IEEE Transactions on Dependable and Secure Computing, Sept SVC and transportation safety (cont d) SVC and transportation safety (cont d) Emergency Braking Notification application HP scheme, 8 lane highway, 160 vehicles in range Append Cert/GS more times after pnym change Crash average 80 to 100% without Emergency braking notification Urban setting Penetration rate and VC system effectiveness (highway) V2V communication

9 SVC and Transportation Safety (cont d) Secure Geo-Cast Forwarder 2 (F 2 ) Decentralized Floating Car Data; communication performance 49 Source (S) Forwarder 1 (F 1 ) 50 Destination (D) Secure Geo-Cast (cont d) Implementations on two platforms STANDARD: IBM Thinkpad T41, Intel Pentium M 1.6 GHZ CPU, 256 Mb (333MHz) DDR RAM, Linux EMBEDDED: NEC prototype for VC, MIPS architecture, VR5500 RISC CPU (400 MHZ), 64 MB DDR RAM, Linux Secure Geo-Cast (cont d) Processing and delay C. Harsch, A. Festag, and P. P., "Secure Position-Based Routing for VANETs," IEEE VTC 2007-Fall A. Festag, P. P., and T. Tielert, Design and Performance of Secure Geocast for Vehicular Communication, IEEE Transactions on Vehicular Technology, IEEE Transactions on Vehicular Technology, June IEEE VNC 2011 Keynote Secure Vehicular Communication System building and experimentation System building: Secure VC Field demonstration, Dudenhofen, October 2008, Car to Car Communication Consortium (C2C-CC) SeVeCom demonstrator; last appearance ITS World, Stockholm 2009 M. Gerlach, F. Friederici, P. Ardelean, and P. P., Security Demonstration, C2C-CC Forum and Demonstration, Dudenhofen, Germany, October 2008 P. Ardelean and P. P., "Secure and Privacy-Enhancing Vehicular Communication," Demo, IEEE WiVeC, Calgary, AL, Canada, September 2008 F. Kargl, P. P., T. Holczer, S. Cosenza, A. Held, M. Mütter, N. Asaj, P. Ardelean, D. de Cock, M. Sall, and B. Wiedersheim, Secure Vehicle Communication, ACM MobiSys. Krakow, Poland, July

10 System building: Secure VC (cont d) System building: Secure VC (cont d) System building: Secure VC (cont d) System building: Secure VC (cont d) System building: Secure VC (cont d) Security deamon for C2C-CC field demo System building: Secure VC (cont d) Laptop attacker Based on illustrations by M. Gerlach Based on illustration by M. Gerlach 59 Security use case: impersonation of an emergency vehicle 60 10

11 Secure VC: field operational testing Secure VC: field operational testing (2) FP7 EU project, Partners: University of Twente, Renault, Fraunhofer SIT, Escrypt, Trialog, and KTH Illustration by F. Kargl IEEE VNC 2011 Keynote Data centric trust establishment Eviction of faulty nodes Challenge Identify faulty nodes and remove them from the network Basic ideas Detect misbehaving or faulty nodes in proximity Contribute to the collection of faulty behavior evidence Use detection locally for self-protection, ignoring messages originating from nodes suspected to be faulty Only the CA can revoke a faulty node M. Raya, P. P., I. Aad, D. Jungels, and J.-P. Hubaux, "Eviction of Misbehaving and Faulty Nodes in Vehicular Networks," IEEE JSAC, 2007 T. Moore, M. Raya, J. Clulow, P. P., R. Anderson and J.-P. Hubaux, Fast Exclusion of Errant Devices from Vehicular Networks, IEEE SECON, Eviction of faulty nodes (cont d) LEAVE (Local Eviction of Attackers by Voting Evaluators) or Sting protocols Warning, Disregard, or Sting messages Eviction of faulty nodes (cont d) Certificate Revocation: Distribute Lists (CRLs) to all vehicles within a domain Roadside Unit Suspect vehicle Report Disregard data 65 Encoded, verifiable CRL pieces 66 CA 11

12 Data-centric trust establishment Need to extend the traditional notion entitycentric trust Cannot rely or operate exclusively on a priori or largely time-invariant trust relations with network entities What if the identity of the data producing entity is secondary? What if a privacy-enhancing mechanism is used? Data-centric trust establishment (cont d) Proposal: data-centric trust Trustworthiness attributed to node-reported data per se In VC systems Evaluate the trustworthiness of data reported by other vehicle rather than the trustworthiness of the vehicles themselves Contradicting reports Highly volatile network Data-centric trust establishment (cont d) Data-centric trust establishment (cont d) Traffic Jam Accident Junction warning RL distribution Data-centric trust establishment (cont d) (x,y,z) Data-centric trust establishment (cont d) Proximity to event can be crucial Geographical Time Security status Revoked or not Default adaptation Vehicles from a different domain (authority)

13 Data-centric trust establishment (cont d) Weights (trust levels) Event-specific trust f( ( v k ), j ) Fsv ( ( k), f( ( vk), j), l( vk, j)) Dynamic trust metric Security status l( vk, j) s( v k ) Output: Decision on Reported Event Decision Logic IEEE VNC 2011 Keynote Challenges Node and event type Node id Event reports from nodes v k of type j 73 Evidence M. Raya, P. P., V. D. Gligor, and J.-P. Hubaux, " On Data-Centric Trust Establishment in Ephemeral Ad Hoc Networks," IEEE INFOCOM Securing VC Systems Projects Network on Wheels (NoW) IEEE Working Group CAMP and the Vehicle Safety Communication - Applications (VSC) 2, VSC 3 Consortia Secure Vehicle Communication (SeVeCom) PRECIOSA EVITA PRESERVE Securing VC Systems (cont d) Data centric security Privacy and accountability Formal analysis Broader experimentation and access to test-beds Increased importance of security and privacy for VC systems Hybrid, electric vehicles Smart grids Securing VC Systems (cont d) Deployment and costs Multiple communication/networking technologies and platforms Standardization Coordination around the globe 77 13