1 / 26

Harmonization Task Group

Harmonization Task Group. William Whyte, Security Innovation, 2012-09-11. OVERVIEW. Scope & purpose of task group Review of security findings and recommendations Action items for IEEE Next steps. Goals.

ima
Download Presentation

Harmonization Task Group

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Harmonization Task Group William Whyte, Security Innovation, 2012-09-11

  2. OVERVIEW • Scope & purpose of task group • Review of security findings and recommendations • Action items for IEEE • Next steps

  3. Goals • Clause 10 – EU-U.S, Joint Declaration of Intent on Research Cooperation in Cooperative Systems • “Globally harmonized standards are essential to support and accelerate the adoption of Cooperative Systems. The parties strongly support the development of global open standards which ensure interoperability through appropriate actions which include, but are not limited to, coordinating the activities of the standardisationorganisations. In particular the parties intend to make efforts to preclude the development and adoption of redundant standards.”

  4. Meaning ofHarmonizAtion • 4 different levels of harmonization. • No interoperability. • The Mobile ITS Station must be physically exchanged when crossing a border. Not a viable option. • Interfaces and functional requirements are compatible, but applications, security and operations are different. • Various software components of the ITS station need to be replaced, and if the station is mounted in a vehicle, the vehicle could be registered as a local vehicle. Could be an option when exporting a vehicle, but not an option for the daily commuter. • Mobile ITS stations are functionally identical; all interfaces, functions, apps, security, etc., are based on the same standards and all stations have passed similar certification procedures, however, the operations of applications and security “affiliated” with regional back-office systems that do not talk to each other. • Potentially, a new “affiliation” could be loaded at the border, or ITS stations could be configured with dual “affiliations”, however, the complexity of setting up and managing this is likely to be more challenging than level 4 below. • Mobile ITS stations are functionally identical; all interfaces, functions, apps, security, etc., are based on the same standards and all stations have passed similar certification procedures, and the operations of applications and security “affiliated” with regional back-office systems have been “harmonized”. The back-offices may be connected in a hierarchical or flat structure.

  5. Members

  6. Structure AndOutput • HTG1 (Security); HTG3 (Networking and Management) • Each group output three documents: • X.1: Status of current standards • Review current standards for overlaps and gaps • X.2: Testing for interoperability • High-level description of tests that may be carried out to demonstrate interoperability based on harmonized standards • Motivating scenario is the border crossing scenario • X.3: Feedback to SDOs and other organizations • Based on gap and overlap analysis, propose how overlaps could be eliminated and gaps could be filled. • Additional documents: • Overview document • Comments on (ETSI) GeoNetworking • All documents currently undergoing final non-technical edit (to make formatting consistent and meet accessibility requirements), will be released shortly • Documents are intended as input to SDOs as they create their programs of work – they are not binding • Workshop to be held in Europe, Nov 15-16; another planned for North America after that but not yet scheduled • Aim of workshops: bring together representatives of SDOs, govts, stakeholder organizations to develop work program with harmonization needs taken into account

  7. HTG 1.1, 1.3 • HTG1.1: Status of current standards • Identify areas of Divergence (D) and Incompleteness (I) • HTG 1.3: Feedback to SDOs and other organizations • Consider security requirements under the following headings:

  8. IEEE High-Priority Actions • IEEE should continue to be the main SDO standardizing communications security mechanisms for messages over a fast transport protocol. • High-priority short-term activities: • (SAE/IEEE & ETSI): • Harmonize use of generation time in CAM/DEN/BSM • Decide on implicit v explicit certs • Harmonize on location of signing in the stack • Service Specific Permissions for CAM / BSM • IEEE/ETSI • Coordinate on proposed and potential changes to 1609.2 • IEEE • Review WSA security and propose changes if necessary • IEEE / ISO • Station management • IEEE to take action once stakeholders propose design: • Anonymous certs / reversible pseudonymity • Cert format • CRL format • Misbehavior reporting

  9. 1609.2-like UseCases • Use cases • Vehicle Originating Broadcast • Infrastructure Originating Broadcast • Infrastructure-Vehicle Unicast • Security Management for VOB, IOB, IVU • Advertisements • All standards here (ETSI and IEEE / SAE taking the lead) are profiles of 1609.2 so interoperability is easy to achieve • Some small areas of divergence, some major areas of incompleteness

  10. Vehicle Originating Broadcast:Message Signature • HTG1-VOB-01-D-01: Generation time. Sort out whether generation time goes in security headers or message payload. SAE / ETSI TC ITS WG 1. • HTG1-VOB-01-D-02: Choice of cryptographic signing mechanism. Use implicit certs or not? • HTG1-VOB-01-D-03: Cross-layer issues in signing. Ensure a common understanding of the correct location of signing within the stack, given inconsistencies in layering model used by ETSI vs 1609/SAE (geonetworking, facilities layer) • HTG1-VOB-01-D-04: Geonetworking: ETSI to evaluate geonetworking security requirements. • HTG1-VOB-01-D-05: Message Signature Verification policy: Verify all or verify on demand? SAE and ETSI ITS WG1 should liaise. • HTG1-VOB-01-D-06: Modification of signed data format: ETSI should not approve any divergence from 1609.2 unless IEEE 1609 also approve the changes and implement them. • HTG1-VOB-01-D-07: Certificate transfer: Policy for when certs vs digests are attached. SAE / ETSI WG1 • HTG1-VOB-01-I-01: Ability to assert all permissions: Primarily non-SDO for now

  11. Vehicle Originating Broadcast:Pseudonymity • HTG1-VOB-02-I-01 Reversible pseudonymity: Implement consistent specification of reversible pseudonymity once stakeholders agree. • HTG1-VOB-02-I-02 pseudonym change interval and algorithm: (Non-SDO) Agree whether there is a need for authorities to transmit and modify pseudonym change policy. (SDOs) Define message protocols for this. • HTG1-VOB-02-I-03 alert state: Avoid changing pseudonyms when in an alert state: ensure SAPs support this (ETSI) • This has implications for multi-application operations • HTG1-VOB-02-I-04 synchronization of identifier changes: Support synchronization of identifier changes (ETSI)

  12. Vehicle Originating Broadcast:Permission Encoding • HTG1-VOB-03-D-1: Geographic region encoding: • Define a data dictionary mapping compact identifiers to region definitions • Specify management messages to be used to update this data dictionary. • ETSI • HTG1-VOB-03-D-2: Permissions encoding and PSID value: Agree how permissions should be encoded by ETSI – currently well-known port number mapped to ITS-AID, should probably be just ITS-AID • ETSI • HTG1-VOB-03-I-1: Service Specific Permissions: Specify SSP for CAM / BSM. SAE / ETSI WG1.

  13. INFRASTRUCTUREOriginating Broadcast • HTG1-IOB-02-I-1 Revocation vs. short-lived certificates: (Non-SDO) Create policy for when revocation should be used vs. short lived certificates. • HTG1-IOB-02-I-2 Logging of vehicle-originating messages: Define how and whether RSUs and infrastructure are required and allowed to log incoming vehicle-originated messages. • Both non-SDO • Additionally, IOB will benefit from permission encoding work noted under VOB

  14. Infrastructure-Vehicle UNicast • Individual transactions between a vehicle requesting service from the infrastructure and the infrastructure responding to that vehicle about whether it can provide that service • Typically fast message protocol without advertisements • HTG members didn’t know of any existing specification of application of this type • HTG1-IVU-02-I-1 Encryption: Specify a limited set of shared mechanisms that may be used for confidentiality for messages of this type. • Need requirements from stakeholders • HTG1-IVU-03: Pseudonymity Service: Analyze privacy requirements • Need input from stakeholders

  15. Security Management ForVOB / IOB • HTG1-SM-01 Root Cert Update: • HTG1-SM-01-I-1 Provide standards to support root cert update once requirements are known. • HTG1-SM-01-I-3 PKI structure: Specify the PKI hierarchy to be used for specific applications. (Non-SDO) • HTG1-SM-02-I-1 Protocol for obtaining new pseudonyms when roaming: ETSI • HTG1-SM-03-I-1 Protocol for updating long-term/CSR certificates. Probably IEEE. • HTG1-SM-04, Pseudonym Resolution • HTG1-SM-04-I-1 Specification of protocol for reversible pseudonymity: SDOs should agree on a protocol, derived from those proposed by stakeholders. • HTG1-SM-04-I-2 Specification of conditions for reversing pseudonymity: Non-SDO. • HTG1-SM-04-I-3 Protocol to notify ITS-S owner if privacy policy changes: (Non-SDO) determine if this is necessary; (SDO) Specify this. • HTG1-SM-05, Revocation • HTG1-SM-05-I-1 CRL format for reversible pseudonyms derived from those proposed by stakeholders. • HTG1-SM-05-I-2 Specification of certificate revocation distribution process: Specify how CRLs may be distributed, especially to those ITS-S that do not have frequent data connectivity to the certificate management service. Research needed. • HTG1-SM-07, Misbehavior Reporting • Misbehavior reporting algorithm.Research needed. • Misbehavior reporting protocol. Research needed.

  16. Security Management ForVOB / IOB

  17. Local Time-Critical Sessions • Tolling, EFC • These are not widely standardized (except tolling, which is out of scope) • Is it worth providing a set of common security mechanisms that application designers could use? • SDOs may consider developing a public key based security mechanism suitable for these applications. This has been a “future work item” within IEEE 1609.2 for some time. • EFC standards should be reviewed to ensure that they do not maintain identifiers between sessions • An appropriate SDO should develop guidelines for privacy against eavesdropping in EFC, for use by future standards. This seems a natural task for ISO / CEN.

  18. Local Non-Time-Critical Sessions • E.g. probe data collection • These are not widely standardized (except tolling, which is out of scope) • Is it worth providing a set of common security mechanisms that application designers could use? • SDOs may consider developing a public key based security mechanism suitable for these applications. This has been a “future work item” within IEEE 1609.2 for some time. • SDOs may consider developing a symmetric cryptography based security mechanism suitable for these applications. • If existing internet mechanisms are to be modified for use in the ITS settings, ITS SDOs should liaise with the IETF. • An appropriate SDO should develop guidelines for privacy against eavesdropping in LNTCS applications, for use by future standards. • See also Service Advertisements. • HTG1-SM-07, Misbehavior Reporting • Misbehavior reporting algorithm.Research needed. • Misbehavior reporting protocol. Research needed.

  19. MULTI-RSUSessions • Fully specify security and operational requirements. Non-SDO • Consider using V-HIP as a basis for secure session handoff. This work naturally belongs either in the IPv6 work done within ETSI or within 1609.2 where WG members have experience with V-HIP. • Standardize interfaces for initialization of secure session handoff. IEEE / ETSI.

  20. Service Advertisements • HTG1-Adv-01 Requirements • HTG1-Adv-01-I-01: Produce a TVRA for service advertisements. ETSI (TVRA expertise)/ IEEE (owner of advertisments) • HTG1-Adv-01-I-02: Specify a generic mechanism for initiating application or facilities layer secure sessions via the service advertisement. IEEE. • HTG1-Adv-01-I-03: Specify a mechanism for initiating network layer secure sessions based on information in the service advertisement. IEEE / ETSI. • HTG1-Adv-01-I-04: Specify a mechanism for initiating MAC layer secure sessions using information in a service advertisement. Depends on requirements. • HTG1-Adv-04-I-01: Specify maximum lifetimes for acceptable service advertisements based on the TVRA and standardize. IEEE • HTG1-Adv-05-I-01: Specify verification policy for service advertisements based on the TVRA. IEEE • HTG1-Adv-02 Format: Specify signed WSA format based on TVRA. IEEE • HTG1-Adv-04: Pseudonym attachment interval / algorithm based on TVRA. IEEE or non-SDO.

  21. LowerLayer • HTG1-LL-01 Requirements: Non-SDO • HTG1-LL-02 Layer 3 Mechanisms: E.g. profile of IPSec. ETSI. • HTG1-LL-03: Layer 3 privacy considerations. Requirements on changing IP addresses for privacy. Non-SDO. • HTG1-LL-04 Layer 2 Mechanisms: E.g. profile of 802.11 TGai. ETSI?

  22. MultipleApplicaTionsAnd ApplicationManagement:Application Deployment (Full Model)

  23. MultipleApplicaTionsAnd ApplicationManagement:Application Deployment (Single-App Model)

  24. MultipleApplicaTionsAnd ApplicationManagement • HTG1-MA-01: Statement and approval of application use of resources • Allow application to make authenticated / authorized statement of permissions it needed prior to being installed • May not need to be standardized – could be OS-specific, for example • HTG1-MA-02: Privacy • May want to obscure the fact that two applications are running on the same device. Possible countermeasures: • Use a different set of network identifiers for each application (in other words, each application runs on its own virtual machine down through the MAC level). • Encrypt all identifiers other than those necessary to complete the first hop (i.e. all identifiers except the destination MAC address for communications over 5.9 GHz) • This would require layer 2 encryption, which is not currently supported by IEEE 802.11-2012 operating outside the context of a BSS. • Ensure that identifiers change between one use of an application and the next and do not leak information about which application the identifiers refer to. • Policy may dictate minimum level of privacy • Alternatively, reduction of privacy could be considered to be a result of opt-in decisions and out of scope • Requirements research needed.

  25. Platform and physical security • HTG1-PPS-01: Minimum security standards for platform security: what level of hardware and software protection must be provided to run particular types of application • For example, do police car apps need higher physical security than ordinary safety-of-life apps? • Allow platforms to make conformance statements about the security they provide  applications they can run • Research needed. • HTG1-PPS-02: Statement of platform capabilities to CA • Assert authorization / appropriateness of platform to run particular applications. • HTG1-PPS-03: Statement of platform capabilities to application at install time • Could be platform / OS-specific • HTG1-PPS-04: Minimum security and performance requirements for secure firmware upgrade • HTG1-PPS-05: Station management • 1609.6, 1609.5.

  26. Future extensibility • HTG1-Fut-01: Crypto algorithm agility (applications using 1609.2) • Define mechanisms by which implementations of 1609.2 security may be upgraded if existing cryptographic algorithms are broken. • Provide guidance as to how cryptographic / security hardware should be deployed to allow for migration • Long-term: determine candidate algorithms: • Research into satisfactory replacement algorithms • Research into hardware upgradeability, e.g., using reconfigurable hardware. • Standardizing replacement algorithms– IEEE. • HTG1-Fut-02: Crypto algorithm agility (applications not using 1609.2) • HTG1-Fut-03: Ability to support new formats (applications using 1609.2) • HTG1-Fut-04: Ability to support new formats (applications not using 1609.2)

More Related