IEEE 1609.2-2016 Standard: Secure Wireless Access in Vehicular Environments

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

Where is IEEE 1609.2 used? Current: 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 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 OCTET STRING OCTET STRING Original Payload Hash of external data (opt.) Original Payload (opt.) Must have at least one Ieee1609Dot2Data HashedData Psid Time64 Time64 3DLocation HashedId3 MissingCrlIden. EncryptionKey 1609.2 type = unsecured Hash of external data Generation Location (opt.) P2PCD request (opt.) Missing CRL Identifier (opt.) 1609.2 version Original Payload Hash identifier Generation Time (opt.) Expiry Time (opt.) Encryption Key (opt.) PSID One or both of SIgnedDataPayload HeaderInfo Payload data Header Info ToBeSignedData Certificate Hash and sign Signer s private key ToBeSigned Data Signer s Certificate Certificate, certificate chain, or digest of certificate HashAlgorithm ToBeSignedData SignerInfo Signature Signer identifying data Hash identifier ToBeSigned Data Signature data Type Algorithm Ieee1609Dot2Data 1609.2 type = signed 1609.2 version SignedData 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 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. Signing Certificate Signed PDU signer signer_id PSID application permissions permits1 payload permitted geographic region2 transmission location3 contains generation time3 start validity time is equal to or before expiry time3 expiry time is equal to or after public key4 Issuer s signature5 signature NOTES: 1. Determined using the PSID and SSP. The process to determine whether the operational permissions permit the message payload is specified by the organization reserving the PSID and is out of scope for this standard. 2. Included per policy set by the appropriate authority for the region where the certificate is being used. 3. Optional. Inclusion of this data is as determined by the organization reserving the PSID. This data may be contained in the payload or within the security header fields. 4. For implicit certificates, the public key is derived rather than explicitly stated within the certificate. 5. Not included in an implicit certificate. 5

Message 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 Signer ID Start Signature Does the signature verify with the public key from the certificate? No Certificate Yes Public Key Is the certificate already known and trusted? Yes Signer ID No Signature Does the signature verify with the public key from the certificate? No CA Certificate Yes Public Key Is the certificate already known and trusted? Yes Signer ID No Signature Does the signature verify with the public key from the certificate? No CA Certificate Yes Public Key Is the certificate already known and trusted? Yes Signer ID No Signature Does the signature verify with the public key from the certificate? No Root Certificate Yes Public Key Is the certificate already known and trusted? Yes Signer ID No Signature Reject, cannot be trusted 6 Accept, valid Reject, invalid Certificate Chain Processing Flow

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) Relevance check (replay, freshness, locality) Valid / Invalid Data Received IEEE 1609.2 Signed SPDU Signer Certificate Valid / Invalid Consistency check Data Data Signature Signature Hash value Valid / Invalid Hash fn Verification Valid (all) / Invalid (any) Public key A Signer Certificate Known Valid CA Certificates (local) Chain is cryptographically valid Chain leads to a known certificate Permissions are consistent Valid / Invalid Received Certificates Other Certificate Certificate Certificates (optional) Revocation Information (local) Valid / Invalid Revocation check Received Certificates 7

Message Peer to peer certificate distribution Signer ID Start Signature Does the signature verify with the public key from the certificate? No Certificate Yes Public Key Is the certificate already known and trusted? Distributed with message Yes 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 Signer ID No Signature Does the signature verify with the public key from the certificate? No CA Certificate Yes Public Key Is the certificate already known and trusted? Yes Signer ID No Signature Does the signature verify with the public key from the certificate? May be distributed via P2PCD No CA Certificate Yes Public Key Is the certificate already known and trusted? Yes Signer ID No Signature Does the signature verify with the public key from the certificate? No Root Certificate Yes Public Key Already known Is the certificate already known and trusted? Yes Signer ID No Signature Reject, cannot be trusted Accept, valid Reject, invalid 8 Certificate Chain Processing Flow

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 Ieee1609Dot2Data 1609.2 type = unsecured 1609.2 version Original plaintext Recipient s public key source Symmetric key (fresh, random) Authentic- ated encryption Nonce 2 (fresh, random) Recipient s public key Nonce 1 (fresh, random) AesCcmCiphertext Public key encryption Authentic- ated ciphertext Nonce HashedId8 EncryptedDataEncryptionKey Encrypted symmetric key type SymmetricCiphertext Symmetric ciphertext type Encrypted symmetric key Symmetric ciphertext data Recipient ID Optional additional recipient infos for other recipients RecipientInfo RecipientInfo RecipientInfo RecipientInfo SymmetricCiph. Recipient Info type Recipient ID Encrypted key Recipient Info Recipient Info Recipient Info Symmetric ciphertext ... Ieee1609Dot2Data 1609.2 type = encrypted 1609.2 version Encrypted data 9

Privacy 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 App Security IP MAC MAC IP Pseudonym App Data 10

Future plans Corrigendum: 2nd 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 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) 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/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 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 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 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 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 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 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) 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 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 19

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 20