1. IEEE ™-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

2. 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 Q (certificate management), 2H 2017 (CRL distribution)

3. Where is IEEE 1609.2 used? Current: Future:
IEEE ™-2016 – for WAVE Service Announcement (WSA) security
SAE J2945/ , 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

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

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

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

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

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

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

10. Privacy Messages sent by vehicles contain multiple identifiers
App
Messages sent by vehicles contain multiple identifiers
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
allows signing certificate to change
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

11. 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 ; 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 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)

12. 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.
 Connected Vehicle Pilot Deployment Program Phase I, Security Management Operational Concept –Tampa (THEA)
Connected Vehicle Pilot Deployment Program Phase 1, Security Management Operational Concept–ICF/Wyoming

13. Questions?
Thomas M Kurihara mindspring.com William Whyte

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

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

16. Project Status (1)
IEEE Standards Association Standards Board approved in January 2016
IEEE ™ WAVE - Security Services
IEEE ™ WAVE - Multi-channel Operations
IEEE ™ WAVE - Networking Services
IEEE ™ WAVE - Identifier Allocation
Revision of IEEE Std ™ – 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

17. 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 , 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 months
Additional PARs will be discussed at the July meeting for corrigendum and other work on security

18. 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 meetings)

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

20. 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) 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) 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 , 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 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