CEN/TS 16702-2:2015

SLOVENSKI STANDARD
01-september-2015
Elektronsko pobiranje pristojbin - Varnostno spremljanje avtonomnih cestninskih
sistemov - 2. del: Zaupanja vreden snemalnik
Electronic fee collection - Secure monitoring for autonomous toll systems - Part 2:
Trusted recorder
Elektronische Gebührenerhebung - Sichere Überwachung von autonomen
Mautsystemen - Teil 2: Zuverlässige Datenaufzeichnung
Perception du télépéage - Surveillance sécurisée pour systèmes autonomes de péage -
Partie 2: Enregistreur fiabilisé
Ta slovenski standard je istoveten z: CEN/TS 16702-2:2015
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

TECHNICAL SPECIFICATION
CEN/TS 16702-2
SPÉCIFICATION TECHNIQUE
TECHNISCHE SPEZIFIKATION
March 2015
ICS 03.220.20; 35.240.60
English Version
Electronic fee collection - Secure monitoring for autonomous toll
systems - Part 2: Trusted recorder
Perception du télépéage - Surveillance sécurisée pour Elektronische Gebührenerhebung - Sichere Überwachung
systèmes autonomes de péage - Partie 2: Enregistreur von autonomen Mautsystemen - Teil 2: Zuverlässige
fiabilisé Datenaufzeichnung
This Technical Specification (CEN/TS) was approved by CEN on 19 January 2015 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
© 2015 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16702-2:2015 E
worldwide for CEN national Members.

Contents Page
Foreword .4
Introduction .5
1 Scope .7
2 Normative references .7
3 Terms and definitions .8
4 Symbols and abbreviations . 11
5 SAM concept and scenarios . 12
5.1 General . 12
5.2 The concepts of TR and Verification SAM . 13
5.3 Scenarios for a Trusted Recorder . 14
5.3.1 General . 14
5.3.2 Real-Time Freezing without using a Trusted Time Source . 14
5.3.3 Real-Time Freezing using a Trusted Time Source . 15
5.4 Scenarios for a Verification SAM . 15
5.4.1 General . 15
5.4.2 MAC verification. 16
5.5 General Scenarios . 16
5.5.1 General . 16
5.5.2 Assigning a Toll Domain Counter . 17
5.5.3 Obtaining SAM Information . 17
6 Functional requirements . 18
6.1 General . 18
6.1.1 SAM options . 18
6.1.2 Presentation of requirements . 19
6.2 Basic requirements. 19
6.3 Key management . 20
6.4 Cryptographic functions . 20
6.5 Real-time freezing . 21
6.6 Verification SAM . 21
6.7 Toll Domain Counter . 22
6.8 Trusted time source . 23
6.9 Security protection level . 24
7 Interface requirements . 24
7.1 General . 24
7.2 Calculate MAC for real-time freezing . 24
7.2.1 General . 24
7.2.2 Calculation of MAC . 25
7.2.3 Coding of request . 25
7.2.4 Coding of response . 26
7.3 Calculate digital signature for real-time freezing . 26
7.3.1 General . 26
7.3.2 Calculation of digital signature . 26
7.3.3 Coding of request . 27
7.3.4 Coding of response . 27
7.4 Get device information . 28
7.4.1 General . 28
7.4.2 Coding of request . 28
7.4.3 Coding of response . 28
7.5 Get toll domain counter information . 28
7.5.1 General . 28
7.5.2 Coding of request . 29
7.5.3 Coding of response . 29
7.6 Get key information . 29
7.6.1 General . 29
7.6.2 Coding of request . 30
7.6.3 Coding of response . 30
7.7 Error handling . 31
Annex A (normative) Data type specification . 32
A.1 General . 32
A.2 Data specifications . 32
Annex B (normative) Implementation Conformance Statement (ICS) proforma . 33
B.1 Guidance for completing the ICS proforma . 33
B.1.1 Purposes and structure . 33
B.1.2 Abbreviations and conventions . 33
B.1.3 Instructions for completing the ICS proforma. 34
B.2 ICS proforma for Trusted Recorder . 35
B.2.1 Identification implementation . 35
B.2.2 Identification of the standard . 35
B.2.3 Global statement of conformance . 35
B.2.4 ICS proforma tables for TR . 36
B.3 ICS proforma for Verification SAM . 39
B.3.1 Identification implementation . 39
B.3.2 Identification of the standard . 39
B.3.3 Global statement of conformance . 39
B.3.4 ICS proforma tables for Verification SAM . 40
Annex C (informative) Trusted time source implementation issues . 43
C.1 General . 43
C.2 Possible implementations of a TTS . 43
C.2.1 TTS based on a real time clock . 43
C.2.2 TTS with the need for external calibration . 43
C.3 TTS power supply . 44
Annex D (informative) Use of this Technical Specification for the EETS . 45
D.1 General . 45
D.2 Overall relationship between European standardization and the EETS . 45
D.3 European standardization work supporting the EETS . 45
D.4 Correspondence between this Technical Specification and the EETS . 46
Bibliography . 47

Foreword
This document (CEN/TS 16702-2:2015) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
This part 2, the trusted recorder is the second part of the standard suite of the secure monitoring for
autonomous toll systems. The overall concept of secure monitoring is defined in part one,
CEN/TS 16702-1:2014.
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.
Introduction
The widespread use of tolling requires provisions for users of vehicles that are roaming through many different
toll domains. Users should be offered a single contract for driving a vehicle through multiple toll domains and
those vehicles require onboard equipment (OBE) that is interoperable with the toll systems in these toll
domains. Thus, there is a commercial and economic justification both in respect of the OBE and the toll
systems for enabling interoperability. In Europe, for example, this need has been officially recognized and
legislation on interoperability has been adopted (see directive 2004/52/EC) and the associated commission
decision.
The Technical Specification “Electronic fee collection – Security framework” (CEN/TS 16439) provides an
overview of general security requirements of the stakeholders and provides a comprehensive threat analysis
for the assets in an interoperable EFC scheme. A number of identified threats may result into less revenue of
the Toll Charger, undercharging and/or not meeting required service levels between the Toll Service Provider
and the Toll Charger. Some of these threats can be eliminated by implementing the security measures
specified in CEN/TS 16439. However, most of the security measures necessary to combat the identified
threats are to be addressed and specified in other standards.
One example of threats that cannot be mitigated by security measures specified in CEN/TS 16439 concerns
the trustworthiness of Toll Declarations in autonomous toll systems. Toll declarations are statements that a
vehicle has been circulating in a particular toll domain within a particular time period. In autonomous toll
systems, the circulation of vehicles is measured by Toll Service Providers, using GNSS-based OBE. Toll
service providers then send Toll Declarations to the Toll Charger, based on which the Toll Charger will charge
the Toll Service Provider. The correctness and completeness of these declarations is obviously of paramount
interest to Toll Chargers, Toll Service Providers and users alike.
The secure monitoring compliance checking concept provides a solution that allows a Toll Charger to check
the trustworthiness of the Toll Declarations from a Toll Service Provider, while respecting the privacy of the
user. This concept is defined in two Technical Specifications. CEN/TS 16702-1:2014 “Secure monitoring for
autonomous toll systems – Part 1: Compliance checking” gives the full description of the secure monitoring
compliance checking concept. The current Technical Specification, CEN/TS 16702-2 “Secure Monitoring for
autonomous toll systems – Part 2: Trusted recorder” defines the Trusted Recorder, a secure element required
for some of the different types of secure monitoring compliance checking defined in CEN/TS 16702-1:2014.
Figure 1 — Relation between EFC - Security framework and the overall secure monitoring concept
Figure 1 shows the relations between the CEN/TS 16439 EFC Security Framework and EFC Secure
monitoring for autonomous toll systems, i.e. the two parts Compliance Checking and Trusted Recorder. The
threat analysis in the Security Framework motivates the security requirements of an EFC system. The
requirements are implemented and fulfilled by several security measures. One of these measures is Secure
Monitoring, specified in “Secure Monitoring for autonomous toll systems – Part 1: Compliance checking”. The
“Secure Monitoring for autonomous toll systems – Part 2: Trusted Recorder” specifies the cryptographic
services necessary for the secure monitoring compliance checking concept.
Figure 1 indicates also that a Trusted Recorder will most likely be implemented on trusted hardware, e.g. on
Secure Application Module (SAM), inside the OBE or on a general trusted platform of a vehicle. Such a
trusted device could support more functions, which may be required for EFC or other services.
1 Scope
This Technical Specification defines the requirements for the Secure Application Module (SAM) used in the
secure monitoring compliance checking concept. It specifies two different configurations of a SAM:
— Trusted Recorder, for use inside an OBE;
— Verification SAM, for use in other EFC system entities.
The Technical Specification describes
— terms and definitions used to describe the two Secure Application Module configurations;
— operation of the two Secure Application Modules in the secure monitoring compliance checking concept;
— functional requirements for the two Secure Application Modules configurations, including a classification
of different security levels;
— the interface, by means of transactions, messages and data elements, between an OBE or Front End and
the Trusted Recorder;
— requirements on basic security primitives and key management procedures to support Secure Monitoring
using a Trusted Recorder.
This Technical Specification is consistent with the EFC architecture as defined in ISO 17573 and the derived
suite of standards and Technical Specifications, especially CEN/TS 16702-1:2014 and CEN/TS 16439.
The following is outside the scope of this Technical Specification:
— The life cycle of a Secure Application Module and the way in which this is managed.
— The interface commands needed to get a Secure Application Module in an operational state.
— The interface definition of the Verification SAM.
— Definition of a hardware platform for the implementation of a Secure Application Module.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
CEN/TS 16439:2013 , Electronic fee collection - Security framework
CEN/TS 16702-1:2014, Electronic fee collection - Secure monitoring for autonomous toll systems - Part 1:
Compliance checking
EN ISO 14906:2011, Electronic fee collection - Application interface definition for dedicated short-range
communication (ISO 14906:2011)

1)
CEN/TS 16439:2013 is currently under revision and accepted as a CEN/ISO work item. The next edition will be
assigned the reference CEN ISO/TS 19299.
ISO/IEC 7816-4:2013, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 9797-1:2011, Information technology — Security techniques — Message Authentication Codes
(MACs) — Part 1: Mechanisms using a block cipher
ISO/IEC 10118-3, Information technology — Security techniques — Hash-functions — Part 3: Dedicated
hash-functions
ISO/IEC 14888-3:2006, Information technology — Security techniques — Digital signatures with appendix —
Part 3: Discrete logarithm based mechanisms
ISO/IEC 18031, Information technology — Security techniques — Random bit generation
ISO/IEC 18033-3:2010, Information technology — Security techniques — Encryption algorithms — Part 3:
Block ciphers
ISO/IEC 19790:2012, Information technology — Security techniques — Security requirements for
cryptographic modules
FIPS PUB 140-2, December 2002, Security requirements for cryptographic modules
Common Criteria Protection Profile BSI-PP-0035, 2007, Security IC Platform Protection Profile, Version 1.0
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
authentication
provision of assurance that a claimed characteristic of an entity is correct
[SOURCE: ISO/IEC 27000:2009, 2.5]
3.2
authenticator
data, possibly encrypted, that is used for authentication
Note 1 to entry: In this CEN/TS either a MAC or a signature.
3.3
authenticity
property that an entity is what it claims to be
[SOURCE: ISO/IEC 27000:2009, 2.6]
3.4
Back End
computing and communication facilities of an actor (e.g. a Toll Charger or a Toll Service Provider) exchanging
data with a Front or Back End
[SOURCE: CEN ISO/TS 17575-1:2010, 3.4]
3.5
Big Endian
systems in which the most significant byte of the word is stored in the smallest address given and the least
significant byte is stored in the largest
3.6
confidentiality
property that information is not made available or disclosed to unauthorised individuals, entities, or processes
[SOURCE: ISO/IEC 27000:2009, 2.9]
3.7
Front End
parts of the toll system where usage data for an individual user are collected, processed and delivered to the
Back End
Note 1 to entry: The Front End comprises the on-board equipment and an optional proxy.
[SOURCE: CEN ISO/TS 17575-1:2010, 3.13]
3.8
integrity
property that data has not been altered or destroyed in an unauthorized manner
3.9
itinerary
travel diary organized in one or more itinerary records enabling assessment of the correctness of the toll
declaration
3.10
issuer
institution (or its agent) that issues the Trusted Recorder
[SOURCE: adapted from ISO/IEC 7812-1:2006, 3.3]
3.11
Key Verification Code
calculated by encrypting one block of zeroes with the actual symmetric key, then truncated to leftmost three
bytes
[SOURCE: CEN/TS 16439:2013]
3.12
message authentication code
MAC
string of bits which is the output of a MAC algorithm
Note 1 to entry: A MAC is sometimes called a cryptographic check value (see for example ISO 7498-2).
[SOURCE: ISO/IEC 9797-1:2011, 3.9]
3.13
non-repudiation
ability to prove the occurrence of a claimed event or action and its originating entities, in order to resolve
disputes about the occurrence or non-occurrence of the event or action and about the involvement of entities
in the event
[SOURCE: ISO/IEC 27000:2009, 2.27]
3.14
on-board equipment
OBE
equipment fitted within or on the outside of a vehicle and used for toll purposes
[SOURCE: ISO 17573:2010, 3.9]
3.15
real-time freezing
freezing of each itinerary record as soon as its acquisition has terminated, using a Trusted Recorder
3.16
roadside equipment
equipment located along the road, ether fixed or mobile
3.17
signature
one or more data elements resulting from the signature process
[SOURCE: ISO/IEC 14888-1:2008, 3.12]
3.18
Signing Time Lock
pre-configured time interval that shall have elapsed since the last successful request to calculate an
authenticator before a Trusted Recorder calculates another authenticator
3.19
Secure Application Module
SAM
physically, electrically and logically protected module intended to contain algorithm(s), related keys, security
procedures and information to protect an application in such a way that unauthorized access is avoided by
tamper protection features
3.20
secure monitoring compliance checking
concept that allows a Toll Charger to rely on the trustworthiness of toll declarations produced by Toll Service
Providers
3.21
Toll Charger
TC
entity which levies toll for the use of vehicles in a toll domain
[SOURCE: ISO 17573:2010, 3.16]
3.22
toll declaration
statement to declare the usage of a given EFC service to a Toll Charger
3.23
toll domain
area or part of a road network where a toll regime is applied
[SOURCE: ISO 17573:2010, 3.18]
3.24
toll domain ID
unique identifier of a toll domain
3.25
toll service
service enabling users having only one contract and one set of OBE to use a vehicle in one or more toll
domains
[SOURCE: ISO 17573:2010, 3.22]
3.26
Toll Service Provider
TSP
entity providing toll services in one or more toll domains
[SOURCE: ISO 17573:2010, 3.23]
3.27
toll system
off board equipment and possible other provisions used by a Toll Charger for the collection of toll for vehicles
[SOURCE: ISO 17573:2010, 3.24]
3.28
Trusted Recorder
TR
logical entity capable of providing cryptographic services, including confidentiality, integrity, authenticity and
non-repudiation to be used inside an OBE
3.29
Trusted Third Party
TTP
security authority, or its agent, trusted by other entities with respect to security related activities
3.30
user
customer of a toll service provider, one liable for toll, the owner of the vehicle, a fleet operator, a driver, etc
Note 1 to entry: This is a generic term which is context dependent.
[SOURCE: ISO 17573:2010, 3.29]
3.31
Verification SAM
Secure Application Module capable of providing cryptographic services to verify a Trusted Recorder MAC in
such manner that the proof of non-repudiation is given
4 Symbols and abbreviations
ADU Application Data Unit
AES Advanced Encryption Standard (ISO/IEC 18033-3:2010)
BCD Binary Coded Decimal
CA Certification Authority
CLA Class byte
CMAC Cipher-based MAC
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
EETS European Electronic Toll Service
ID Identifier
INS Instruction byte
KVC Key Verification Code
MAC Message Authentication Code
NTP Network Time Protocol
OBE On-Board Equipment
P1, P2 Parameter bytes
PKI Public Key Infrastructure
PP Protection Profile
RQ Requirement
RSA Algorithm for public-key cryptography (Rivest, Shamir and Adleman)
RSE Roadside Equipment
SAM Secure Application Module
SNTP Simple Network Time Protocol
TC Toll Charger
TDC Toll Domain Counter
TR Trusted Recorder
TRID Trusted Recorder Identifier
TSP Toll Service Provider
TTP Trusted Third Party
TTS Trusted Time Source
UTC Coordinated Universal Time
5 SAM concept and scenarios
5.1 General
CEN/TS 16702-1:2014 defines requirements for a Trusted Recorder used in an OBE supporting symmetric
and asymmetric algorithms. A Verification SAM (for example in the RSE) is required to achieve the same
cryptographic proof of non-repudiation when using the symmetric algorithm compared to the asymmetric
algorithm. 5.2 of this Technical Specification is describing the two different configurations of the Secure
Application Module in the EFC context.
5.3, 5.4 and 5.5 describe the scenarios for the use of the TR and Verification SAM, motivated by
CEN/TS 16702-1:2014. The scenarios in these clauses cover all possible use cases for both SAM
configurations, a TR inside an OBE and a Verification SAM used in the RSE or another EFC entity.
NOTE Names and data flow elements in the diagrams in Clause 5 are symbolic and do not always give all details.
For details, refer to Clause 7.
5.2 The concepts of TR and Verification SAM
The Trusted Recorder is intended for the use inside OBE. The TR is responsible for freezing itineraries by
calculating an authenticator over each itinerary. This Technical Specification additionally defines the
requirements for a Verification SAM, which shall be used in other EFC system entities, for example in the
RSE, the TSP back office or the TC back office. The Verification SAM is responsible for the verification of
symmetric authenticators over itineraries, calculated by Trusted Recorders inside OBE.
The Trusted Recorder used in OBE is a logical entity with certain security functions to support the secure
monitoring compliance checking concept. If properly used, the Trusted Recorder and - if required - the
Verification SAM will ensure the authenticity, integrity and non-repudiation of data produced in OBE and/or a
Proxy implementing the secure monitoring compliance checking concept.

Figure 2 —Entities, standards/TS and interfaces in the context of secure monitoring compliance
checking
Figure 2 shows the entities relevant in the context of EFC and the link between the Trusted Recorder, the
Verification SAM and other entities and their interfaces and transactions.
Depending on its configuration (see Table 1 in 6.1.1), based on the requirements of the supported toll
schemes, a Trusted Recorder provides some or all of the following features:
— data authenticity and data integrity based on asymmetric (signature) or symmetric (MAC) cryptographic
algorithms;
— a Signing Time Lock to avoid that the OBE sends a request to authenticate data only in the event of an
external observation by the Toll Charger;
— storage and management of counters, to ensure a correct sequence of itineraries and detect missing
itineraries;
— secure storage and management of cryptographic keys.
NOTE 1 These capabilities are necessary for supporting the SM_CC-1 type of secure monitoring compliance checking
defined in CEN/TS 16702–1, 0.3.
The Trusted Recorder optionally provides:
— trusted time information.
NOTE 2 This capability is necessary for supporting the SM_CC-2 type of secure monitoring compliance checking
defined in CEN/TS 16702–1, 0.3.
The Verification SAM provides one specific function for the secure monitoring compliance checking concept.
This is the verification of symmetric authenticators.
5.3 Scenarios for a Trusted Recorder
5.3.1 General
This clause defines the scenarios valid for a Trusted Recorder used inside OBE in a vehicle.
5.3.2 Real-Time Freezing without using a Trusted Time Source
The Trusted Recorder may be used for real-time freezing of itineraries using symmetric cryptography or
asymmetric cryptography.
Figure 3 — Real-time freezing scenario
This scenario consists of the following steps:
1. The itinerary is sent to the Trusted Recorder. The itinerary is just data to be authenticated by the TR. A
TR shall not attempt to parse or interpret this data. As indicated in Figure 3, the TR also receives the
identifier of the key to be used to calculate the authenticator, and the identifier of the relevant toll
domain(s). According to CEN/TS 16702–1, E.4.1, up to four toll domain identifiers may be provided.
NOTE OBE will send more than one toll domain identifier in case of overlapping toll domains. In such cases, multiple
toll domain counters are used simultaneously. Detailed explanations can be found in CEN/TS 16702–1, E.4.1.
2. The TR retrieves the current value of the relevant toll domain counter(s) from its secure memory and
concatenates these value(s) with the DataToAuthenticate. In case less than four toll domain identifiers
are provided, for every ‘missing’ toll domain counter the TR adds a number of bytes with value zero to the
concatenated data, such that the length of the data is always the same.
3. The TR calculates the authenticator over the concatenated data, using the key identified by the
KeyIdentifier. The authenticator is either
1) a. A Message Authentication Code (MAC), calculated using a symmetric key.
2) b. A signature, calculated using the private key of an asymmetric key pair.
4. The TR increments the value of the relevant toll domain counter(s) by one and stores the new value(s).
5. The TR returns the authenticator, together with the (plaintext) value of the toll domain counter(s) to the
caller.
Interface and functional requirements are defined for this scenario in Clause 6 and Clause 7.
5.3.3 Real-Time Freezing using a Trusted Time Source
This is the same scenario as 5.3.2 with the following additions, as shown in Figure 4:
— In step 3, the TR also concatenates a time stamp to the DataToAuthenticate, before calculating the
authenticator. The TR retrieves the value of the time stamp from its trusted time source.
— In step 5, the TR also returns the time stamp.

Figure 4 — Real-time freezing with TTS
Functional requirements are defined for this scenario in Clause 6. Note that no interface requirements are
defined for this scenario in Clause 7.
5.4 Scenarios for a Verification SAM
5.4.1 General
This clause defines the scenarios valid for a Verification SAM used in a RSE, the TSP back office or the TC
back office.
5.4.2 MAC verification
Figure 5 — MAC verification
A Verification SAM may be used to verify the authenticity of the MAC over an itinerary record. This MAC is
supposed to be calculated by a Trusted Recorder inside OBE. The Verification SAM holds the same
symmetric key that was used by the TR to calculate the MAC.
NOTE In case a TR uses asymmetric cryptography to freeze the itinerary record, the presence of a Verification SAM
is not necessary. Any computer having access to the public key certificate of the TR is able to verify the signature.
However, the methods for distributing and verifying the TR certificates are out of scope of this Technical Specification.
Verification of a MAC is done by following these steps:
a) The itinerary record is sent to the Verification SAM. From the point of view of the SAM, this is just data to
be verified. A SAM shall not attempt to parse or interpret this data. As indicated in Figure 5, the SAM also
receives
1) a MAC that supposedly is valid for the data to be verified,
2) the identifier of the Trusted Recorder that supposedly calculated the MAC,
3) the identifier of the key supposedly used by the TR to calculate the MAC,
b) To prevent that each SAM has to contain all keys of all TRs whose outputs it may have to verify, the keys
of the Trusted Recorder shall be diversified based on some predefined diversification scheme. The
diversification data used shall be the TRID of the TR and the relevant key, as specified in
CEN/TS 16702–1, 7.2.2. Thus, the SAM is able to calculate the key used by the TR to calculate the MAC.
c) The Verification SAM calculates the MAC over the data to be verified, using the calculated MAC key, and
compares the result with the MAC provided in the call.
d) The result of the MAC verification (positive or negative) is returned to the caller
Functional requirements are defined for this scenario in Clause 6.
5.5 General Scenarios
5.5.1 General
This clause defines the general scenarios for the Trusted Recorder and the Verification SAM.
5.5.2 Assigning a Toll Domain Counter
A Trusted Recorder contains a number of Toll Domain Counters (TDCs). Each TDC is assigned to a specific
toll domain by a unique toll domain ID.
Assigning a Toll Domain Counter to a specific toll domain may be done either by the TR issuer before the
Trusted Recorder is issued, or by the TR itself during its lifetime. The first option may be used to ensure that
the Trusted Recorder will work in a number of pre-defined toll domains. The second option allows for a
dynamic, flexible allocation of Toll Domain Counters, depending on the toll domains a Trusted Recorder
encounters during its lifetime.
NOTE 1 A malicious OBE could in principle easily stop a Trusted Recorder from freezing any itineraries by assigning
all available Toll Domain Counters on the TR to non-existing Toll Domain IDs. To prevent this, the TR issuer could choose
to assign a number of TDCs to toll domains that it knows or expects the TR will use.
The exact process to use in case of pre-issuance allocation of TDCs is out of scope of this Technical
Specification.
The process to use in case the TR dynamically allocates a TDC to a specific toll domain consists of the
following steps:
— The TR receives a request to freeze an itinerary in real-time, as described in 5.3.2 or 5.3.3. The request
contains the ID of a toll domain for which the TR does not yet hold a Toll Domain Counter.
— The TR verifies whether it holds one or more Toll Domain Counters that are not yet assigned to a toll
domain.
— If this is the case, the TR assigns a TDC to the toll domain specified in the freezing request. It then
uses the current value of this TDC (which will be zero) to calculate the authenticator over the data to
be authenticated, and returns the authenticator plus the current value of the TDC to the caller, as
described in 5.3.2 or 5.3.3.
— If the TR does not hold a non-assigned Toll Domain Counter, it will deny the request to freeze the
itinerary data.
NOTE 2 The 'catch-all' toll domain counter concept defined in CEN/TS 16702–1, E.4.2 need to be implemented by the
OBE software based on an agreed value for the date element tollDomainId of the used TollDomainCounter. This means
that the OBE implements a list of toll domain IDs that are using the same TR TollDomainCounter in case of running out of
toll domain counters. The agreed identical toll domain ID of this 'catch-all' toll domain counter is also part of the frozen
itinerary instead of the real toll domain ID. The ‘catch-all’ toll domain counter could be assigned before the TR is issued, as
discussed in the previous Note.
5.5.3 Obtaining SAM Information
Depending on its configuration either as a TR or a Verification SAM, the TR or Verification SAM shall be able
to present Device Information, Toll Domain Counter Information and Key Information:
— Device Information consists of
— the TRID of the device as defined in Annex A. This ID will be used to derive the symmetric MAC key
used by the Trusted Recorder from a master key located in e.g. the Verification SAM,
— the Device Class identifying the capabilities of the Trusted Recorder, in accordance with Table 1 and
— the Device Specification Version, which is the version of this Technical Specification to which the
Trusted Recorder complies.
— Toll Domain Counter Information consists of the current value(s) of the Toll Domain Counter(s). Toll
Domain Information shall not be present for a Verification SAM.
— The Key information contains information that in detail identifies a key. Key information may also include
the CertificateID (if applicable).
Device Information and Key Information will be loaded to the TR by the Issuer. Toll Domain Counter
Information is stored in the TR during its lifetime.

Figure 6 — SAM identification
The data flow Toll Domain Counter Information as shown in Figure 6 is only available from a Trusted Recorder
but not from a Verification SAM. The interface and functional requirements for this
...