Security

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 RD, ECI Lab)
• Dr. Hariharan Krishnan (GM RD, 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
• T10 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 wont work if you cant link
  two different messages
• Call this Short Term Linkability

?
7
Public Key Infrastructure Works.

• Trusted authority signs a copy of each OBUs
  public key
• Every OBU gets a copy of the authoritys 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 years 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 Shachams 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
• Cant 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
Bumper-to-Bumper Traffic

• Inexpensive OBUs and RAs can support TACKs
• 260B average update overhead (1 request needed)

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 Shachams 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