Security & Privacy in VANETs Ahren Studer , Runting Shi, Adrian Perrig, CMU Fan Bai, GM

1. Security & Privacy in VANETs Ahren Studer, Runting Shi,Adrian Perrig, CMUFan Bai, GM 1

2. Acknowledgements • Authors would like to acknowledge the insightful comments from our colleagues, which inspire us to further improve the quality of our presentation: • Dr. Bhargav Bellur (GM India Science Lab.) • Dr. Aravind Iyer (GM India Science Lab.) • Dr. Cem Saraydar (GM R&D, ECI Lab) • Dr. Hariharan Krishnan (GM R&D, ECI Lab) • Dr. Andre Weimerskirch (CAMP)

3. Outline • Motivation & Properties • Prior Approaches • Our Solution: TACKs • Temporary Anonymous Certified Keys • Simulation Results • Conclusion • Potential Changes to 1609.2

4. Goal: Privacy Without Overhauling 1609.2 • Same underlying authentication • Keep ECDSA, TESLA, … • “Privacy”: Long Term Unlinkability • Only the proper authority can track an OBU based on the keys and certificates used to sign messages over a period of time • T: X signs message A • T+10 minutes: Y signs message B • Eavesdropper cannot tell if X = Y

5. Signatures in VANETs • We need signatures (or other authentication) • Stops malicious parties from impersonating OBUs or RSUs • Identifies misbehaving or malfunctioning vehicles • We need a way to verify those signatures match valid OBUs • Stops laptops from posing as a valid vehicle • Allows removal of destroyed or misbehaving OBUs • Prevent creation of fake vehicles

6. Signatures in VANETs • We need a way to associate a key with a physical entity over time • Blind spot alerts won’t work if you can’t link two different messages • Call this “Short Term Linkability” ?

7. Public Key Infrastructure Works. • Trusted authority signs a copy of each OBU’s public key • Every OBU gets a copy of the authority’s public key • OBUs sign each message using their private key • Authority can sign messages saying which OBUs are no longer valid • Certificate Revocation List

8. Public Key Infrastructure Works...Somewhat • Distributing CRLs is an issue • Large list to distribute and keep up to date • Millions of vehicles removed from the road annually • No Long Term Unlinkability • Traditionally each vehicle possesses one asymmetric key • Like driving down the road with a loudspeaker and shouting your name

9. Goals • Authenticate valid OBUs • Authenticate messages • Short Term Linkability • Long Term Unlinkability • Low Overhead • Computation • Communication

10. Outline • Motivation & Properties • Prior Approaches • Our Solution: TACKs • Temporary Anonymous Certified Keys • Simulation Results • Conclusion • Changes to 1609.2

11. Multiple Certificates Per OBU • Each OBU stores a year’s worth of certificates & keys • Each key is used for a short period of time • Straightforward • Limited connectivity to an authority is needed • Large overhead to revoke 1 OBU • Malicious OBU can pose as multiple vehicles Raya and Hubaux “The Security of Vehicular Ad Hoc Networks” ACM Workshop on Security of ad hoc and sensor networks (SASN 05)

12. Coordinated Key Changes • OBUs communicate to determine when to change keys • Coordinating simultaneous key/certificate changes provides long term unlinkability • Difficult to track a vehicle • Additional communication needed • OBUs can opt out Sampigethaya et al. “CARAVAN: Providing Location Privacy for VANET” Embedded Security in Cars (ESCAR) 2005

13. Group Signatures to Generate Certificates • OBU uses a group signature to sign its own certificate • Proves signer is a valid OBU (not which OBU) • Certificate changes can be frequent • One key per OBU to revoke • Computationally expensive • OBUs can generate arbitrary number of certificates • Fake a traffic jam Calandriello et al. “Efficient and Robust Pseudonymous Authentication in VANET” VANET workshop 2007

14. Outline • Motivation & Properties • Prior Approaches • Our Solution: TACKs • Temporary Anonymous Certified Keys • Simulation Results • Conclusion • Potential Changes to 1609.2

15. Temporary Anonymous Certified Keys (TACKs) • OBUs anonymously request certificates • OBU signs the request with a Group Signature • Only proves an OBU is valid (not revoked) • Certificates are only valid for a short period of time in a specific region • OBUs frequently change keys • Revoked vehicles are quickly evicted • Authority can verify a requestor was not revoked • All other VANET operation is unchanged

16. TACKs Assumptions • OBUs know their current location • GPS provides enough accuracy • OBUs know how to contact an Authority • Location of authority is included in map metadata • Opportunistic network approach • When in range, acquire certificates • Or a multi-hop routing protocol helps to enable the communication between authority and OBUs • The existence of multi-hop routing protocol is a separate issue (should not be in 1609.2 standard)

17. TACK Update • OBU:pick new temporary key pair (K+, K-) • OBU → Authority: group signature of K+ to prove that it is a valid OBU • Authority: verify proof (wait a little bit) • Authority → OBU: certificate(K+) • Temporary keys can be ECDSA, TESLA, … • TACK is independent of the authentication schemes specified

18. TACK Update • Use Boneh & Shacham’s group signature • Verifier can tell who has been revoked • Verifier can tell if 1 OBU makes multiple requests in an interval • Only the group manager can determine which OBU generated the request • Group signature is 228B • 360ms to sign on a 400MHz processor • 36ms to verify on a 3.2GHz processor • 149B version is 5x slower Boneh & Shacham “Group Signatures with Verifier-Local Revocation” Conference on Computer and Communications Security 2004

19. TACK Properties • Authenticate valid OBUs (temporary cert.) • Authenticate messages (signatures) • Short Term Linkability (1 cert. per interval) • Low Overhead • Computation (OBU generates 1 group signature per interval) • Communication (228B) • OBUs no longer need CRLs for other OBUs

20. Still Missing Long Term Unlinkabiltiy Anonymous certificate are only a part of the solution Need Simultaneous Key Changes

21. Region Based Authorities • Divide roadways into regions following a given criteria • The detailed criteria is an independent issue, and it is not in the scope of our study • Each region has a different authority • This Regional Authority can only sign certificates for its region • Certificates for a different region are invalid • Forces simultaneous key changes

22. Regional Authorities (RAs) • OBUs update keys when entering the region • OBUs physically near each other update simultaneously • No explicit communication for key revocation: location implicitly indicates when to change keys • Implicit forcing function • To operate in the new region an OBU needs to update its key • Opting out means disabling OBU operation • Can’t continue to use the same key from the old region

23. Regional Authorities (RAs) Works best if region boundaries correspond with traffic mixing points

24. Identifying the Origin of a Message • Want to identify misbehaving or malfunctioning OBUs • In TACKs, the group signature hides which OBU requested a certificate from the RA • RA must record the request • Group manager can use the request to find the OBU

25. Who can determine the signer? Signature → Certificate → Request → OBU Eavesdropper RA Group Manager Techniques exist so multiple parties are needed to determine the OBU For example: DMV + Police + Judge

26. TACK Properties • Authenticate valid OBUs (temporary cert.) • Authenticate messages (signatures) • Short Term Linkability (1 cert. per interval) • Long Term Unlinkability (cert. updates when entering a region) • Low Overhead • Computation (1 expensive request per interval) • Communication (228B) • OBUs no longer need CRLs for other OBUs

27. Outline • Motivation & Properties • Prior Approaches • Our Solution: TACKs • Temporary Anonymous Certified Keys • Simulation Results • Conclusion • Changes to 1609.2

28. Simulation of TACKs • Ns2 simulation with realistic highway and city mobility models 3km 2km 3km

29. Simulation of TACKs • 300m wireless range, Rayleigh fading • Wireless traffic includes Beacons & Certificate Requests • Beacons every 100ms • Standard format for safety applications • Location, velocity, signature, certificate • Certificate Requests • Whenever an OBU enters a new region • If no response, a second request is made

30. Simulation Metrics • P(Successful Update) • Probability of acquiring a new certificate, illustrating how reliable TACKs protocol could be • Necessary for operation in the new region • Update Overhead • Bandwidth consumed to perform certificate updates, illustrating the efficiency of TACK protocol

31. City Results • Inexpensive OBUs and RAs can support TACKs • 260B average update overhead (1 request needed) Bumper-to-Bumper Traffic

32. Highway Results • Computation becomes the limiting factor • Algorithms are easily parallelized

33. Highway Results • Increased communication since no response • Communication is not the bottleneck

34. Simulation Results • Our simulation study indicates that TACKs are a reliable way to preserve the long-term unlinkability of vehicles, without generating too much communication overhead • Even in worst case scenario RSUs can support bumper to bumper highway speed cars • Computation is the limiting factor • Silicon is cheap, bandwidth is expensive

35. Conclusions • TACKs fulfills the necessary properties • Current mechanisms for message & OBU authentication and short term linkability • Group signatures to conceal the identity of an OBU requesting a certificate • Geographically limited authorities provide timely eviction of revoked OBUs and long term unlinkability by forcing synchronized key changes • TACKs is efficient enough to operate in real world settings

36. Outline • Motivation & Properties • Prior Approaches • Our Solution: TACKs • Temporary Anonymous Certified Keys • Simulation Results • Conclusion • Potential Changes to 1609.2

37. Necessary Changes to 1609.2 • Addition of group signature support • Additional region fields to certificates • Additional specs for certificate requests • Not part of 1609.2, but a new application

38. Addition of Group Signatures • Boneh & Shacham’s Group Signature with Verifier Location Revocation is needed • Requires reservation of a PKAlgorithm value

39. Addition of Region to OBU Certificates • Need a field in OBU certificates to indicate region of validity, or a change in processing of OBU certificates • Field is already in CA (certificate authority) certificates • Currently RA is geographically limited • With TACKs, geographic validity of an OBU is application independent.

40. Additional Application for Certificate Requests • PSID – Provider Service Identifier • Need PSID reserved for the certificate requests • Request protocol could even be formed as an additional standard

41. Conclusions • TACKs improves key management while providing some privacy • A single key pair is associated with each OBU • No OBU revocation data sent to OBUs • Only an authority can identify the signer of a message • TACKs requires very few changes to the standard

42. Thank You 42