Locking Down and Re-Using V2X Security - Lessons for Smart Cities
•
1 like•923 views
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
Report
Share
Locking Down and Re-Using V2X Security - Lessons for Smart Cities
- 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