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:
OCTET STRING
• 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
Original
Original
Payload
Payload
(opt.)
Ieee1609Dot2Data
1609.2
version
1609.2
type =
unsecured
OCTET STRING
Hash of
external
data (opt.)
Must have
at least one
HashedData
Original
Payload
Hash
identifier
Psid
Hash of
external
data
PSID
Time64
Time64
Generation Expiry Time
Time (opt.)
(opt.)
3DLocation
HashedId3
MissingCrlIden.
Generation
Location
(opt.)
P2PCD
request
(opt.)
Missing CRL
Encryption
Identifier
Key (opt.)
(opt.)
EncryptionKey
One or both of
SIgnedDataPayload
HeaderInfo
Payload data
Header Info
ToBeSignedData
Certificate
ToBeSigned
Data
Signer’s
Certificate
Hash and
sign
Signer’s
private key
Certificate, certificate chain, or digest of certificate
HashAlgorithm ToBeSignedData
Hash
identifier
ToBeSigned
Data
SignerInfo
Type
Signer
identifying
data
Signature
Algorithm
Signature
data
Ieee1609Dot2Data
1609.2
version
1609.2
type =
signed
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 applicationspecific 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_id
signer
PSID
application
permissions
permits1
payload
permitted
geographic region 2
contains
transmission
location3
start validity time
is equal to or before
generation time 3
expiry time
is equal to or after
expiry time 3
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...
Signer ID
Signature
Does the signature
verify with the
public key from the
certificate?
Certificate
Public Key
Is the certificate
already known and
trusted?
Signature
No
Does the signature
verify with the
public key from the
certificate?
CA Certificate
Public Key
Is the certificate
already known and
trusted?
Signature
No
Does the signature
verify with the
public key from the
certificate?
Public Key
Signer ID
Signature
Public Key
No
Yes
No
Yes
Is the certificate
already known and
trusted?
Yes
No
Does the signature
verify with the
public key from the
certificate?
Root Certificate
Yes
Yes
Signer ID
CA Certificate
No
Yes
Signer ID
• ....
• 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
Start
No
Yes
Signer ID
Is the certificate
already known and
trusted?
Signature
No
Yes
Accept, valid
Certificate Chain
Reject, invalid
Processing Flow
Reject, cannot
be trusted
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)
Data
Relevance check
(replay, freshness,
locality)
Valid /
Invalid
Consistency check
Valid /
Invalid
Verification
Valid /
Invalid
Received IEEE 1609.2 Signed
SPDU
Signer Certificate
Data
Data
Signature
Signature
Hash fn
Hash
value
Valid (all) /
Invalid (any)
Public
key A
Signer
Certificate
Other
Certificates
Certificate
Certificate
(optional)
Known Valid CA
Certificates (local)
Received
Certificates
Chain is
cryptographically valid
Chain leads to a known
certificate
Permissions are
consistent
Valid /
Invalid
Revocation check
Valid /
Invalid
Revocation
Information (local)
Received
Certificates
7
Message
Peer to peer
certificate distribution
Signer ID
Signature
Does the signature
verify with the
public key from the
certificate?
Certificate
Public Key
• 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
Start
Yes
Signer ID
Is the certificate
already known and
trusted?
Signature
No
Distributed with message
Does the signature
verify with the
public key from the
certificate?
CA Certificate
Public Key
No
Yes
No
Yes
Signer ID
Is the certificate
already known and
trusted?
Signature
No
Does the signature
verify with the
public key from the
certificate?
Yes
May be distributed via P2PCD
CA Certificate
Public Key
Signer ID
Signature
Yes
Is the certificate
already known and
trusted?
Public Key
Yes
No
Does the signature
verify with the
public key from the
certificate?
Root Certificate
No
No
Yes
Already known
Signer ID
Is the certificate
already known and
trusted?
Signature
No
Yes
Accept, valid
Certificate Chain
Reject, invalid
Processing Flow
Reject, cannot
be trusted
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
Ieee1609Dot2Data
1609.2
type =
unsecured
1609.2
version
Recipient’s
public key
source
Symmetric
key (fresh,
random)
Recipient’s
public key
Nonce 2
(fresh,
random)
Authenticated
encryption
Nonce 1
(fresh,
random)
AesCcmCiphertext
Public key
encryption
HashedId8
Nonce
EncryptedDataEncryptionKey
Recipient
ID
Encrypted
symmetric
key type
Original
plaintext
Authenticated
ciphertext
SymmetricCiphertext
Encrypted
symmetric
key
Symmetric Symmetric
ciphertext ciphertext
type
data
Optional additional recipient infos
for other recipients
RecipientInfo
Recipient
Info type
Recipient
ID
Encrypted
key
RecipientInfo
RecipientInfo
RecipientInfo
Recipient
Info
Recipient
Info
Recipient
Info
SymmetricCiph.
...
Symmetric
ciphertext
Ieee1609Dot2Data
1609.2
version
1609.2
type =
encrypted
Encrypted
data
9
Privacy
• Messages sent by vehicles contain multiple identifiers
App
• 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
MAC
IP
Pseudonym
App Data
• Does it need to work the same way for everyone?
• Harmonize with related work in IEEE 802p, IETF, ETSI, and
others
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
[email protected]
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