1、BSI Standards PublicationPD CEN/TS 16702-1:2014Electronic fee collection Secure monitoring forautonomous toll systemsPart 1: Compliance checkingPD CEN/TS 16702-1:2014 PUBLISHED DOCUMENTNational forewordThis Published Document is the UK implementation of CEN/TS16702-1:2014.The UK participation in its
2、 preparation was entrusted to TechnicalCommittee EPL/278, Intelligent transport systems.A list of organizations represented on this committee can beobtained on request to its secretary.This publication does not purport to include all the necessaryprovisions of a contract. Users are responsible for i
3、ts correctapplication. The British Standards Institution 2014. Published by BSI StandardsLimited 2014ISBN 978 0 580 84810 0ICS 35.240.60Compliance with a British Standard cannot confer immunity fromlegal obligations.This Published Document was published under the authority of theStandards Policy and
4、 Strategy Committee on 30 November 2014.Amendments issued since publicationDate Text affectedPD CEN/TS 16702-1:2014TECHNICAL SPECIFICATION SPCIFICATION TECHNIQUE TECHNISCHE SPEZIFIKATION CEN/TS 16702-1 November 2014 ICS 35.240.60 English Version Electronic fee collection - Secure monitoring for auto
5、nomous toll systems - Part 1: Compliance checking Perception du tlpage - Surveillance scurise pour systmes autonomes de page - Partie 1: Contrle de conformit Elektronische Gebhrenerhebung - Sichere berwachung von autonomen Mautsystemen - Einhaltungsprfung This Technical Specification (CEN/TS) was ap
6、proved by CEN on 14 June 2014 for provisional application. The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standa
7、rd. CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in parallel to the CEN/TS) until the final decisio
8、n about the possible conversion of the CEN/TS into an EN is reached. CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Ita
9、ly, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG CEN-CENELEC Management Centre: Ave
10、nue Marnix 17, B-1000 Brussels 2014 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. CEN/TS 16702-1:2014 EPD CEN/TS 16702-1:2014CEN/TS 16702-1:2014 (E) 2 Contents Page Foreword 5 0 Introduction 6 0.1 Overview .6 0.2 Processes .6 0.3 Op
11、tions .8 0.4 Privacy aspects . 11 1 Scope . 12 1.1 General scope . 12 1.2 Relation to CEN/TS 16439 12 1.3 Relation to other standards . 14 2 Normative references . 14 3 Terms and definitions 15 4 Abbreviations 17 5 Processes 18 5.1 Introduction and overview . 18 5.2 Processes needed for different ty
12、pes of Secure Monitoring . 19 5.3 Itinerary Freezing 21 5.3.1 Introduction . 21 5.3.2 Generate Itinerary . 21 5.3.3 Real-time freezing . 23 5.3.4 Freezing per declaration 24 5.4 Checking of Itinerary Freezing 25 5.4.1 Introduction . 25 5.4.2 Observing a vehicle 25 5.4.3 Retrieving Proof of Itinerary
13、 Freezing (PIF) . 26 5.4.4 Checking PIF against Observation . 27 5.5 Checking of Toll Declaration . 27 5.5.1 Introduction . 27 5.5.2 Retrieve Itinerary Data 27 5.5.3 Check Itinerary Consistency . 28 5.5.4 Checking Toll Declaration against Itinerary . 28 5.6 Claiming incorrectness 29 5.7 Providing EF
14、C Context Data 29 5.8 Key Management 29 5.8.1 Introduction . 29 5.8.2 Requirements 29 6 Transactions 30 6.1 Introduction . 30 6.2 Description of Itinerary Data 32 6.2.1 Introduction . 32 6.2.2 Itinerary Batch . 34 6.2.3 Itinerary Record Data Elements 35 6.3 Retrieving PIF in real-time (DSRC Transact
15、ion) 37 6.3.1 Introduction . 37 6.3.2 Transactional Model . 38 6.3.3 Syntax and Semantics 38 6.3.4 Security 40 6.4 Toll Declaration . 40 PD CEN/TS 16702-1:2014CEN/TS 16702-1:2014 (E) 3 6.4.1 Introduction 40 6.4.2 Transactional Model 40 6.4.3 Syntax and semantics . 41 6.4.4 Itinerary Sequence 42 6.4.
16、5 Security 44 6.5 Back End Data Checking 44 6.5.1 Introduction 44 6.5.2 Transactional model 45 6.5.3 Checks of the Itinerary 46 6.5.4 Syntax and semantics . 47 6.5.5 Security 50 6.6 Claiming incorrectness . 50 6.6.1 Introduction 50 6.6.2 Transactional model 51 6.6.3 Syntax and semantics . 52 6.6.4 S
17、ecurity 52 6.7 Providing EFC Context Data 53 6.7.1 Introduction 53 6.7.2 Transactional Model 53 6.7.3 Syntax and semantics . 53 6.7.4 Security 55 7 Security 55 7.1 Security functions and elements . 55 7.1.1 Hash functions . 55 7.1.2 MAC. 55 7.1.3 Digital signatures 55 7.1.4 Public Keys, Certificates
18、 and CRL . 55 7.2 Key Management . 56 7.2.1 Key Exchange between Stakeholders . 56 7.2.2 Key generation and certification 56 7.3 Trusted Recorder and SM_CC Verification SAM characteristics . 57 7.3.1 Introduction 57 7.3.2 Trusted Recorder . 57 7.3.3 SM_CC Verification SAM 58 Annex A (normative) Data
19、 type specification . 59 Annex B (normative) Protocol Implementation Conformance Statement . 67 B.1 Guidance for completing the PICS proforma . 67 B.1.1 Purposes and structure 67 B.1.2 Abbreviations and conventions . 67 B.1.3 Instructions for completing the PICS proforma . 69 B.2 Identification of t
20、he implementation 69 B.2.1 General . 69 B.2.2 Date of the statement 69 B.2.3 Implementation Under Test (IUT) identification . 69 B.2.4 System Under Test (SUT) identification 69 B.2.5 Product supplier 70 B.2.6 Applicant (if different from product supplier). 70 B.2.7 PICS contact person . 70 B.3 Ident
21、ification of the protocol 71 B.4 Global statement of conformance . 71 B.5 Roles . 71 B.6 Types of Secure Monitoring . 71 B.7 Capabilities and conditions 72 B.8 Processes . 73 Annex C (informative) Example transactions . 74 PD CEN/TS 16702-1:2014CEN/TS 16702-1:2014 (E) 4 Annex D (informative) Address
22、ed threats (in CEN/TS 16439) 78 D.1 Introduction . 78 D.2 Threats where Secure Monitoring can provide Security Measures 78 D.3 Related Requirements 80 D.4 Related Security Measures 81 Annex E (informative) Essentials of the SM_CC concept 84 E.1 Introduction . 84 E.2 The SM_CC concept FAQs . 84 E.3 S
23、M_CC options . 86 E.3.1 SM_CC_1 . 86 E.3.2 SM_CC_2 . 90 E.3.3 SM_CC_3a . 93 E.3.4 SM_CC_3b . 95 E.4 Managing multiple toll domains 96 E.4.1 Overlapping toll domains . 96 E.4.2 The catch-all toll domain counter . 98 Annex F (informative) Use of this Technical Specification for the EETS . 99 F.1 Gener
24、al . 99 F.2 Overall relationship between European standardization and the EETS . 99 F.3 European standardization work supporting the EETS . 99 F.4 Correspondence between this technical specification and the EETS 100 Bibliography . 101 PD CEN/TS 16702-1:2014CEN/TS 16702-1:2014 (E) 5 Foreword This doc
25、ument (CEN/TS 16702-1:2014) has been prepared by Technical Committee CEN/TC 278 “Intelligent transport systems”, the secretariat of which is held by NEN. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN and/or CENELEC shall not
26、 be held responsible for identifying any or all such patent rights. This document has been prepared under a mandate given to CEN by the European Commission and the European Free Trade Association. According to the CEN-CENELEC Internal Regulations, the national standards organizations of the followin
27、g countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands,
28、 Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. PD CEN/TS 16702-1:2014CEN/TS 16702-1:2014 (E) 6 0 Introduction 0.1 Overview In autonomous toll systems a Toll Service Provider (TSP) sends toll declarations to the Toll Charger (TC), i.
29、e. statements that a vehicle was circulating within a toll domain. Compliance Check Communication (CCC) according to CEN ISO/TS 12813:2009 provides useful indications to a TC of whether the OBE is operating correctly or not. It assumes the OBE to be secure and the TSP to be trusted. It mainly focuss
30、es on the compliance of the Service User (SU) with the toll domains rules. This Technical Specification does not assume the OBE to be secure nor the TSP to be trusted and adds measures to deal with the associated risks. It specifies the requirements for Secure Monitoring Compliance Checking (SM_CC),
31、 a concept that allows the TC to check the trustworthiness of toll declarations produced by a TSP using an OBE operated by the SU, while respecting the privacy of the SU in accordance with the applicable regulations. Trustworthiness equals the confidence in the reliable operation of the Toll Service
32、 Providers EFC System and / or in case of errors gives technical indications about possible failures or manipulations which may be attributed to the SU and/or the TSP or an external party. An operational EFC System can use a combination of the CCC and SM_CC tools to keep misuse under control effecti
33、vely. This Technical Specification is the first part in a set of two that together specify Secure Monitoring for Autonomous Toll Systems: This technical specification, “Secure Monitoring - Compliance Checking”, specifies the transactions between RSE of the TC over DSRC as well as transactions betwee
34、n the Toll Chargers and the Toll Service Providers back end systems, for the purpose of Secure Monitoring. A second part, “Secure Monitoring Trusted Recorder”, specifies requirements on a tamper-proof entity called a Trusted Recorder (TR) which can be part of the OBE. It also specifies the interface
35、 between OBE and TR. Most but not all available options for secure monitoring require the use of a TR to provide for integrity, authenticity and non-repudiation services. The SM_CC method is suitable: a) for use by Toll Chargers and Toll Service Providers that do not have to trust each other and onl
36、y trust parts of each others equipment; b) for all types of toll regimes according to CEN ISO/TS 17575 (all parts); c) for providing evidence that can be used in court; d) for the application to local schemes as well as in interoperable sectors such as the European Electronic Toll Service (EETS). 0.
37、2 Processes SM_CC provides a TC operating an autonomous toll system with the tools to check whether or not the usage of a transport service by a vehicle in his toll domain is correctly recorded in what is called the itinerary. In the OBE, the registration of a vehicles road usage is represented by a
38、 so-called itinerary which is committed to in real-time or with a defined delay by a process called itinerary freezing. Itinerary freezing ensures that the integrity of the itinerary is undeniably committed to. After an itinerary is frozen, deletion or manipulation/replacement of itinerary data will
39、 invalidate the proof of integrity and can thus be detected. The freezing process comes in two variants: real-time freezing: In this case the presence of a tamper proof trust anchor in the OBE is assumed. This trust anchor is called the Trusted Recorder (TR) and takes care of digitally signing itine
40、rary records thereby committing to them in real-time. PD CEN/TS 16702-1:2014CEN/TS 16702-1:2014 (E) 7 freezing per declaration: In this case, the itineraries are signed by the TSP back end and committed to by sending the signature to the TC using the standard EN ISO 12855:2012 message Toll Declarati
41、on. The road usage itself can be detected via (automatic or manual) observations. In order to be fully effective, the concept requires either unexpected or undetected observations, depending on the type of secure monitoring applied. SM_CC provides the TSP with tools to check the consistency of the C
42、harge Reports obtained from his Front-end and/or the related Toll Declarations with the itinerary. SM_CC is based on a double principle and related processes which are loosely coupled but need to be executed both: Checking of Itinerary Freezing (CIF) and Checking of Toll Declaration (CTD). Figure 1
43、The sub-processes of Compliance Checking (UML use case diagram) For CIF the aim is to check the registered itinerary data against an observation of road usage. The concept ensures that such data cannot be corrected in case of an unexpected spot check observation or deleted/changed in case of an abse
44、nce of checks. CIF can be done in real-time at the roadside using an SM_CC transaction via DSRC and / or with delay in the back end using the CTD transaction. CIF gives the TC confidence in that all road usage is registered as an itinerary in the freezing process. The frozen itineraries in turn are
45、used as a reference for checking the plausibility of the Toll Declarations. It is mandatory that the TSP checks that the itinerary is plausible and that the Toll Declaration is consistent with the Itinerary. The Toll Chargers confidence that this process is carried out continuously can be establishe
46、d through the CTD Process, but it is also possible to achieve this through audits or other processes not described in this standard. CTD is a spot check operation in which the Toll Declaration is checked against the underlying detailed itinerary data (which is not necessarily part of the Toll Declar
47、ation) in order to verify that the aggregated fields that are reported (e.g. distance travelled in charging zone, aggregated fee etc.) have been computed correctly. CTD also aims to verify the integrity, the completeness and plausibility of the itinerary data. Since CTD requires the TC to analyse th
48、e detailed itineraries corresponding to the Toll Declaration of the SU it is desirable from a privacy perspective to limit the number of CTD transactions. PD CEN/TS 16702-1:2014CEN/TS 16702-1:2014 (E) 8 CIF and CTD can be executed independently, however to achieve the complete coverage of Secure Mon
49、itoring CIF needs to be complemented with CTD and vice-versa. 0.3 Options For a derivation of the different types of Secure Monitoring from the available options, see Table 1. Annex E provides further background information on the use of and the rationale for these options. Annex F how this TS can be used for the EETS. PD CEN/TS 16702-1:2014CEN/TS 16702-1:2014 (E) 9 Type of Secure Monitoring Description Capabilities needed Conditions for effective compliance checks Privacy impact TrustedRecorderTrustedTimeSourceHighcommunication availabilityCIFviaDS
