Mobile Networks Module I Part 2 Securing

Mobile Networks Module I – Part 2 Securing Vehicular Networks Prof. J. -P. Hubaux 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 802. 11 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 P 1609. 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: • • Malicious / Rational • Active / Passive • § Insider / Outsider 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) Security services Positioning Confidentiality Privacy. . . Shared session key PKI CA PA PB Authentication § 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 1. Governmental Transportation Authorities 2. Manufacturers Country 1 Region 1 District 1 Manuf. 2 Region 2 District 2 Car A Car B § The governments control certification § Vehicle manufacturers are trusted § Long certificate chain § Only one certificate is needed § Keys should be recertified on borders to § ensure mutual certification Car B 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) § Identity and Credentials Management ‘Re-filling’ with or obtaining new credentials Roadside Unit Providing revocation information Roadside Unit Wire-line Connections 23

Anonymous keys § Preserve identity and location privacy § Keys can be preloaded at periodic checkups § The certificate of V’s ith 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: 15 - Vehicle A spotted at position P 2 At 3: 00 - Vehicle A spotted at position P 1 § Keys change over time § Liability has to be enforced § Only law enforcement agencies should be allowed to retrieve the 25 real identities of vehicles (and drivers)

Do. S resilience § Vehicles will probably have several wireless technologies onboard § In most of them, several channels can be used § To thwart Do. S, vehicles can switch channels or communication technologies Network layer DSRC UTRA-TDD Bluetooth Other § In the worst case, the system can be deactivated 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 • Wi. Max • 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

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

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

Revocation by Compressed CRLs (RC 2 RL) § 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) element “a” k different hash functions with range 1…m vector with m bits H 1(a) H 2(a) 0 1 0 0 1 2 3 1 0 … 0 Hk(a) … 1 0 0 m 35

Local Eviction of Attackers by Voting Evaluators (LEAVE) 36

Data-Centric Trust Data Trust Decision on event 37

What is Data-Centric Trust?

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

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

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

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 http: //ivc. epfl. ch 43