1 / 12

Permission Encoding in 1609

Permission Encoding in 1609. William Whyte, Security Innovation April 6 2010. Review: WSM routing with PSIDs. In 1609.3, a higher layer entity uses the WME- WSMService.request to register an interest in PSIDs

octavius-booker
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 6 2010

  2. 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.

  3. 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

  4. 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 used 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.

  5. 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

  6. 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?

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

  8. Service Specific Permissions • Permissions are encoded in a new field, separate from PSID: Service Specific Permissions (SSP) • 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: • 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

  9. 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?

  10. 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.

  11. SSP approach: Changes to 1609.3 • 6.4.2: SSP and PSID 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.

  12. User service request with notifi-cation

More Related