This presentation by OnBoard Security's Drew van Duren was given at the IEEE 4th World Forum on Internet of Things 05-08 February 2018 in Singapore. Topics covered include: – Connected Vehicle Architectures and Applications – IEEE 1609.2 V2X security stack and uses – Issues and Lessons Learned in U.S. CV Pilots – Potential Unmanned aircraft systems (Drones) applications – Re-tasking V2X security to other uses

1. Locking Down and
Re-Using V2X Security:
Lessons for Smart Cities

2. Agenda
§ V2X Security and the U.S. Connected Vehicle Pilots
– Connected Vehicle Architectures and Applications
– IEEE 1609.2 V2X security stack and uses
– Issues and Lessons Learned in U.S. CV Pilots
§ V2X Security: Tools for Smart Cities
– Potential Unmanned aircraft systems (Drones) applications
– Re-tasking V2X security to other uses
2JANUARY 31, 2018ONBOARD SECURITY

3. Connected Vehicle Architecture - Communications
§ CV “Applications” => What we want to ‘do’
§ Architecture => Framework for doing it ’in’
– Connected Vehicle Implementation
Architecture (CVRIA)
– Entities, Views, Message Flows
§ Connected Vehicle Data Dictionary
– SAE J2735 => Basic Safety Messages,
Traveler Information, Map, Signal Phase,
Signal Request, Signal Status, etc.
§ IEEE 1609 Transport services (local
broadcast or network)
§ IEEE 1609.2 Security services
Bus ASD +
Light-Duty Vehicle
ASD +
Truck ASD
Roadside Equipment
(RSE)
ITS Roadway
Equipment
NYCDOT Traffic
Management Center
(TMC)
Bus Databus +
Light-Duty Vehicle
Databus +
Truck Databus
Light-Duty Vehicle
Operator +
MTA Operators +
Truck Operator
Light-Duty Vehicle
Operator +
MTA Operators +
Truck Operator
Vehicle Intersection
Warning
RSE Intersection
Safety
Roadway Signal
Control
TMC Intersection
Safety
TMC Signal Control
Event Data
Collection
Location
Determination
Host
Vehicle
Status
(PP)
Local Accelerometers
Event Data Analysis
& Archive
Alerts
Monitor
RSE
Status
(VPN)
(2B) signal control commands
(OOS)
(2B) signal control status
(OOS)
(2B) intersection safety
application info
(SNMP)
(2B) intersection safety
application status
(SNMP)
(1A) intersection
control status +
conflict monitor
Status (VPN)
BSM
(1609-s)
SPaT (1609-s)
MAP (1609-s)
Intersection
Geometric
Data
(SNMP)

4. Connected Vehicle
Applications
§ Variety of ‘applications’
supported by the
CVRIA architecture
§ Some have been test-
deployed
§ Many-to-many
association between
Apps and J2735 Data
Dictionary messages

5. § DSRC/WAVE – a suite of
standards
§ IEEE 1609.2 is an application-
to-application security layer,
independent of the transport
§ Secures machine-to-machine
(application to application)
communications
IEEE 1609.2 V2X Security Stack
UDP / TCP
LLC
PHY
WAVE MAC
(including channel coordination)
IPv6
WSMP Networking
Protocols
1609.3
1609.12
1609.2
Management
Security
1609.4
802.11
Higher layer standards
1609.11
WSMP Transport
Protocols

6. Uses of 1609.2 in V2X
§ Vehicle-to-Vehicle (V2V) and Vehicle-to-Infrastructure (V2I) message security
– Authentication (Private key signing)
§ Basic Safety Messages (automotive equivalent of ADS-B) using small, implicit certificates (useful
in bandwidth constrained environments)
– Integrity – Protection from message tampering (provides detection forged messages)
– Replay Protection (timing and message equivalency consistency checks)
– Confidentiality – Encrypt, using public key, to a private key holder (mostly used with V2I)
– Geographic consistency - Certificates can be constrained to a Geographic area (native
certificate-based geofencing). Message recipients can validate that the message sender
was authorized to communicate a given message ‘in a given area’
– Fine-grained Permissions (Service Specific Permissions – SSP)
§ Ability to define for a given vehicle what authorizations it has to send certain message content. For
example, first responders may sign and transmit a traffic signal preemption command, but no one
else can.
§ Inherent authorizations WITHOUT an AUTHORIZATION SERVER and network connection

7. 1609.2 Credential SSP Message Authorization
PSID A
SSP
SSP
Application
Identifier
Service-Specific
Permissions
(SSP)

8. Issue: Application Security vs. Regional
Architectures
§ Applications operate between:
– Traffic Management Centers (TMC)
– Roadside Equipment (RSE)
– Vehicle Onboard Equipment (OBE)
– Other online service providers
§ Vehicles are mobile and need to interoperate with other regions’
infrastructures
– They may not have real-time connectivity to any central coordination
service ==> application logic must be fully specified ahead of time and
configurable using only local means
§ Goal: Consistent application security properties between regions
§ Impediment: One region’s architecture may not fit the security
assumptions of the application designer
§ Where are application security configurations and assumptions reflected?

9. Application Security Profiles
§ Simplify the job of an application
designer in specifying how to use
1609.2 security services
§ Determine proper security behavior of
sender and receiver
§ Specify which consistency checks
(geospatial, temporal), replay
detection (yes/no), etc. to perform
§ Specify messaging behavior, crypto,
time/location tolerances (timeouts),
when to re-sign, re-verify, when to
encrypt, etc. for:
– Sending
– Receiving
– Security (Certificate) management

10. Example
§ Roadside Unit (RSU) Placement Impacts
– Architecturally: One CV Pilot site signs TMC information in the RSU. The other
sites sign the messages at the TMC (gaining end-to-end integrity and source
authentication protections)
– Result: Different architectures demanded differences in security profile settings
– Result: Vehicles driving in one of the cities may not ‘behave’ correctly when
receiving equivalent application messages in the other city.
– Application designer’s assumptions may be false and security vulnerabilities may
emerge
– Vehicles are mobile – They WILL move between the different regions, therefore
vehicle will have to become smart and adapt to regional ‘personalities’ unless
minimal baseline interoperability is specified for some applications
– Who owns the application?
– Who has the right to specify the security interoperability settings between
regions?

11. Lesson-Learned #1: Determine what applications
MUST be interoperable between regions
§ E.g., Does a firetruck in Los Angeles need to be able to perform
certain applications in Houston, Texas? (e.g., traffic signal
preemption)
§ What vulnerabilities may emerge when one city’s infrastructure
makes different assumptions about how vehicles should handle its
messages?

12. Lesson-Learned #2: Standardize the interoperable
application specifications before you deploy
§ Connected vehicle pilots in the U.S. only have one completed
specification, SAE J2945/1, which describes proper application
behavior for V2V Basic-Safety-Message communications
§ Application specifications, especially V2I, will help designers
developing architectures
§ IF THIS IS NOT POSSIBLE, then consider regional configurations
(application personalities) that actuate in the vehicle when it moves
from one region to the other (and hope that everyone is using the
right ‘personality’)

13. Issue: Message Dictionary Clarity
§ SAE J2735 => Basic Safety Messages, Traveler Information, Map, Signal
Phase, Signal Request, Signal Status, etc.
§ Identifies:
– datagram structures
– Message data elements and data types by message
– Mandatory vs. Optional fields
§ Challenge for CV Pilot security: Message Dictionary contains many
repeated, overlapping and otherwise un-normalized information types
§ Result: Establishing security authorization rules (SSPs) over such
messages is exceedingly difficult and prone to error. Too much flexibility
(in how to express message information) to application designers can be a
huge security issue

14. Lesson-Learned #3: Build ‘clean’ message
dictionaries
§ Don’t repeat information in so many places
§ Standards bodies: Normalize your message data types/elements
– Make it easier for application designers and security engineers
§ Application Designers: Specify with clarity how to construct
messages and secure the vulnerable ones using SSPs
– These SSPs go INTO the 1609.2 credential and are issued by the PKI

15. Lesson 4: Include system security engineers
throughout the process
§ When developing message dictionaries
§ When developing Application specifications (for which security
matters)
§ For determining regional architectural impacts on applications and
vs. versa
§ For risk modeling overall system: They can help with the holistic
picture and where security issues are likely to arise

16. V2X Security: Tools for Smart Cities
§ IEEE 1609.2 is a full security stack, credential-driven, decentralized
messaging security model created for the transportation industry
§ IEEE 1609.2 certificates are small (~1/2 the size of X.509), saving
bandwidth (but still employ strong cryptography)
§ 1609.2 security model employs substantial geospatial and time-based
consistency checking mechanisms embedded right in the certificate and
encoded in each application’s tailorable security profile
§ WHERE ELSE CAN WE USE THIS????

17. Potential application of 1609.2 to DRONE
identification and tracking
FAA
Law
Enforcement
Operators

18. Potential Unmanned Aircraft Applications of 1609.2
§ Augment existing aviation messages (such as
ADS-B) with message-level cryptographic
security
– Prevent message forgery, replay, message tampering of
aircraft position reports
– Adds ~180 Bytes for the crypto (signature, certificate
and container encoding)
– Unauthenticated position reporting should not be
allowed in urban environments – too many risks
– Robotic, automated systems will increasingly rely on the
remote position reporting data for self-guidance
decisions
??
??
??

19. Potential Unmanned Aircraft Applications of 1609.2
(cont.)
§ UAS to UAS Ad-hoc Messaging
– Being considered in Unmanned Traffic Management (UTM) circles to
augment drone messaging in network-disconnected environments
§ UAS to Ground Control Station (controller)
– Application / telemetry / telematics messaging
§ UAS to Connected Ground Vehicles
– Ground and low altitude airborne vehicle situational awareness
§ UAS to Infrastructure
– Localized applications reporting information such as tall obstacles, weather,
roadway information, shipping port data, etc.

20. Re-tasking 1609.2 to other uses
§ Development of new message dictionaries OR adding security over
existing ones (e.g., ADS-B)
§ Development and specification of other automation applications
(e.g., drone apps)
§ Development of authorization models (SSPs) for new applications
§ Adaptation of PKI (Security Credential Management System) to
support new applications
– Most likely a simplification of the ground vehicle V2X system

21. Summary
§ Connected vehicle technology has been in the making for a long
time, but is poised for massive growth. Security and trust of the
ecosystem is vital.
§ Disconnects between standards bodies, application designers and
regulators are understandable, but rigorous system security
engineering principles still need to be maintained
§ Smart cities and nations wanting to secure and expand their ’Mobile
IoT’ portfolios’ (e.g., to include drones and other automated, mobile
systems) have an off-the-shelf security stack in the form of IEEE
1609.2 that can be easily tailored