IEEE 1609 22016 Standard for Wireless Access in

IEEE 1609. 2™-2016, Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages T. M. Kurihara, Chair, IEEE 1609 Working Group W. Whyte, Vice-Chair, IEEE 1609 Working Group ITU-T CITS Tokyo, Japan July 5, 2016

Overview • SCOPE • “…defines secure message formats and processing for use by Wireless Access in Vehicular Environments (WAVE) devices, including methods to secure WAVE management messages and methods to secure application messages. It also describes administrative functions necessary to support the core security functions. ” • 1609. 2™-2016 published March 2016 • Secure Protocol Data Unit (PDU) format: signed data, encrypted data • Certificate format: • Certificates for signing application PDUs: pseudonymous (no identification of sender) and identified • Certificates for Certificate Authorities (CAs) • Certificate revocation list (CRL) format • Peer-to-peer certificate distribution to allow devices to “learn” unknown certificates • Future work: • Certificate management (certificate request from the Security Credentials Management System) • Certificate Revocation List (CRL) distribution • Both will be based on output of research projects within CAMP (Crash Avoidance Metrics Partnership, a pre-competitive association of US vehicle OEMs that engages subject matter experts for research projects) • Source material expected to be available in Q 3 2016 (certificate management), 2 H 2017 (CRL distribution) 2

Where is IEEE 1609. 2 used? • Current: • IEEE 1609. 3™-2016 – for WAVE Service Announcement (WSA) security • SAE J 2945/1 -201603, On-Board System Requirements for V 2 V Safety Communications, for Basic Safety Message (BSM) security • Future: • SPa. T/MAP/TIM – infrastructure to vehicle communications • PSM – pedestrian safety message • Public safety messages – signal pre-emption, … • Particularly suited for scenarios where: • One sender sends to many receivers • AND each receiver receives from many senders • In other settings (e. g. , persistent secure sessions), a different security mechanism may be appropriate 3

Constructing an IEEE 1609. 2 signed PDU • Signed PDU contains • At least one of: • Payload • Hash of external payload • Provider Service ID to indicate permissions • Optional additional header fields – generation time, expiry time, generation location, security management fields • Reference to signing certificate (certificate itself or hash of certificate) • Signature 4

Consistency between signed Secured PDU (SPDU) and signing certificate • Certificate contains one or more pairs of (PSID, Service Specific Permissions (SSP)) • Only one instance of each Provider Service ID (PSID) • Signed SPDU states which PSID applies to it • Receiving higher layer checks using applicationspecific logic whether payload is consistent with PSID and SSP • Example: SSP for BSM could say whether certificate holder is entitled to set “Lightbar. In. Use” field. 5

Certificate chain • Message is signed by a certificate • Certificate is issued by a Certificate Authority certificate… • . . . which in turn is issued by a higher CA certificate. . . • . . . S • which in turn is issued by a higher CA certificate. . . • Chain ends at a “root” certificate which issued itself • At least one certificate in the chain must already be known and trusted by a receiver in order for them to be able to trust the message 6

Full set of verification checks • To be valid an SPDU needs to meet all conditions (from the bottom up): • No certificate in the chain is revoked • Signing certificate chains to an already-trusted CA certificate • Signature verifies • Payload is consistent with paired PSID/SSP and other permissions in certificate • Message is relevant (sufficiently recently generated, not expired, sufficiently close if that matters, not a replay if that matters) 7

Peer to peer certificate distribution • Receiver needs to be able to construct a chain from the message signing certificate to a known root • Receiver can use a field in their own outgoing signed messages to request the unknown certs received from other senders • Protocol supports multiple requesters and responders simultaneously while including throttling mechanism to prevent flooding Distributed with message May be distributed via P 2 PCD Already known 8

Encrypted data • Encrypt data with a one-time symmetric key • Encrypt symmetric key with the persistent public key of the receiver • To sign encrypted data or encrypt signed data, apply the two mechanisms one after the other 9

Privacy App • Messages sent by vehicles contain multiple identifiers • 1609. 2 certificate, source address, application-level ID field • If an eavesdropper sees two messages in two locations with the same identifier this is likely to be the same vehicle Security • Eavesdropper with widespread eavesdropping capabilities can track vehicles IP 1609. 2 allows signing certificate to change 1609. 4 allows source MAC address to change No 1609 standard addresses synchronization of changes, though there is a draft standard addressing this in ETSI • Additional considerations: • • Need to inhibit change during an alert state where short-term tracking is important? • How should this work in a multi-application setting? MAC IP Pseudonym App Data • Does it need to work the same way for everyone? • Harmonize with related work in IEEE 802 p, IETF, ETSI, and others 10

Future plans • Corrigendum: 2 nd Half 2016 • Some minor bug fixes • Once that is done the “core” functionality is expected to be stable indefinitely • Amendment(s) • Add informational material – could be done 2 H 2016 • Identifier change synchronization and other privacy considerations • Certificate learning when P 2 PCD is not possible, for example when learner is not sending messages of the same type • Include certificate management – start 2 H 2016, complete 2017 • Include CRL distribution – start 2 H 2017, complete 2018 • Systems engineering guidance – out of scope of 1609. 2; but necessary for deployment • Deployers must address all these questions, 1609 may provide guidance documents or they may come from another source • When to use 1609. 2 versus other security mechanisms • Other security mechanisms appropriate for CV and C-ITS settings • Physical and other security requirement to demonstrate that a device is secure enough to be validly issued with certificates • Interactions with CAs • Technical (via protocol to be defined) • Business (via certificate issuing policy) 11

Links of Interest • These documents describe implementation of security architecture(s) and touch on how privacy is being operationalized, among other things for the connected vehicles pilot projects in the U. S. • http: //ntl. bts. gov/lib/59000/59264/FHWA-JPO-16 -312. pdf • Connected Vehicle Pilot Deployment Program Phase I, Security Management Operational Concept –Tampa (THEA) • http: //ntl. bts. gov/lib/59000/59237/FHWA-JPO-16 -288. pdf • Connected Vehicle Pilot Deployment Program Phase 1, Security Management Operational Concept–ICF/Wyoming 12

Questions? Thomas M Kurihara tkstds@ mindspring. com William Whyte wwhyte@securityinnovation. com 13

Supplemental Information T. M. Kurihara IEEE VT/ITS Chair, IEEE 1609 Working Group 14

IEEE 1609 Standards Status (07/2016) • IEEE 1609 Project update • IEEE 1609 Working Group Meetings • July 26 -27, CALTRANS, San Diego, CA • September 1, CETECOM, Milpitas, CA • August 30 -31, SAE J 2735 meeting, CETECOM • July 28, meet with IEEE Registration Authority Committee (RAC) regarding PSID registry and public listing of assigned identifiers extract from 1609. 12 15

Project Status (1) • IEEE Standards Association Standards Board approved in January 2016 • • IEEE 1609. 2™-2016 -- WAVE - Security Services IEEE 1609. 4™-2016 -- WAVE - Multi-channel Operations IEEE 1609. 3™-2016 -- WAVE - Networking Services IEEE 1609. 12™-2016 -- WAVE - Identifier Allocation • Revision of IEEE Std 1609. 0™-2012 – WAVE - Architecture, in development, align to contents of revised standards • Project Authorization Request (PAR) approved in June • Plan for 9 -12 month development, or less, ballot and approval to follow 16

Project Status (2) • Project Authorization Request (PAR) for P 1609. 2 a, WAVE - Security Services for Applications and Management Messages - Amendment Certificate Management • Note: Submitted for consideration and approval by IEEE New Standards Committee (NESCOM) in June 2016 • Scope: provides additional test vectors…, examples for material in IEEE Std 1609. 2 -2016, and additional certificate management features • Proposed changes will be backward compatible • PAR is active for 4 years, project plan is to develop and approve amendment in 12 -18 months • Additional PARs will be discussed at the July meeting for corrigendum and other work on security 17

Project Status (3) • Revision of IEEE 1609. 12 • Create process and procedures for requesting, allocating, and maintaining a register of Provide Service Identifier (PSID), considerations include: • IEEE Registration Authority Committee (RAC) Policy, Terms of Reference, and Conventions • IEEE 1609 WG PSID sub-group (SG) structure, composition, roles and responsibilities, part of RAC process (proposed) • Remove allocated PSID list from standard, post to IEEE RAC site • Establish process for IEEE 1609 WG to review, approve requests for allocation of PSIDs collaborating with SAE J 2735 TC, and coordinate posting of approved identifiers with IEEE RAC Administrator • Coordination for international allocations of PSIDs (a. k. a. , ITS-AID) to follow and in collaboration with US-EC HTF, HTG#7 task for a global ITS registries (June 2016 meetings) 18

Project Status (4) • IEEE Vehicular Technology/ITS • Sponsor organization in IEEE Standards Association for following standards working groups • 1609 WAVE standards working group • Std 2030. 1. 1 -2015, Standard for Technical Specifications of a DC Quick Charger for Use with Electric Vehicles • P 2030. 1. 2, Standard for Charging Network Management Protocol for Electric Vehicle Charging Systems • P 2020, Standard for Automotive System Image Quality • P 2020 and P 2030. 1. 2 PARs submitted for consideration at IEEE NESCOM meeting, June 2016 and were approved 19

ETSI TC-ITS WG 5 - Security List of security work items reported during the ETSI TC-ITS plenary and working group meetings, Jun 27 -Jul 1 • ITSWG 5(16)000039 - Design principles for C-ITS short term certificate policy, input document from EC C-ITS WG 5 to ETSI on Design principles for short term certificate policy • ITS(16)000090 - Identified C-ITS Security Standardisation needs of the C-ITS Platform WG Security , input document from EC C-ITS WG 5, Platform • Revision of TR 102 893 V 1. 2. 1, Intelligent Transport Systems (ITS); Security; Threat, Vulnerability and Risk Analysis (TVRA); Clause 6 revised to include privacy provisions applicable to the Netherlands • Revision of TS 102 941 V 2. 1. 1, Intelligent Transport Systems (ITS); Security; Trust and Privacy Management (included contribution from Security Innovation of SCMS Proof of Concept by Security Innovation); DER messages encoding for protocols with PKI for Plugtest in November • Revision of TR 103 415, Pseudonym change strategies, joint project with ETSI TC-ITS WG 2 • Test standards developed and approved for November 2017 Plugtest in Livonia, Italy • BSI contribution presented by Annika Strobel (Bosch) for discussion on choice of next crypto curves for ETSI standardisation (Brainpool curves proposed by BSI) • Revision of TS 103 097 Intelligent Transport Systems (ITS); Security; Security header and certificate formats (to be sent for approval following Plugtest results in November 2016); Backward compatible CRs considered, others either to be considered for NWI or in revision of current draft 20