SIST-TS CEN/TS 16702-1:2015

SLOVENSKI STANDARD
SIST-TS CEN/TS 16702-1:2015
01-februar-2015
Elektronsko pobiranje pristojbin - Varnostno spremljanje avtonomnih cestninskih
sistemov - 1. del: Preverjanje skladnosti
Electronic fee collection - Secure monitoring for autonomous toll systems - Part 1:
Compliance checking
Elektronische Gebührenerhebung - Sichere Überwachung von autonomen
Mautsystemen - Einhaltungsprüfung
Perception du télépéage - Surveillance sécurisée pour systèmes autonomes de péage -
Partie 1: Contrôle de conformité
Ta slovenski standard je istoveten z: CEN/TS 16702-1:2014
ICS:
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
SIST-TS CEN/TS 16702-1:2015 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TS CEN/TS 16702-1:2015

---------------------- Page: 2 ----------------------

SIST-TS CEN/TS 16702-1:2015

TECHNICAL SPECIFICATION
CEN/TS 16702-1

SPÉCIFICATION TECHNIQUE

TECHNISCHE SPEZIFIKATION
November 2014
ICS 35.240.60
English Version
Electronic fee collection - Secure monitoring for autonomous toll
systems - Part 1: Compliance checking
Perception du télépéage - Surveillance sécurisée pour Elektronische Gebührenerhebung - Sichere Überwachung
systèmes autonomes de péage - Partie 1: Contrôle de von autonomen Mautsystemen - Einhaltungsprüfung
conformité
This Technical Specification (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 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)
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, 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É EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2014 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16702-1:2014 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------

SIST-TS CEN/TS 16702-1:2015
CEN/TS 16702-1:2014 (E)
Contents Page
Foreword .5
0 Introduction .6
0.1 Overview .6
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 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 Retrieving 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 incorrectness . 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 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
2

---------------------- Page: 4 ----------------------

SIST-TS CEN/TS 16702-1:2015
CEN/TS 16702-1:2014 (E)
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.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 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 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
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 . 69
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 contact 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
3

---------------------- Page: 5 ----------------------

SIST-TS CEN/TS 16702-1:2015
CEN/TS 16702-1:2014 (E)
Annex 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_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 for 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
4

---------------------- Page: 6 ----------------------

SIST-TS CEN/TS 16702-1:2015
CEN/TS 16702-1:2014 (E)
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. CEN [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 organizations 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, Luxembourg, Malta, Netherlands, Norway, Poland,
Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United Kingdom.

5

---------------------- Page: 7 ----------------------

SIST-TS CEN/TS 16702-1:2015
CEN/TS 16702-1:2014 (E)
0 Introduction
0.1 Overview
In autonomous toll systems a Toll Service Provider (TSP) sends toll declarations 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 be trusted. It mainly focusses on the
compliance of the Service User (SU) with the toll domain’s 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), 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
Provider’s 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 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 well as transactions between the Toll
Charger's and the Toll Service Provider's 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 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 only trust
parts of each other’s 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.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 vehicle’s road 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/replacement 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 care of digitally signing itinerary records
thereby committing to them in real-time.
6

---------------------- Page: 8 ----------------------

SIST-TS CEN/TS 16702-1:2015
CEN/TS 16702-1:2014 (E)
— 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 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 check 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 Toll 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
deleted/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 frozen 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 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 necessarily 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 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.
7

---------------------- Page: 9 ----------------------

SIST-TS CEN/TS 16702-1:2015
CEN/TS 16702-1:2014 (E)
CIF and CTD can be executed independently, however to achieve the 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
...