SIST-TS CEN/TS 16702-2:2020
(Main)Electronic fee collection - Secure monitoring for autonomous toll systems - Part 2: Trusted recorder
Electronic fee collection - Secure monitoring for autonomous toll systems - Part 2: Trusted recorder
This document 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.
This document 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 document is consistent with the EFC architecture as defined in EN ISO 17573-1 and the derived suite of standards and Technical Specifications, especially CEN/TS 16702-1 and CEN ISO/TS 19299.
The following is outside the scope of this document:
- 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.
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é
Elektronsko pobiranje pristojbin - Varnostno spremljanje avtonomnih cestninskih sistemov - 2. del: Zaupanja vreden snemalnik
Ta dokument določa zahteve za modul varnega dostopa (SAM), ki se uporablja pri konceptu preverjanja skladnosti varnostnega spremljanja. Določa dve različni konfiguraciji modula varnega dostopa:
– zaupanja vreden snemalnik: za uporabo v opremi v vozilu (OBE);
– modul varnega dostopa za preverjanje: za uporabo v drugih entitetah sistema za elektronsko pobiranje pristojbin (EFC).
Ta dokument podaja:
– izraze in definicije, ki so uporabljeni za opis teh dveh konfiguracij modula varnega dostopa;
– delovanje teh dveh modulov varnega dostopa v konceptu preverjanja skladnosti varnostnega spremljanja;
– funkcionalne zahteve za ti dve konfiguraciji modula varnega dostopa, vključno z razvrstitvijo različnih varnostnih ravni;
– vmesnik, prek transakcij, sporočil in podatkovnih elementov, med opremo v vozilu ali čelnim delom in zaupanja vrednim snemalnikom;
– zahteve glede osnovnih varnostnih primitivov in ključnih postopkov upravljanja kot podpora varnostnemu spremljanju z uporabo zaupanja vrednega snemalnika.
Ta dokument je v skladu z arhitekturo za elektronsko pobiranje pristojbin, kot je določena s standardom FprEN ISO 17573-1 in skupino izpeljanih standardov in tehničnih specifikacij, še posebej FprCEN/TS 16702-1 in CEN ISO/TS 19299.
Naslednje ne spada na področje uporabe tega dokumenta:
– življenjska doba modula varnega dostopa in način, na katerega se to upravlja;
– ukazi vmesnika, ki so potrebni za zagon modula varnega dostopa;
– definicija vmesnika modula varnega dostopa za preverjanje;
– definicija platforme za strojno opremo za izvajanje modula varnega dostopa
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
01-marec-2020
Nadomešča:
SIST-TS CEN/TS 16702-2: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:2020
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
CEN/TS 16702-2
TECHNICAL SPECIFICATION
SPÉCIFICATION TECHNIQUE
January 2020
TECHNISCHE SPEZIFIKATION
ICS 03.220.20; 35.240.60 Supersedes CEN/TS 16702-2:2015
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
systèmes autonomes de péage - Partie 2 : Enregistreur Überwachung von autonomen Mautsystemen - Teil 2:
fiabilisé Zuverlässige Datenaufzeichnung
This Technical Specification (CEN/TS) was approved by CEN on 25 November 2019 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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, 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: Rue de la Science 23, B-1040 Brussels
© 2020 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16702-2:2020 E
worldwide for CEN national Members.
Contents Page
European foreword . 4
Introduction . 5
1 Scope . 7
2 Normative references . 7
3 Terms and definitions . 8
4 Symbols and abbreviations . 12
5 SAM concept and scenarios . 13
5.1 General . 13
5.2 The concepts of TR and verification SAM . 13
5.3 Scenarios for a trusted recorder. 15
5.3.1 General . 15
5.3.2 Real-Time Freezing without using a Trusted Time Source . 15
5.3.3 Real-Time Freezing using a Trusted Time Source . 16
5.4 Scenarios for a verification SAM . 16
5.4.1 General . 16
5.4.2 MAC verification . 16
5.5 General Scenarios . 17
5.5.1 General . 17
5.5.2 Assigning a Toll Domain Counter . 17
5.5.3 Obtaining SAM Information . 18
6 Functional requirements. 19
6.1 General . 19
6.1.1 SAM options . 19
6.1.2 Presentation of requirements . 20
6.2 Basic requirements . 20
6.3 Key management . 21
6.4 Cryptographic functions . 21
6.5 Real-time freezing . 22
6.6 Verification SAM . 23
6.7 Toll Domain Counter . 23
6.8 Trusted time source . 24
6.9 Security protection level . 25
7 Interface requirements . 26
7.1 General . 26
7.2 Calculate MAC for real-time freezing . 26
7.2.1 General . 26
7.2.2 Calculation of MAC . 27
7.2.3 Coding of request . 27
7.2.4 Coding of response. 28
7.3 Calculate digital signature for real-time freezing . 28
7.3.1 General . 28
7.3.2 Calculation of digital signature . 29
7.3.3 Coding of request . 29
7.3.4 Coding of response . 29
7.4 Get device information . 30
7.4.1 General . 30
7.4.2 Coding of request . 30
7.4.3 Coding of response . 31
7.5 Get toll domain counter information. 31
7.5.1 General . 31
7.5.2 Coding of request . 31
7.5.3 Coding of response . 32
7.6 Get key information . 32
7.6.1 General . 32
7.6.2 Coding of request . 33
7.6.3 Coding of response . 33
7.7 Error handling . 34
Annex A (normative) Data type specification . 35
Annex B (normative) Implementation Conformance Statement (ICS) proforma . 36
Annex C (informative) Trusted Time Source implementation issues. 49
Annex D (informative) Use of this document for the EETS . 51
Bibliography . 53
European foreword
This document (CEN/TS 16702-2:2020) 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 shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN/TS 16702-2:2015.
The CEN/TS 16702 series, Electronic fee collection – Secure monitoring for autonomous toll systems, is
composed with the following parts:
— Part 1: Compliance checking;
— Part 2: Trusted recorder.
This document about the trusted recorder is the second part of the CEN/TS 16702 series about the secure
monitoring for autonomous toll systems. The overall concept of secure monitoring is defined in
CEN/TS 16702-1.
This second edition will supersede the first edition (CEN/TS 16702-2:2015), which was technically
revised. The main changes compared to the previous edition are as follows:
— references to underlaying standards updated to latest version;
— updated terminology;
— slight restructuring.
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 organisations of the
following countries are bound to announce this Technical Specification: Austria, Belgium, Bulgaria,
Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland,
Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Republic of
North Macedonia, Romania, Serbia, 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 on-board 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 supporting interoperability. In Europe, for example, this need is recognized and
legislation on interoperability has been adopted (see Directive 2004/52/EC) and the associated
Commission Decision.
CEN ISO/TS 19299, Electronic fee collection – Security framework (ISO/TS 19299), provides an overview
of general security requirements of the stakeholders and provides a comprehensive threat analysis for
the assets in an interoperable EFC scheme. Security attacks may result into less revenue of the toll
charger, undercharging 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 that are
specified. However, most of the security measures necessary to combat the identified threats are
addressed and specified in other standards.
One example of threats that cannot be mitigated by security measures specified in CEN ISO/TS 19299
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 are
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, whilst respecting the
privacy of the user. This concept is defined in the CEN/TS 16702 series:
• CEN/TS 16702-1, Electronic fee collection – Secure monitoring for autonomous toll systems – Part 1:
Compliance checking, which defines the secure monitoring compliance checking concept;
• CEN/TS 16702-2, Electronic fee collection – Secure monitoring for autonomous toll systems – Part 2:
Trusted recorder (this document), which defines the trusted recorder, a secure element required for
some of the different types of secure monitoring compliance checking concepts.
Figure 1 — Relation between EFC – Security framework and the overall secure monitoring
concept
Figure 1 shows the relations between CEN ISO/TS 19299, Electronic fee collection – Security framework,
and the CEN/TS 16702 series. 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 CEN/TS 16702-1, which defines 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 document 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 a piece of on-board equipment (OBE);
— verification SAM, for use in other EFC system entities.
This document describes
— terms and definitions used to describe the configurations of the two SAMs;
— operation of the two SAMs in the secure monitoring compliance checking concept;
— functional requirements for the configurations of the two SAMs, 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 document is consistent with the EFC architecture as defined in EN ISO 17573-1 and the derived suite
of standards and Technical Specifications, especially CEN/TS 16702-1 and CEN ISO/TS 19299.
The following is outside the scope of this document:
— The life cycle of a SAM and the way in which this is managed;
— The interface commands needed to get a SAM in an operational state;
— The interface definition of the verification SAM;
— Definition of a hardware platform for the implementation of a SAM.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
CEN/TS 16702-1:2020, Electronic fee collection - Secure monitoring for autonomous toll systems - Part 1:
Compliance checking
CEN ISO/TS 19299:2015, Electronic fee collection – Security framework (ISO/TS 19299)
EN ISO 14906, Electronic fee collection - Application interface definition for dedicated short-range
communication (ISO 14906)
ISO/IEC 7816-4:2013, Identification cards — Integrated circuit cards — Part 4: Organization, security and
commands for interchange
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER) — Part 2:
ISO/IEC 9797-1, Information technology — Security techniques — Message Authentication Codes (MACs)
— Part 1: Mechanisms using a block cipher
ISO/IEC 10118-3, IT Security techniques — Hash-functions — Part 3: Dedicated hash-functions
ISO/IEC 18031, Information technology — Security techniques — Random bit generation
ISO/IEC 18033-3, 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.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
• IEC Electropedia: available at http://www.electropedia.org/
• ISO Online browsing platform: available at http://www.iso.org/obp
3.1
authentication
security mechanism allowing the verification of the provided identity
[SOURCE: EN 301 175 V1.1.1 (1998-08), Clause 3]
3.2
authenticator
data, possibly encrypted, that is used for authentication
[SOURCE: EN 15509:2014, 3.3]
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: CEN ISO/TS 19299:2015, 3.5]
3.4
back end
part of a back office system interfacing to one or more front ends
[SOURCE: CEN ISO/TS 19299:2015, 3.7, modified — "back end" and "front end" originally had upper-case
characters.]
3.5
big-endian
format for transmission of binary data in which the most significant byte appears first
[SOURCE: ISO/IEC 14776-262:2017, 3.1.18, modified]
3.6
confidentiality
prevention of information leakage to non-authenticated individuals, parties or processes
[SOURCE: CEN ISO/TS 19299:2015, 3.11, modified — "and/or processes" was replaced with "or
processes".]
3.7
data integrity
property that data has not been altered or destroyed in an unauthorized manner
[SOURCE: ISO 7498-2:1989, 3.3.21]
3.8
digital signature
one or more data elements resulting from the digital signature process
[SOURCE: CEN ISO/TS 19299:2015, 3.11, 3.38]
3.9
front end
part of a tolling system consisting of on-board equipment (OBE) and possibly a proxy where road tolling
information and usage data are collected and processed for delivery to the back end
[SOURCE: CEN ISO/TS 19299:2015, 3.17, modified — "back end" and "front end" originally had upper-
case characters.]
3.10
itinerary
travel diary organized in one or more itinerary records enabling assessment of the correctness of the toll
declaration
3.11
message authentication code
MAC
fixed-length string of bits used to verify the authenticity of a message, generated by the sender of the
message, transmitted together with the message, and verified by the receiver of the message
[SOURCE: ISO 16609:2012, 3.15]
Note 1 to entry: A MAC is sometimes called a cryptographic check value (see for example ISO 7498-2).
3.12
non-repudiation
ability to prove the occurrence of a claimed event or action and its originating entities
[SOURCE: CEN ISO/TS 19299:2015, 3.27]
3.13
on-board equipment
OBE
required equipment on-board a vehicle for performing required electronic fee collection (EFC) functions
and communication services
3.14
real-time freezing
freezing of each itinerary record as soon as its acquisition has terminated, using a trusted recorder
3.15
roadside equipment
RSE
equipment located along the road, either fixed or mobile
3.16
Secure Application Module
SAM
physical module that securely executes cryptographic functions and stores keys
[SOURCE: CEN ISO/TS 19299:2015, 3.35]
3.17
secure monitoring compliance checking
concept that allows a toll charger to rely on the trustworthiness of toll declarations produced by toll
service providers
3.18
time lock
mechanism ensuring that a new operation can only be commissioned after a configurable period of time
or processor clock cycles since the previous operation
3.19
TR issuer
institution (or its agent) that issues the trusted recorder
[SOURCE: ISO/IEC 7812-1:2006, 3.3, adapted]
3.20
toll charger
TC
entity which levies toll for the use of vehicles in a toll domain
3.21
toll declaration
statement to declare the usage of a given toll service to a toll charger
[SOURCE: CEN ISO/TS 19299:2015, 3.44]
3.22
toll domain
area or a part of a road network where a certain toll regime is applied
3.23
toll domain ID
unique identifier of a toll domain
3.24
toll service
service enabling users to pay toll
3.25
toll service provider
TSP
entity providing toll services in one or more toll domains
3.26
trusted recorder
TR
logical entity capable of cryptographic functions, used to provide the on-board equipment (OBE) with
security services, including data confidentiality, data integrity, authentication and non-repudiation
3.27
Trusted Third Party
TTP
security authority, or its agent, trusted by other entities with respect to security related activities
[SOURCE: ISO/IEC 10181-1:1996, 3.3.30, modified]
3.28
toll service user
customer of a toll service provider, i.e. one liable for toll, owner of the vehicle, fleet operator or driver
depending on the context
Note 1 to entry: This is a generic term which is context dependent.
3.29
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
APDU Application Protocol Data Unit
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
GNSS Global Navigation Satellite System
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 defines requirements for a trusted recorder (TR) used in a piece of OBE, which supports
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. Subclause 6.2 of this document describes the two different configurations of the
SAM in the EFC context.
Subclauses 6.3, 6.4 and 6.5 describe the scenarios for the use of the TR and verification SAM, motivated
by CEN/TS 16702-1 (variations SM_CC-1 “Real-time Freezing using a TR without trusted time source”
and SM_CC-2 “Real-time Freezing using a TR with trusted time source”). 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 6 are symbolic and do not always give all details.
For details, refer to Clause 8.
5.2 The concepts of TR and verification SAM
The TR is intended for the use inside OBE. The TR is responsible for freezing itineraries by calculating an
authenticator over each itinerary. This document 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 TRs inside OBE.
The TR used in OBE is a logical entity with certain security functions to support the secure monitoring
compliance checking concept. If properly used, the TR 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 — Relevant standards in the context of secure monitoring compliance checking
Figure 2 shows the entities relevant in the context of EFC and the link between the TR, 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 TR provides one more of the following features:
— data authenticity and data integrity based on asymmetric (signature) or symmetric (MAC)
cryptographic algorithms;
— a 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:2020, 5.2.
The TR 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:2020, 5.2.
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 TR used inside OBE in a vehicle.
5.3.2 Real-Time Freezing without using a Trusted Time Source
The TR 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 TR. 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:2020, 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:2020, 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
a) a Message Authentication Code (MAC), calculated using a symmetric key or
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 7 and Clause 8.
5.3.3 Real-Time Freezing using a Trusted Time Source
This is the same scenario as 6.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 7. Note that no interface requirements
are defined for this scenario in Clause 8.
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 TR 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 of distribution and verification of the TR certificates are out of the Scope of this
document.
Verification of a MAC is done by the following 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 TR 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 TR 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:2020, 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 7.
5.5 General Scenarios
5.5.1 General
This subclause defines the general scenarios for the TR and the verification SAM.
5.5.2 Assigning a Toll Domain Counter
A TR 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 TDC to a specific toll domain may be done either by the TR issuer before the TR is issued, or
by the TR itself during its lifetime. The first option may be used to ensure that the TR will work in a
number of pre-defined toll domains. The second option allows for a dynamic, flexible allocation of TDCs,
depending on the toll domains a TR encounters during its lifetime.
NOTE A malicious OBE could in principle easily stop a TR from freezing any itineraries by assigning all available
TDCs 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 document.
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 6.3.2 or 6.3.3. The
request contains the ID of a toll domain for which the TR does not yet hold a TDC.
— The TR verifies whether it holds one or more TDCs 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 6.3.2 or 6.3.3.
— If the TR does not hold a non-assigned TDC, it will deny the request to freeze the itinerary data.
The 'catch-all' toll domain counter concept defined in CEN/TS 16702-1:2020, E.4.2 needs 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 NOTE above.
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 TR identifier (TRID) of the device as defined in Annex A. This ID will be used to derive the
symmetric MAC key used by the TR from a master key located in e.g. the verification SAM,
— the Device Class identifying the capabilities of the TR, in accordance with Table 1 and
— the Device Specification Version, which is the version of this document to which the TR complies.
— Toll Domain Counter Information consists of the current value(s) of the TDC(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 TR 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 TR but not
from a verification SAM. The interface and functional requirements for this scenario are defined in
Clause 7 and Clause 8.
6 Functional requirements
6.1 General
6.1.1 SAM options
The function set implemented in a SAM is depending on its planned use. This document defines the
following options for a SAM:
a) TR_symmetric: The SAM is able to produce a MAC based on symmetric keys stored in the TR and to
manage Toll Domain Counters.
b) TR_asymmetric: The SAM is able to produce a signature based on asymmetric private keys stored
in the TR and to manage Toll Domain Counters.
c) Trusted Time Source (TTS): The SAM is able to produce time stamps based on a TTS and to include
these in the data authenticated by the MAC or signature.
d) verification SAM: The SAM is able to verify a MAC.
e) Secure key import: The SAM supports a confidential key import of a verification key, based on an
asymmetric key encryption method and/or a symmetric key encryption method.
An implementation of a SAM will be a combination of several options. Table 1 shows the permissible
combinations of options. Other combinations of options are not allowed by this document.
Table 1 — SAM configurations
Supported options
Conf- SAM configuration
a) Symmetric b) Asymmetric c) Trusted d) verification e) Confidential
ID name
SM_CC SM_CC time source SAM key import
1 Symmetric TR X
2 TR without TTS X X
3 Full TR X X X
4 verification SAM X X
NOTE In case a TR supports both, symmetric and asymmetric algorithms a TC or an interoperable toll scheme
may limit the OBE to use only one of the supported authentication algorithms.
6.1.2 Presentation of requirements
Table 2 defines the format of the requirements specified in the following clauses.
Table 2 — Format of requirements
Header Content
RQ ID Unique requirement identifier
(requirement
RQ-B.x Basic requirements
identifier)
RQ-KM.x Key management
RQ-CF.x Cryptographic functions
RQ-RF.x Real-time freezing
RQ-VS.x verification SAM
RQ-TD.x Toll Domain Counter
RQ-TT.x Trusted Time Source
RQ-SP.x Security protection level
Requirement Description of the requirement
Conf-Ids The requirement shall be fulfilled by a SAM having the indicated configuration.
Possible configurations are listed in Table 1.
6.2 Basic requirements
The basic requirements presented in Table 3 are meant to ensure the ability to identify the TR or
verification SAM and its keys.
Table 3 — Basic requirements
RQ ID Requirement Conf-IDs
RQ-B.1 A TR or verification SAM shall have a 16-octet worldwide unique identifier, All
TRID.
RQ-B.2 A TR or verification SAM shall be able to present the TRID. All
RQ-B.3 A TR or verification SAM shall be able to present the identifiers of the keys All
that are located in the TR or verification SAM.
6.3 Key management
Table 4 contains the set of requirements regarding key management and defines the functionality for key
import, key generation, the key attributes and properties of the TR or verification SAM.
Table 4 — Key management requirements
RQ ID Requirement Conf-IDs
RQ-KM.1 The TR or verification SAM shall be able to store at least four 128-bit All
Advanced Encryption Standard (AES) keys.
RQ-KM.2 The verification SAM shall be able to confidentially import an encrypted AES 4
master key with the key encryption method
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...