1、BSI Standards Publication PD CEN/TS 16702-1:2014 Electronic fee collection Secure monitoring for autonomous toll systems Part 1: Compliance checkingPD CEN/TS 16702-1:2014 PUBLISHED DOCUMENT National foreword This Published Document is the UK implementation of CEN/TS 16702-1:2014. The UK participatio
2、n in its preparation was entrusted to Technical Committee EPL/278, Intelligent transport systems. A list of organizations represented on this committee can be obtained on request to its secretary. This publication does not purport to include all the necessary provisions of a contract. Users are resp
3、onsible for its correct application. The British Standards Institution 2014. Published by BSI Standards Limited 2014 ISBN 978 0 580 84810 0 ICS 35.240.60 Compliance with a British Standard cannot confer immunity from legal obligations. This Published Document was published under the authority of the
4、 Standards Policy and Strategy Committee on 30 November 2014. Amendments issued since publication Date 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 - Sec
5、ure monitoring for autonomous 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 Specif
6、ication (CEN/TS) was approved 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
7、 into a European Standard. 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)
8、until the final decision 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
9、, Iceland, Ireland, Italy, 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
10、 Management Centre: Avenue 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:2014 CEN/TS 16702-1:2014 (E) 2 Contents Page Foreword 5 0 Introduction 6 0.1 Overview .6
11、 0.2 Processes .6 0.3 Options .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
12、 needed for different types 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 Retri
13、eving Proof of Itinerary 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 incorrect
14、ness 29 5.7 Providing EFC 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
15、real-time (DSRC Transaction) 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:2014 CEN/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 I
16、tinerary Sequence 42 6.4.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 a
17、nd semantics . 52 6.6.4 Security 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
18、Public Keys, Certificates 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
19、 Annex A (normative) Data 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 . 6
20、9 B.2 Identification of the 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 cont
21、act person . 70 B.3 Identification 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:2014 CEN/TS 16702-1:2014 (E) 4 Ann
22、ex D (informative) Addressed 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_
23、CC concept FAQs . 84 E.3 SM_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 f
24、or the EETS . 99 F.1 General . 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:2014 CEN/TS 16702-1:2
25、014 (E) 5 Foreword This document (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. C
26、EN and/or CENELEC shall not 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 or
27、ganizations of the following 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, Luxe
28、mbourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom. PD CEN/TS 16702-1:2014 CEN/TS 16702-1:2014 (E) 6 0 Introduction 0.1 Overview In autonomous toll systems a Toll Service Provider (TSP) sends toll declarations
29、to the Toll Charger (TC), i.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
30、be trusted. It mainly focusses 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
31、Compliance Checking (SM_CC), 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 o
32、peration of the Toll Service 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
33、misuse under control effectively. 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
34、 well as transactions between 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
35、also specifies the interface 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
36、 to trust each other and only 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 Electr
37、onic Toll Service (EETS). 0.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 ro
38、ad usage is represented by a 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/replac
39、ement of itinerary data will 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 car
40、e of digitally signing itinerary records thereby committing to them in real-time. PD CEN/TS 16702-1:2014 CEN/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 1285
41、5:2012 message Toll Declaration. 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 c
42、heck the consistency of the Charge 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 Tol
43、l Declaration (CTD). Figure 1 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 dele
44、ted/changed in case of an absence 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 f
45、rozen itineraries in turn are 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
46、continuously can be established 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 neces
47、sarily part of the Toll Declaration) 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
48、 requires the TC to analyse the 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:2014 CEN/TS 16702-1:2014 (E) 8 CIF and CTD can be executed independently, however to achieve the
49、complete coverage of Secure Monitoring 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:2014 CEN/TS 16702-1:2014 (E) 9 Type of Secure Monitoring Description Capabilities needed Conditions for effective compliance checks Privacy impact Trusted Recorder Trusted Time Source
