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 1609.2™-2016 published March 2016 Future work: “…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 Q3 2016 (certificate management), 2H 2017 (CRL distribution)

Where is IEEE 1609.2 used? Current: Future: IEEE 1609.3™-2016 – for WAVE Service Announcement (WSA) security SAE J2945/1-201603, On-Board System Requirements for V2V Safety Communications, for Basic Safety Message (BSM) security Future: SPaT/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

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

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 application- specific logic whether payload is consistent with PSID and SSP Example: SSP for BSM could say whether certificate holder is entitled to set “LightbarInUse” field.

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

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)

Peer to peer certificate distribution Distributed with message 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 May be distributed via P2PCD Already known

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

Privacy Messages sent by vehicles contain multiple identifiers 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 Eavesdropper with widespread eavesdropping capabilities can track vehicles 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? Does it need to work the same way for everyone? Harmonize with related work in IEEE 802p, IETF, ETSI, and others Security IP MAC MAC IP Pseudonym App Data

Future plans Corrigendum: 2nd Half 2016 Amendment(s) 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 2H 2016 Identifier change synchronization and other privacy considerations Certificate learning when P2PCD is not possible, for example when learner is not sending messages of the same type Include certificate management – start 2H 2016, complete 2017 Include CRL distribution – start 2H 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)

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/59200/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/59200/59237/FHWA-JPO-16-288.pdf Connected Vehicle Pilot Deployment Program Phase 1, Security Management Operational Concept–ICF/Wyoming

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

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

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 J2735 meeting, CETECOM July 28, meet with IEEE Registration Authority Committee (RAC) regarding PSID registry and public listing of assigned identifiers extract from 1609.12

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

Project Status (2) Project Authorization Request (PAR) for P1609.2a, 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

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 J2735 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)

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 P2030.1.2, Standard for Charging Network Management Protocol for Electric Vehicle Charging Systems P2020, Standard for Automotive System Image Quality P2020 and P2030.1.2 PARs submitted for consideration at IEEE NESCOM meeting, June 2016 and were approved

ETSI TC-ITS WG5 - Security List of security work items reported during the ETSI TC-ITS plenary and working group meetings, Jun 27-Jul 1 ITSWG5(16)000039 - Design principles for C-ITS short term certificate policy, input document from EC C-ITS WG5 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 WG5, Platform Revision of TR 102 893 V1.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 V2.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 WG2 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