1 / 25

Permission Encoding in 1609

Permission Encoding in 1609. William Whyte, Security Innovation April 7 2010. Overview. Amended slides from April 6 th Slides for April 7 th : Review April 6 th conclusions Multiple PSIDs in certs Implementation details. Amended April 6 th slides. Review: WSM routing with PSIDs.

peri
Download Presentation

Permission Encoding in 1609

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Permission Encoding in 1609 William Whyte, Security Innovation April 7 2010

  2. Overview • Amended slides from April 6th • Slides for April 7th: • Review April 6th conclusions • Multiple PSIDs in certs • Implementation details

  3. Amended April 6th slides

  4. Review: WSM routing with PSIDs • In 1609.3, a higher layer entity uses the WME-WSMService.request to register an interest in PSIDs • Any WSM received with that PSID in the WSM Header will be routed to every entity that has requested that PSID. • An entity may request multiple PSIDs, and a PSID may be requested by multiple entities. • An entity may request PSIDs that it does not send on or vice versa. • Example: SAE J2735 Emergency Vehicle Alert will be received but not sent by end-user vehicles.

  5. Permission enforcement • A sender states what permissions it’s claiming and gives proof that it’s entitled to those permissions • In 1609.2-2006: • Permissions are encoded by PSID • PSID appears in header of signed message • PSID appears in certificate • A certificate is a statement of the holder’s permissions, made by a trusted third party • If a higher layer entity receives a message on a requested PSID, signed and with an appropriate cert attached, can be trusted. • So PSIDs are used both for routing and for permission encoding

  6. Motivation for discussion • A message set may contain optional fields that should only be set by certain types of sender • Take example of SAE J2735 Basic Safety Message (BSM) • For example, “Light bar in use” should only be transmitted by emergency / public safety vehicle • “Tire pressure” should not be used by handheld devices • SAE J2735 Emergency Vehicle Alert (EVA) • Allows vehicle to say what type it is • Types (“IncidentResponseEquipment”) range from privately-owned-vehicle to ambulance to boat. • We don’t want a sender to set fields that they are not entitled to set • Receiving vehicles may build up an inaccurate Local Dynamic Map • “there’s a boat on the highway” • Fields may give the sender an advantage • If I say my lightbar is in use or that I’m an ambulance other vehicles may give me priority, even if I don’t have a lightbar • If we use a single PSID to denote BSM, then the current permissions mechanism does not grant permissions in a granular enough way.

  7. Options for using permissions • Permissions are only enforced at the message set level • If a device can send any message from a set, it can send all messages from that set • Use multiple PSIDs per message set to encode permissions with more granularity • For BSM, one PSID for “Ordinary vehicle”, one for “Tow Truck”, one for “Ambulance”, one for “Handheld”, … • For EVA, one PSID for each vehicle type? • Use a single PSID per message set but define an additional field, Service Specific Permissions (SSP), to encode the sender type • One SSP for “Ordinary vehicle”, one for “Tow Truck”, one for “Ambulance”, one for “Handheld”, … • Review the options on the next slides

  8. Permissions enforced at message set level • If a device can send any message from a set, all messages from that set will be accepted from it • EVA cert allows any EVA message • BSM cert allows any sender to claim they have their lightbar on • Anyone who can • compromise a unit, or • extract keys from a unit can send incorrect messages • Advantages: routing and permissions can be handled by the same mechanism; consistent with 1609.2-2006 • Disadvantages: • This is a problem if: • Inaccurate information is a problem, even if it does not involve an escalation of privileges (boat on the highway) • Different messages in the set have significantly different permissions • All future message set development must be policed to ensure that messages in a message set have similar privileges • But note that message set developers must be aware of differing privileges under any of the models in this presentation • Policing can be done by IEEE-RA as part of PSID issuance?

  9. Multiple PSIDs per message set • Use multiple PSIDs per message set to encode permissions with more granularity • For BSM, one PSID for “Ordinary vehicle”, one for “Tow Truck”, one for “Ambulance”, one for “Handheld”, … • For EVA, one PSID for each vehicle type? • Advantage: Allows granularity of permissions without changing current messages • Disadvantage: • Uncomfortable to use PSIDs both for routing and for security • Will require an end entity to register to receive on many more PSIDs than was otherwise the case • If we add PSIDs to a message set, existing applications will not receive on new PSIDs unless upgraded1. 1. One undiscussed approach to this is to define a “permission upgrade message”, signed by application deployers, which can be sent by units that use new PSIDs

  10. Service Specific Permissions • Permissions are encoded in a new field, separate from PSID: Service Specific Permissions (SSP) • For BSM, one SSP for “Ordinary vehicle”, one for “Tow Truck”, one for “Ambulance”, one for “Handheld”, … • For EVA, one SSP for each vehicle type? • Advantage: • Separates security from routing • Extensible – if permissions to set specific fields in a message are bitmapped, easy to define more • Disadvantage: Major change to standard, probably makes things a lot more confusing

  11. SSP approach: open questions • How can we optimize bandwidth? • Fixed-length SSP? If so how long? • Single SSP in cert to allow it to be omitted from message? • Multiple PSIDs per cert to allow us to send fewer certs? • How does it integrate with WSA? • Is SSP encoded separately in WSA from PSC? • How is service matching performed?

  12. SSP approach: Changes to 1609.2 primitives • 7.4.2.1, WAVESecurityServices-SignedMessage.request • Add SSP to the parameter list. • 7.4.4.2, WAVESecurityServices-SecuredMessageDataExtraction.request • Add the following to the parameter list, depending on decisions made in the meeting: • SSP from the message • SSP(s) from the certificate. • 7.5.2.1, WAVESecurityServices-SignedWsa.request • Change "PSID and Priorities" to "(PSID, Priority, SSP)" • 7.5.3.2, WaveSecurityServices-SignedWsaValidation.confirm • Add the following to the parameter list, depending on decisions made in the meeting: • For each PSID in the WSA: • the list of SSPs extracted from the cert • potentially the SSP extracted from the WSA, if we decide to encode the SSP separately from the PSC.

  13. SSP approach: Changes to 1609.3 • 6.4.2: SSP from the WSA need to go into the AvailableServiceInfo • 7.4.2.2 WME-ProviderService.Request • Add a parameter specifying the SSP. • 7.4.2.4 WME-UserService.Request • Add a parameter specifying the SSP. • A User Service may need to specify all the SSPs that it will accept.

  14. User service request with notifi-cation

  15. April 7th: Review, Open questions, implementation details

  16. April 6th conclusions: Messages • Support optional field, the Service Specific Permission (SSP), in message certs • SSP is application information that is authorized, contained in a certificate, and passed around but not written or read by 1609.2 security processing • Variable-length SSP, length encoded in a single octet, max length 31 octets • Application Specification Organizations (“vendors”) define syntax and semantics • SSP syntax and semantics are specific to the sending PSID, though vendors may (of course) reuse syntax and semantics across all the PSIDs they control • Certs may only contain a single SSP for a given PSID • The SSP associated with a message is obtained from the accompanying or referenced cert

  17. April 6th conclusions: WSAs • Support optional SSP in WSA and WSA certs • Agree that if cert has single SSP for a given PSID, that SSP may be omitted from the relevant ServiceInfo in the WSA • Certs may contain multiple SSPs for a given PSID • If so, the relevant ServiceInfo must explicitly state its SSP • WW and JM have discussed necessary changes to 1609.3 and it seems possible to integrate SSP cleanly into existing 1609.3 WME processes • WW will make a comment on 1609.3 to enable this integration during sponsor ballot

  18. Multiple PSIDs in Certs: Background • A message cannot be accepted until the receiver has seen the sender’s cert • If the receiver has already seen the sender’s cert, the message can include a reference to the cert rather the cert itself • Bandwidth due to cert: ~120 bytes • Bandwidth due to reference: 10 bytes • Basic idea: reduce the number of times per second that sender includes the cert in a message to save bandwidth

  19. Sending certs occasionally: single PSID • Say we send heartbeats at 10 Hz, but certs only at 2 Hz • Delay of up to .5 seconds before receiver can trust a message • Two vehicles approaching each other at 120 km/h • Relative speed 66 m/s • With 300m radio range and cert available immediately, 4.5 seconds to react • Cert sent at 2 Hz: • Say 80% transmission success: 80% chance of 4 s to react, 96% chance of 3.5s, 99.2% chance of 3s. • Say 50% transmission success: 50% chance of 4s to react, 75% chance of 3.5s, 87.5% chance of 3s, 97% chance of 2s, 99% chance of 1s • Reasonable assumption: There is some transmission success %age at which it makes sense to send certs less frequently than messages • Note that omitting certs reduces bandwidth use and will improve transmission success %age

  20. Multiple PSIDs in cert: advantage • Bandwidth savings • Assume Application A sends a times per second • Application B sends b times per second • If we have one cert per PSID and send certs every message, total overhead is (a+b) * cert size • If we have one cert per PSID and send certs every half-second, total overhead is 4 * cert size • This is assuming that a and b are both >= 2 • Actual figure is ((min (a,2)) + (min (b,2))) * cert size • If we have multiple PSIDs per cert and send certs every half-second, total overhead is 2 * cert size

  21. Multiple PSIDs in cert: disadvantage: privacy • Note: Only a disadvantage for anonymous vehicles • Identified vehicles (emergency / public service) and RSEs have no requirement for anonymity; there is no barrier to multiple PSIDs per cert for those units. • Distinguishing • Say vehicle 1 has cert with PSIDs A and B • Say vehicle 2 has cert with PSIDs A and C • Then even if vehicle 1 and vehicle 2 only use PSID A at a given time, they can be distinguished by their certs • Leaking irrelevant information • Say vehicle 1 has cert with PSIDs A and B • Should anyone who receives on PSID A even know that vehicle 1 can send on PSID B?

  22. Discussion • WW preferred solution all else being equal: anonymous certs can only contain a single PSID / SSP. • This may not be acceptable due to bandwidth • List of SAE message types on the next slide • Does SAE think there are collections of message types that will: • All be sent from an anonymous vehicle • Have distinct PSIDs each sent multiple times a second • If no, perhaps bandwidth gain from multiple PSIDs is minimal • If yes, bandwidth gain from multiple PSIDs is worth pursuing • One possible mitigation for privacy attacks: • Explicitly list the PSIDs corresponding to the criteria above • Require that if an anonymous cert contains any one of those PSIDs, it contains all of them • Requires that any vehicle that can send any of those message types is in principle permitted to send all of them

  23. SAE J2735 message types • A la Carte • Basic Safety Message • Common Safety Request • Emergency Vehicle Alert • Intersection Collision Avoidance • Map Data • NMEA Corrections (Differential GPS) • Probe Data Management • Probe Vehicle Data • Roadside Alert • RTCM Corrections (Differential GPS) • Signal Phase and Timing • Signal Request • Signal Status • Traveler Information • Basic Safety Message – Verbose

  24. Open questions • How do we encode multiple SSPs? • Option 1: Length-of-all-SSPs field, limited to 1 byte. • Option 2: Set top bit of length-of-this-SSP field to indicate last SSP in an array

More Related