1609'2 Security Status

1
1609.2 / Security Status
William Whyte, NTRU Cryptosystems March 25, 2009
2
Status

• V1.1
• Quick fix
• Since .3 references .2, .3 cant be a Full Use
  standard without a Full Use .2
• Need a Full Use .2 thats consistent with .3 / .4
  / 11p
• Also take the opportunity to fold in improvements
  from PoC
• V2
• Expansion
• Multiple security mechanisms
• Anonymity
• Still awaiting funding for both projects

3
Agenda

• V1.1 issues
• III comments
• Secured WSMs
• Fraunhofer comments
• WSAs
• Signed v unsigned
• PSC certification
• Signing timing info
• Geographic location and confidence
• V2 issues
• VSC(A)?
• Anonymity

4
V1.1
5
III Taiwan Comments

• 1. Editorial on contrast of encode and
  encrypt etc
• 2. Bug in ToBeSignedMessage format
• 3. Terminology ACID/ACM/ACF ? PSID/PSC
• 4, 5 Editorial

6
Secured WSMs

• WW recommendation
• Security is applied to WSM payload
• Applications know security format by reference to
  PSID
• No need for security field in WSM header
• Mark IV Comments
• Moving data path security to the application
  layer control and removing it from 1609.3 means
  security can't be added/removed at the MAC layer,
  adding some delays in processing, and potentially
  some hardware duplication since the application
  may not be resident on the same processor that
  hosts the WME and 1609.2 security.  If it were
  implemented though 1609.3 it was possible to do
  security processing at the MAC layer, although as
  William points out this causes issues about the
  stack needing access to application decryption
  keys. It may be worth having the option that an
  application can request the security processing
  be handled at the MAC layer.
• WW This seems like an implementation issue if
  identical OTA messages are processed identically,
  the on-unit architecture is not something 1609
  should care about.

7
Fraunhofer comments

• Editorial

8
Signed v Unsigned WSAs

• Consensus reached yesterday
• Some User applications require signed service
  announcements, some get security by other means
• 1609.3 will support both types and define
  security processing appropriately
• WW notes
• Unsigned WSA may need a format (header byte to
  denote unsigned) to save the security overhead
• The extensible framework weve agreed on is good
  the actual security mechanisms for applications
  that dont need signing are still TBD.
• Security will be defined by PSID
• Currently there are no PSIDs that allow unsigned
  WSAs
• Need to list mechanisms

9
PSC Certification

• The possible security models
• If Alice is trusted to offer a service with PSID
  p, she is trusted to offer that service with ANY
  PSC ? PSC not in certs
• Different PSCs have different effects on the
  behavior of the recipient and as such PSCs should
  be explicitly certified
• Offering a service with PSC A gives you more
  privileges than offering it with PSC B you could
  be entitled to offer with B but not A.
• ? PSC in certs
• If we go with option 1, CA has to police use of
  PSC
• If we go with option 2, PSID owner has to police
  semantics of PSC

10
Securing timing information

• Currently
• Timing information (UTC offset) is added to
  outgoing WSA packet by the MAC layer
• Received timing information is used to update
  onboard UTC
• Onboard UTC is also updated by GPS (is this
  true?)?
• Assumptions
• All devices have GPS
• If timing information is not secured, an attacker
  can roll a victims clock backwards or forwards
• Backwards denial of service attack
• Forwards get victim to emit message that can be
  replayed at the victims perceived time
• Other attacks?

11
Securing timing information

• Possible countermeasures (brainstorm)?
• None, the cost of countermeasures outweighs the
  importance of the attack
• Allow GPS to set UTC arbitrarily only believe
  WSA-based timing information within a threshold
  of GPS
• Include timing information in other frames,
  including frames emitted by vehicles reject
  outliers
• Sign timing information drawback is that
  checking signature has significant overhead, such
  as constructing cert chain and checking
  revocation status, that may be inappropriate for
  MAC layer processing
• Possible approach
• Threat Model Analysis (TMA) to ensure that (a)
  attacks are thoroughly listed (b) impact of
  attacks is understood
• Look at other systems where timing information is
  carried in MAC layer
• Identify differences between those systems and
  1609/802.11p
• Survey existing solutions
• Return to group with TMA, list of solutions, and
  analysis of whether difference between those
  solutions settings and 1609/802/11p affects the
  applicability of the solution to 1609/802.11p

12
Forwarding

• Other proposed ITS comms architectures allow
  forwarding
• CALM, ETSI ITS
• Not built into the 1609 network stack
• Currently forwarding (and repeated transmission)
  may be done at the application layer
• Does 1609.2 prevent this?
• Distinction between origin and transmission
  location of message
• Should we review this for v1.1?

13
Geographic location and confidence

• SAE J2725 have defined a new geographic location
  format
• Should we use it?
• Confidence? One confidence for all? 1609.2 is
  ambiguous but current implementations apply
  confidence to (lat, long) and dont use elevation

14
V2
15
Proposed requirements from Mark IV

• Some applications want end-end security
  mechanisms.  This may be even more important if
  we go to WSM-forwarding or geo-routed WSM
  messages.
• Some implementations may want the security
  handled in the same host as the WME, even though
  the application runs in a different host, for
  cost or delay reasons
• Different devices operating in the same PSID may
  wish different grades of security within the same
  security mechanism.  They may negotiate this as
  part of the application communication.
• Security applied can vary by message within an
  application.  For example in the POC tests on
  payment applications, some messages were just
  signed, others were fully encrypted.   The first
  element of the application data field contained a
  message ID and security required was tied to
  message ID.
• Application security mechanisms should cover both
  IP and WSM data.

16
VSC(A), different security mechanisms, and
conformance

• VSC(A) research is ongoing expect to have final
  recommendation for June meeting
• VSC concern about missing v1.1 so that VSC(A)
  applications cannot claim 1609.2 compliance
• WW response
• 1609.2 security is optional for application
  messages (but mandatory for WSAs)?
• Any form of application security is currently
  1609 compliant even if it doesnt implement
  1609.2
• 1609.2 v2 is expected to list a set of security
  mechanisms. It may then be the case that
  applications must use one of those mechanisms
• If this is the case, when we select the
  mechanisms to include, we will be favorably
  disposed to considering the inclusion of
  mechanisms that are already in use or have strong
  industry backing
• Thoughts?

17
Propose sub working group to address this complex
issue
ANONYMITY
18
Overview

• Threat model
• Aspects of solution

19
Threat model

• What can attacker do?
• Big brother govt
• Little brother private investigators
• What do we want to prevent attacker from doing?
• Possible goal Tracking a vehicles DSRC/WAVE
  transmissions is not the cheapest way
• to know exactly where a specific vehicle is
• to gather evidence that will stand up in court
• to obtain information that warrants further
  investigation
• Cost (cost to deploy tracking solution /
  probability of success) risk factor

20
(No Transcript)
21
(No Transcript)
22
(No Transcript)
23
Threat model tracking device

• Probability of success affected by
• Probability of successfully installing device
• Possibility that device is dislodged or detected
• Probability of successfully retrieving
  information from device
• Risk factor affected by
• Can device be linked back to attacker?
• What are consequences of being caught tracking?

24
Threat model tracking manually

• Car 100/day
• Muscles 50/hr, double time 12 pm 8 am
  1600/day
• Total cost to track for a week 10,000
• Probability of success affected by
• Probability of successfully finding target
• Possibility of successfully tracking
• Risk factor affected by
• Is tracker detected?
• Can tracker be linked back to attacker?
• What are consequences of being caught tracking?

25
Threat model tracking via DSRC/WAVE

• One RSU lt 5000
• Fraunhofer Fokus estimate cost to eavesdrop on
  all 900 km2 of Berlin
• 250,000 for enough RSUs
• backhaul cost
• (Relatively cheap over dedicated WiMax?)?
• operational cost
• Probability of success affected by
• Linkability of messages
• Ability to make a single observation linking
  vehicle and known message
• Risk factor affected by
• Is detection system detected?
• Can detection system be linked to attacker?
• What are consequences?
• Consequences differ for govt v non-govt actors

26
Threat model conclusions

• Determining the exact threat model is not a job
  1609 can do on its own
• Need input from policymakers

27
Solution outline

• Change vehicle identifiers periodically (message
  syntax)?
• Prevent linking messages using trajectory
  information inside those messages (message
  semantics)?
• Authenticate messages and provide means to
  withdraw permissions (cert/key management)?

28
Aspects of solution

• Synchronize identifier change on stack in vehicle
• MAC address, IP address
• Synchronize identifier change across vehicles
• Timing of identifier change / prevent tracking
  using message content
• Certificate format and management on-vehicle
• If an attacker compromises a vehicle, what can
  they do?
• Certificate management policies
• Preventing insider attacks

29
Unlinkability
30
Unlinkability
31
Unlinkability
32
Structure of work

• V1.1
• Synchronize identifier change on stack in vehicle
• V2
• Certificate format and management on-vehicle
• Synchronize identifier change across vehicles
• Possibly outside 1609.2
• Timing of identifier change / prevent tracking
  using message content
• Preventing insider attacks