1 / 25

Objectives (1)

EG 11 Definition of the EFC Application for the EETS based on Microwave Technologies Bernhard Oehry Partner Rapp Trans AG Basel, Switzerland bernhard.oehry@rapp.ch. Objectives (1).

randy
Download Presentation

Objectives (1)

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. EG 11Definition of the EFC Application for the EETS based on Microwave TechnologiesBernhard OehryPartnerRapp Trans AGBasel, Switzerlandbernhard.oehry@rapp.ch

  2. Objectives (1) “Expert Group 1 has promoted the idea of a single European EFC application for the European EFC service based on microwave technologies.This idea seems to be well accepted by the majority of the EFC Expert Group. The basic aim of EG 11 is now to define the general specifications for this Application. …

  3. Objectives (2) …It might start from the achievements of such European projects as CARDME, MEDIA, CESARE. Its report will be submitted to the Regulatory Committee created by the Directive 2004/52/CE, through the "EFC Expert Group". It should coordinate its work with the project CESARE III. Furthermore, it will study the requirements for security of the transactions, and especially the question of security keys.”

  4. EG 11 Members • Anton Sieber AT • Bernhard Oehry CH • Joan Marti Riola ES • François Malbrunot FR • Paolo Giorgi IT • Bjarne Olav Tveit NO • Paulo Marques PT • Johan Hedin SE • Simon Smith UK

  5. Scope • Dual DSRC stack (CEN and UNI) • according to EG1 recommendation • For all vehicles (commercial and private) • Only for the EETS • free choice of the user to subscribe • shall not replace national services • Central account only • on-board account not feasible without widespread electronic purse / electronic money infrastructure • not considered by PISTA, CESARE, CARDME, … • Including enforcement in DSRC systems • transaction shall be useful for enforcement of the DSRC part of the EETS • transaction not designed for enforcement of GPS/GSM part of the EETS

  6. Relation of EG 11 to other work

  7. Input: Standards and Specifications • CEN TC278 WG1 SG2:“Interoperability Application Profile for DSRC” • Report of EG 1 (and EG 8) on DSRC • Report of EG 2 on Classification • CEN DSRC and EFC standards • especially EN ISO 14906 • UNI DSRC standards • DSRC transactions from international projects • PISTA / CESARE II • CARDME-4 • MEDIA • National DSRC transactions • Austria, France, Norway, Sweden, UK, Spain, Portugal

  8. Input: CESARE III Model for Interoperability

  9. Requirements from the CESARE Model • EETS Providers issue OBE independent from Toll Chargers  need for an interoperable Personal Account Number • EETS Provider and Toll Chargers independently need proof of validity of the transaction data  separate security elements for EETs Provider and Toll Charger • Toll Charger is responsible for enforcement  DSRC transaction needs to support both charging and enforcement

  10. Constraints • Equal treatment / non discrimination • EETS users and national users must be treated equally  all national requirements must be fully covered • Must work in an international environment • Scale of the service might be very large • A multitude of actors • Minimal change to existing equipment • If possible there should be no need to replace RSE • Upgrades of software will be necessary • Performance suitable for all charging systems • Transaction time must remain low

  11. The Challenge Find the balance between subsidiarity and interoperability: • Subsidiarity asks for a maximum solution that enables all and everything • Interoperability as a commercial product requires restriction of the solution to an affordable minimum Our approach: Define what has to be defined, and leave the rest open

  12. DSRC DATA SECURITY What needs to be defined ? • DSRC Link DSRC • according to EG 1: dual DSRC stack • CEN DSRC • Telepass DSRC • OBU Data Content DATA • Contract / Payment • Vehicle (according to EG 2 on Classification) • OBU • Receipts (Entry and Exit Tickets) • Security Elements SECURITY • Including key management / ownership

  13. What can be left open • Transaction Flow • No need for a fixed definition • “read and write as you like” • OBE and RSE Requirements • OBE initialisation • RSE list management • Technical detail • bit-level coding, security calculations, state transitions, …  TC278 WG1 • Test specifications for approval of conformance  Recommendation 4

  14. DSRC DATA SECURITY DSRC Requirements

  15. DSRC DATA SECURITY Data Requirements (1)

  16. DSRC DATA SECURITY Data Requirements (2)

  17. DSRC DATA SECURITY Data Requirements: “EETS Contract” VST has to contain the information: “I have an EETS contract”

  18. DSRC DATA SECURITY Data Requirements: “EETS Contract” Options to say “EETS Contract” in VST • Agree on a coding for “EETS Contract” • Collisions with existing coding • Define EETS-Providers on a European basis • No existing code for “Europe” • No agreed coding  Use look-up tables in the RSE Proposed EG 11 solution The proposed solution also allows to individuallyblacklist non-compliant EETS-Providers

  19. DSRC DATA SECURITY Security Requirements • Static Authenticators • e.g. Contract Authenticator, Vehicle Authenticator • not foreseen • Dynamic Authenticators • Mechanism: GET Stamped • foreseen: 2 individual authenticators • migration strategy to avoid changes to existing RSE • Access restrictions • All data except Receipt and Eq.Status are read only • Access credentials not foreseen for the time being(see Recommendation 7) • Transaction Counter • foreseen

  20. Table of contents of EG11 Report 1 Objectives, Scope 2 Principles 3 Processes 4 Proposed Solution 5 Implementation / Migration 6 Summary of Recommendations Annex A DSRC Transaction Specification Annex B Compatibility with Other Specifications Annex C References Annex D Glossary of Terms Annex E Expert Group Members

  21. EG 11 Recommendations (1) R 1 The specification in Annex A should be accepted as the technical basis of the EETS for DSRC based charging systems. R 2 The specification should be forwarded as input to European Standardisation. R 3 The European Commission should establish a mechanism to maintain the specification in harmony with European Standards.

  22. EG 11 Recommendations (2) R 4The European Commission should establish a mechanism that defines test procedures for conformity evaluation of EETS equipment. R 5 The process for key management for keys common to Toll Chargers should be defined as part of the CESARE work. R 6 Blacklist content and the relation between PAN and EquipmentOBUId should be addressed from an operational point of view, e.g. by the project CESARE III.

  23. EG 11 Recommendations (3) R 7 The specification does not foresee the use of OBE Access Credentials for the time being. It is recommended that Toll Chargers ready their equipment for key handling and the dynamic calculation of Access Credentials when they replace or update RSE. Introduction of Access Credentials on a mandatory basis shall be decided at a later point in time.

  24. EG 11 Recommendations (4) R 8 EETS security issues should be investigated in detail, e.g. by an Expert Group. A proper threat analysis should be undertaken and a system-wide coherent and comprehensive security framework be proposed. Migration issues, like the co-existence of different security levels, should also be looked into.

  25. Bernhard Oehry Tel.: +41 / 61 / 335 78 46 Fax.: +41 / 61 / 335 77 00 Mail: bernhard.oehry@rapp.ch Web: www.rapp.ch Will the colour go away ?

More Related