Prof. J.-P. Hubaux Mobile Networks Module I – Part 2 Securing Vehicular Networks 1

Outline  Motivation  Threat model and specific attacks  Security architecture  Security analysis  Certificate revocation  Data-centric trust  Conclusion 2

What is a VANET (Vehicular Ad hoc NETwork)? Communication: typically over the Dedicated Short Range Communications (DSRC) (5.9 GHz) Example of protocol: IEEE p Penetration will be progressive (over 2 decades or so) 3

Vehicular communications: why?  Combat the awful side-effects of road traffic In the EU, around 40’000 people die yearly on the roads; more than 1.5 millions are injured Traffic jams generate a tremendous waste of time and of fuel  Most of these problems can be solved by providing appropriate information to the driver or to the vehicle 4

Why is VANET security important?  Large projects have explored vehicular communications: Fleetnet, PATH (UC Berkeley),…  No solution can be deployed if not properly secured  The problem is non-trivial Specific requirements (speed, real-time constraints) Contradictory expectations  Industry front: standards are still under development and suffer from serious weaknesses IEEE P1609.2: Standard for Wireless Access in Vehicular Environments - Security Services for Applications and Management Messages  Research front A growing number of papers 5

A modern vehicle (GPS) Human-Machine Interface A modern vehicle is a network of sensors/actuators on wheels ! 6

Threat model  An attacker can be: Insider / Outsider Malicious / Rational Active / Passive Local / Extended  Attacks can be mounted on: Safety-related applications Traffic optimization applications Payment-based applications Privacy 7

Attack 1 : Bogus traffic information Traffic jam ahead  Attacker: insider, rational, active 8

Attack 2 : Generate “Intelligent Collisions” SLOW DOWN The way is clear  Attacker: insider, malicious, active 9

Attack 3: Cheating with identity, speed, or position Wasn’t me!  Attacker: insider, rational, active 10

Attack 4: Jamming 11

Attack 5: Tunnel 12

Attack 6: Tracking 13

Our scope  We consider communications specific to road traffic: safety and traffic optimization Safety-related messages Messages related to traffic information  We do not focus on more generic applications, e.g., toll collect, access to audio/video files, games,… 14

Security system requirements  Sender authentication  Verification of data consistency  Availability  Non-repudiation  Privacy  Real-time constraints 15

Security Architecture 16

Tamper-proof device  Each vehicle carries a tamper-proof device Contains the secrets of the vehicle itself Has its own battery Has its own clock (notably in order to be able to sign timestamps) Is in charge of all security operations Is accessible only by authorized personnel Tamper-proof device Vehicle sensors (GPS, speed and acceleration,…) On-board CPU Transmission system ((( ))) 17

Digital signatures  Symmetric cryptography is not suitable: messages are standalone, large scale, non-repudiation requirement  Hence each message should be signed with a DS  Liability-related messages should be stored in the EDR 18

VPKI (Vehicular PKI) PKI Security services Positioning Confidentiality Privacy... CA P A P B Authentication Shared session key  Each vehicle carries in its Tamper-Proof Device (TPD): A unique and certified identity: Electronic License Plate (ELP) A set of certified anonymous public/private key pairs  Mutual authentication can be done without involving a server  Authorities (national or regional) are cross-certified 19

The CA hierarchy: two options Car A Car B Car A Car B Manuf. 1 Manuf Governmental Transportation Authorities 2. Manufacturers  The governments control certification  Long certificate chain  Keys should be recertified on borders to ensure mutual certification  Vehicle manufacturers are trusted  Only one certificate is needed  Each car has to store the keys of all vehicle manufacturers 20

Secure VC Building Blocks  Authorities Trusted entities issuing and managing identities and credentials 21

Secure VC Building Blocks  Authorities Hierarchical organization ‘Forest’ 22

Secure VC Building Blocks (cont’d) Roadside Unit ‘Re-filling’ with or obtaining new credentials Providing revocation information Roadside Unit Wire-line Connections  Identity and Credentials Management 23

Anonymous keys  Preserve identity and location privacy  Keys can be preloaded at periodic checkups  The certificate of V’s i th key:  Keys renewal algorithm according to vehicle speed (e.g., ≈ 1 min at 100 km/h)  Anonymity is conditional on the scenario  The authorization to link keys with ELPs is distributed 24

What about privacy: how to avoid the Big Brother syndrome? At 3:00 - Vehicle A spotted at position P1 At 3:15 - Vehicle A spotted at position P2  Keys change over time  Liability has to be enforced  Only law enforcement agencies should be allowed to retrieve the real identities of vehicles (and drivers) 25

DoS resilience  Vehicles will probably have several wireless technologies onboard  In most of them, several channels can be used  To thwart DoS, vehicles can switch channels or communication technologies  In the worst case, the system can be deactivated Network layer DSRC UTRA-TDD Bluetooth Other 26

Data verification by correlation  Bogus info attack relies on false data  Authenticated vehicles can also send wrong data (on purpose or not)  The correctness of the data should be verified => data-centric trust  Correlation can help 27

Security analysis  How much can we secure VANETs?  Messages are authenticated by their signatures  Authentication protects the network from outsiders  Correlation and fast revocation reinforce correctness  Availability remains a problem that can be alleviated  Non-repudiation is achieved because: ELP and anonymous keys are specific to one vehicle Position is correct if secure positioning is in place 28

Certificate revocation in VANETs  The CA has to revoke invalid certificates: Compromised keys Wrongly issued certificates A vehicle constantly sends erroneous information  Using Certificate Revocation Lists (CRL) or online status checking is not appropriate  There is a need to detect and revoke attackers fast 29

System model  There is a CA (Certification Authority)  Each vehicle has a public/private key pair, a TC (Trusted Component = TPD), and an EDR (Event Data Recorder)  Safety messages: Are broadcast and signed Include time and position  Several possible communication channels: DSRC Cellular WiMax Low-speed FM 30

Adversary model  The adversary can be: Faulty node Misbehaving node  Example attack: false information dissemination  Adversaries have valid credentials  Honest majority in the attacker’s neighborhood 31

Message validation TPD (Tamper-Proof Device) RTC (Rev. of the Trusted Component ) LEAVE (Local Eviction of Attackers by Voting Evaluators) MDS (Misbehavior Detection System) Evidence Collection Revocation Information CA (Certification Authority) and Infrastructure Functionality Fail (ID) Revocation Decision RC 2 RL (Rev. by Compressed CRLs) Node ID Vehicle Functionality CA Policies Local Warning Messages Revocation Command Scheme overview 32

Revocation protocols  We propose 2 protocols to revoke a vehicle’s keys: Rev. of the Trusted Component (RTC): CA revokes all keys Rev. by Compressed CRLs (RC2RL): if TC is not reachable  Local Eviction of Attackers by Voting Evaluators (LEAVE): Initiated by peers Generates a report to the CA, which triggers the actual revocation by RTC/RC2RL 33

Revocation of the Trusted Component (RTC) 34 RSU: Road Side Unit; PuK = Public Key; T = Timestamp

Revocation by Compressed CRLs (RC2RL)  CRLs are compressed using Bloom filters  Bloom filter: space-efficient probabilistic data-structure Can be queried to check if an element is in a set or not Configurable rate of false positives (but no false negatives) 123m vector with m bits element “a” k different hash functions with range 1…m … H 1 (a)H 2 (a)H k (a)…

Local Eviction of Attackers by Voting Evaluators (LEAVE) 36

Data-Centric Trust 37 Data Trust Decision on event

What is Data-Centric Trust?

Data-Centric Trust in Networks  Packet forwarding  Security associations  Reputation A M B Data dissemination Insufficient Hard 39 Traditional ad hoc networks Ephemeral networks Data Trust = Entity TrustData Trust = F(Entity Trust, context)

Event-specific trust Dynamic trust metric Security status A C B M General Framework Trust Computation Weights (data-centric trust levels) is the default trustworthiness Location Time Event reports of type from nodes

A C B M General Framework Evidence Evaluation Decision Logic Decision on Reported Event Report contents Event reports of type from nodes

Decision Logics  Most trusted report  Weighted voting  Bayesian inference Takes into account prior knowledge  Dempster-Shafer Theory probability is bounded by belief and plausibility Uncertainty (lack of evidence) does not refute nor support evidence

Conclusion  Vehicular communications could lead to the largest mobile ad hoc network (around 1 billion nodes)  The security of that network is a difficult and highly relevant problem  Car manufacturers seem to be poised to massively invest in this area  Slow penetration makes connectivity more difficult  Security leads to a substantial overhead and must be taken into account from the beginning of the design process  The field offers plenty of novel research challenges  Pitfalls Defer the design of security Security by obscurity  More information at 43