Commission Implementing Regulation (EU) 2016/799Show full title

PART B SECOND-GENERATION TACHOGRAPH SYSTEM

7. INTRODUCTION

7.1. References

The following references are used in this part of this Appendix.

AES

National Institute of Standards and Technology (NIST), FIPS PUB 197: Advanced Encryption Standard (AES), November 26, 2001

DSS

National Institute of Standards and Technology (NIST), FIPS PUB 186-4: Digital Signature Standard (DSS), July 2013

ISO 7816-4

ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange. Third edition 2013-04-15

ISO 7816-8

ISO/IEC 7816-8, Identification cards — Integrated circuit cards — Part 8: Commands for security operations. Second edition 2004-06-01

ISO 8825-1

ISO/IEC 8825-1, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). Fourth edition, 2008-12-15

ISO 9797-1

ISO/IEC 9797-1, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher. Second edition, 2011-03-01

ISO 10116

ISO/IEC 10116, Information technology — Security techniques — Modes of operation of an n-bit block cipher. Third edition, 2006-02-01

ISO 16844-3

ISO/IEC 16844-3, Road vehicles — Tachograph systems — Part 3: Motion sensor interface. First edition 2004, including Technical Corrigendum 1 2006

RFC 5480

Elliptic Curve Cryptography Subject Public Key Information, March 2009

RFC 5639

Elliptic Curve Cryptography (ECC) — Brainpool Standard Curves and Curve Generation, 2010

RFC 5869

HMAC-based Extract-and-Expand Key Derivation Function (HKDF), May 2010

SHS

National Institute of Standards and Technology (NIST), FIPS PUB 180-4: Secure Hash Standard, March 2012

SP 800-38B

National Institute of Standards and Technology (NIST), Special Publication 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, 2005

TR-03111

BSI Technical Guideline TR-03111, Elliptic Curve Cryptography, version 2.00, 2012-06-28

7.2. Notations and Abbreviations

The following notations and abbreviated terms are used in this Appendix:

AES

Advanced Encryption Standard

CA

Certificate Authority

CAR

Certificate Authority Reference

CBC

Cipher Block Chaining (mode of operation)

CH

Command Header

CHA

Certificate Holder Authorisation

CHR

Certificate Holder Reference

CV

Constant Vector

DER

Distinguished Encoding Rules

DO

Data Object

DSRC

Dedicated Short Range Communication

ECC

Elliptic Curve Cryptography

ECDSA

Elliptic Curve Digital Signature Algorithm

ECDH

Elliptic Curve Diffie-Hellman (key agreement algorithm)

EGF

External GNSS Facility

EQT

Equipment

IDE

Intelligent Dedicated Equipment

K_M

Motion Sensor Master Key, allowing the pairing of a Vehicle Unit to a Motion Sensor

K_M-VU

Key inserted in vehicle units, allowing a VU to derive the Motion Sensor Master Key if a workshop card is inserted into the VU

K_M-WC

Key inserted in workshop cards, allowing a VU to derive the Motion Sensor Master Key if a workshop card is inserted into the VU

MAC

Message Authentication Code

MoS

Motion Sensor

MSB

Most Significant Bit

PKI

Public Key Infrastructure

RCF

Remote Communication Facility

SSC

Send Sequence Counter

SM

Secure Messaging

TDES

Triple Data Encryption Standard

TLV

Tag Length Value

VU

Vehicle Unit

X.C

the public key certificate of user X

X.CA

the certificate authority that issued the certificate of user X

X.CAR

the certificate authority reference mentioned in the certificate of user X

X.CHR

the certificate holder reference mentioned in the certificate of user X

X.PK

public key of user X

X.SK

private key of user X

X.PK_eph

ephemeral public key of user X

X.SK_eph

ephemeral private key of user X

‘xx’

a hexadecimal value

||

concatenation operator

7.3. Definitions

The definitions of terms used in this Appendix are included in section I of Annex 1C.

8. CRYPTOGRAPHIC SYSTEMS AND ALGORITHMS

8.1. Cryptographic Systems

CSM_38 Vehicle units and tachograph cards shall use an elliptic curve-based public-key cryptographic system to provide the following security services:

• mutual authentication between a vehicle unit and a card,

• agreement of AES session keys between a vehicle unit and a card,

• ensuring the authenticity, integrity and non-repudiation of data downloaded from vehicle units or tachograph cards to external media.

CSM_39 Vehicle units and external GNSS facilities shall use an elliptic curve-based public-key cryptographic system to provide the following security services:

• coupling of a vehicle unit and an external GNSS facility,

• mutual authentication between a vehicle unit and an external GNSS facility,

• agreement of an AES session key between a vehicle unit and an external GNSS facility.

CSM_40 Vehicle units and tachograph cards shall use an AES-based symmetric cryptographic system to provide the following security services:

• ensuring authenticity and integrity of data exchanged between a vehicle unit and a tachograph card,

• where applicable, ensuring confidentiality of data exchanged between a vehicle unit and a tachograph card.

CSM_41 Vehicle units and external GNSS facilities shall use an AES-based symmetric cryptographic system to provide the following security services:

• ensuring authenticity and integrity of data exchanged between a vehicle unit and an external GNSS facility.

CSM_42 Vehicle units and motion sensors shall use an AES-based symmetric cryptographic system to provide the following security services:

• pairing of a vehicle unit and a motion sensor,

• mutual authentication between a vehicle unit and a motion sensor,

• ensuring confidentiality of data exchanged between a vehicle unit and a motion sensor.

CSM_43 Vehicle units and control cards shall use an AES-based symmetric cryptographic system to provide the following security services on the remote communication interface:

• ensuring confidentiality, authenticity and integrity of data transmitted from a vehicle unit to a control card.

Notes:

— Properly speaking, data is transmitted from a vehicle unit to a remote interrogator under the control of a control officer, using a remote communication facility that may be internal or external to the VU, see Appendix 14. However, the remote interrogator sends the received data to a control card for decryption and validation of authenticity. From a security point of view, the remote communication facility and the remote interrogator are fully transparent.

— A workshop card offers the same security services for the DSRC interface as a control card does. This allows a workshop to validate the proper functioning of the remote communication interface of a VU, including security. Please refer to section 9.2.2 for more information.

8.2. Cryptographic Algorithms

8.2.1 Symmetric Algorithms

CSM_44 Vehicle units, tachograph cards, motion sensors and external GNSS facilities shall support the AES algorithm as defined in [AES], with key lengths of 128, 192 and 256 bits.

8.2.2 Asymmetric Algorithms and Standardized Domain Parameters

CSM_45 Vehicle units, tachograph cards and external GNSS facilities shall support elliptic curve cryptography with a key size of 256, 384 and 512/521 bits.

CSM_46 Vehicle units, tachograph cards and external GNSS facilities shall support the ECDSA signing algorithm, as specified in [DSS].

CSM_47 Vehicle units, tachograph cards and external GNSS facilities shall support the ECKA-EG key agreement algorithm, as specified in [TR 03111].

CSM_48 Vehicle units, tachograph cards and external GNSS facilities shall support all standardized domain parameters specified in Table 1 below for elliptic curve cryptography.

Table 1
Standardized domain parameters
Name	Size (bits)	Reference	Object identifier
NIST P-256	256	[DSS], [RFC 5480]
BrainpoolP256r1	256	[RFC 5639]
NIST P-384	384	[DSS], [RFC 5480]
BrainpoolP384r1	384	[RFC 5639]
BrainpoolP512r1	512	[RFC 5639]
NIST P-521	521	[DSS], [RFC 5480]

Note: the object identifiers mentioned in the last column of Table 1 are specified in [RFC 5639] for the Brainpool curves and in [RFC 5480] for the NIST curves.

8.2.3 Hashing algorithms

CSM_49 Vehicle units and tachograph cards shall support the SHA-256, SHA-384 and SHA-512 algorithms specified in [SHS].

8.2.4 Cipher Suites

CSM_50 In case a symmetric algorithm, an asymmetric algorithm and/or a hashing algorithm are used together to form a security protocol, their respective key lengths and hash sizes shall be of (roughly) equal strength. Table 2 shows the allowed cipher suites:

Table 2
Allowed cipher suites
Cipher suite Id	ECC key size (bits)	AES key length (bits)	Hashing algorithm	MAC length (bytes)
CS#1	256	128	SHA-256	8
CS#2	384	192	SHA-384	12
CS#3	512/521	256	SHA-512	16

Note: ECC keys sizes of 512 bits and 521 bits are considered to be equal in strength for all purposes within this Appendix.

9. KEYS AND CERTIFICATES

9.1. Asymmetric Key Pairs and Public Key Certificates

9.1.1 General

Note: the keys described in this section are used for mutual authentication and secure messaging between vehicle units and tachograph cards and between vehicle units and external GNSS facilities. These processes are described in detail in chapters 10 and 11 of this Appendix.

CSM_51 Within the European Smart Tachograph system, ECC key pairs and corresponding certificates shall be generated and managed through three functional hierarchical levels:

• European level,

• Member State level,

• Equipment level.

CSM_52 Within the entire European Smart Tachograph system, public and private keys and certificates shall be generated, managed and communicated using standardized and secure methods.

9.1.2 European Level

CSM_53 At European level, a single unique ECC key pair designated as EUR shall be generated. It shall consist of a private key (EUR.SK) and a public key (EUR.PK). This key pair shall form the root key pair of the entire European Smart Tachograph PKI. This task shall be handled by a European Root Certificate Authority (ERCA), under the authority and responsibility of the European Commission.

CSM_54 The ERCA shall use the European private key to sign a (self-signed) root certificate of the European public key, and shall communicate this European root certificate to all Member States.

CSM_55 The ERCA shall use the European private key to sign the certificates of the Member States public keys upon request. The ERCA shall keep records of all signed Member State public key certificates.

CSM_56 As shown in Figure 1 in section 9.1.7, the ERCA shall generate a new European root key pair every 17 years. Whenever the ERCA generates a new European root key pair, it shall create a new self-signed root certificate for the new European public key. The validity period of a European root certificate shall be 34 years plus 3 months.

Note: The introduction of a new root key pair also implies that ERCA will generate a new motion sensor master key and a new DSRC master key, see sections 9.2.1.2 and 9.2.2.2.

CSM_57 Before generating a new European root key pair, the ERCA shall conduct an analysis of the cryptographic strength that is needed for the new key pair, given it should stay secure for the next 34 years. If found necessary, the ERCA shall switch to a cipher suite that is stronger than the current one, as specified in CSM_50.

CSM_58 Whenever it generates a new European root key pair, the ERCA shall create a link certificate for the new European public key and sign it with the previous European private key. The validity period of the link certificate shall be 17 years. This is shown in Figure 1 in section 9.1.7 as well.

Note: Since a link certificate contains the ERCA generation X public key and is signed with the ERCA generation X-1 private key, a link certificate offers equipment issued under generation X-1 a method to trust equipment issued under generation X.

CSM_59 The ERCA shall not use the private key of a root key pair for any purpose after the moment a new root key certificate becomes valid.

CSM_60 At any moment in time, the ERCA shall dispose of the following cryptographic keys and certificates:

• The current EUR key pair and corresponding certificate

• All previous EUR certificates to be used for the verification of MSCA certificates that are still valid

• Link certificates for all generations of EUR certificates except the first one

9.1.3 Member State Level

CSM_61 At Member State level, all Member States required to sign tachograph card certificates shall generate one or more unique ECC key pairs designated as MSCA_Card. All Member States required to sign certificates for vehicle units or external GNSS facilities shall additionally generate one or more unique ECC key pairs designated as MSCA_VU-EGF.

CSM_62 The task of generating Member State key pairs shall be handled by a Member State Certificate Authority (MSCA). Whenever a MSCA generates a Member State key pair, it shall send the public key to the ERCA in order to obtain a corresponding Member State certificate signed by the ERCA.

CSM_63 An MSCA shall choose the strength of a Member State key pair equal to the strength of the European root key pair used to sign the corresponding Member State certificate.

CSM_64 An MSCA_VU-EGF key pair, if present, shall consist of private key MSCA_VU-EGF.SK and public key MSCA_VU-EGF.PK. An MSCA shall use the MSCA_VU-EGF.SK private key exclusively to sign the public key certificates of vehicle units and external GNSS facilities.

CSM_65 An MSCA_Card key pair shall consist of private key MSCA_Card.SK and public key MSCA_Card.PK. An MSCA shall use the MSCA_Card.SK private key exclusively to sign the public key certificates of tachograph cards.

CSM_66 An MSCA shall keep records of all signed VU certificates, external GNSS facility certificates and card certificates, together with the identification of the equipment for which each certificate is intended.

CSM_67 The validity period of an MSCA_VU-EGF certificate shall be 17 years plus 3 months. The validity period of an MSCA_Card certificate shall be 7 years plus 1 month.

CSM_68 As shown in Figure 1 in section 9.1.7, the private key of a MSCA_VU-EGF key pair and the private key of a MSCA_Card key pair shall have a key usage period of two years.

CSM_69 An MSCA shall not use the private key of an MSCA_VU-EGF key pair for any purpose after the moment its usage period has ended. Neither shall an MSCA use the private key of an MSCA_Card key pair for any purpose after the moment its usage period has ended.

CSM_70 At any moment in time, an MSCA shall dispose of the following cryptographic keys and certificates:

• The current MSCA_Card key pair and corresponding certificate

• All previous MSCA_Card certificates to be used for the verification of the certificates of tachograph cards that are still valid

• The current EUR certificate necessary for the verification of the current MSCA certificate

• All previous EUR certificates necessary for the verification of all MSCA certificates that are still valid

CSM_71 If an MSCA is required to sign certificates for vehicle units or external GNSS facilities, it shall additionally dispose of the following keys and certificates:

• The current MSCA_VU-EGF key pair and corresponding certificate

• All previous MSCA_VU-EGF public keys to be used for the verification of the certificates of VUs or external GNSS facilities that are still valid

9.1.4 Equipment Level: Vehicle Units

CSM_72 Two unique ECC key pairs shall be generated for each vehicle unit, designated as VU_MA and VU_Sign. This task is handled by VU manufacturers. Whenever a VU key pair is generated, the party generating the key shall send the public key to the MSCA of the country in which it resides, in order to obtain a corresponding VU certificate signed by the MSCA. The private key shall be used only by the vehicle unit.

CSM_73 The VU_MA and VU_Sign certificates of a given vehicle unit shall have the same Certificate Effective Date.

CSM_74 A VU manufacturer shall choose the strength of a VU key pair equal to the strength of the MSCA key pair used to sign the corresponding VU certificate.

CSM_75 A vehicle unit shall use its VU_MA key pair, consisting of private key VU_MA.SK and public key VU_MA.PK, exclusively to perform VU Authentication towards tachograph cards and external GNSS facilities, as specified in sections 10.3 and 11.4 of this Appendix.

CSM_76 A vehicle unit shall be capable of generating ephemeral ECC key pairs and shall use an ephemeral key pair exclusively to perform session key agreement with a tachograph card or external GNSS facility, as specified in sections 10.4 and 11.4 of this Appendix.

CSM_77 A vehicle unit shall use the private key VU_Sign.SK of its VU_Sign key pair exclusively to sign downloaded data files, as specified in chapter 14 of this Appendix. The corresponding public key VU_Sign.PK shall be used exclusively to verify signatures created by the vehicle unit.

CSM_78 As shown in Figure 1 in section 9.1.7, the validity period of a VU_MA certificate shall be 15 years and 3 months. The validity period of a VU_Sign certificate shall also be 15 years and 3 months.

Notes:

— The extended validity period of a VU_Sign certificate allows a Vehicle Unit to create valid signatures over downloaded data during the first three months after it has expired, as required in Regulation (EU) No 581/2010.

— The extended validity period of a VU_MA certificate is needed to allow the VU to authenticate to a control card or a company card during the first three months after it has expired, such that is it possible to perform a data download.

CSM_79 A vehicle unit shall not use the private key of a VU key pair for any purpose after the corresponding certificate has expired.

CSM_80 The VU key pairs (except ephemeral keys pairs) and corresponding certificates of a given vehicle unit shall not be replaced or renewed in the field once the vehicle unit has been put in operation.

Notes:

— Ephemeral key pairs are not included in this requirement, as a new ephemeral key pair is generated by a VU each time Chip Authentication and session key agreement is performed, see section 10.4. Note that ephemeral key pairs do not have corresponding certificates.

— This requirement does not forbid the possibility of replacing static VU key pairs during a refurbishment or repair in a secure environment controlled by the VU manufacturer.

CSM_81 When put in operation, vehicle units shall contain the following cryptographic keys and certificates:

• The VU_MA private key and corresponding certificate

• The VU_Sign private key and corresponding certificate

• The MSCA_VU-EGF certificate containing the MSCA_VU-EGF.PK public key to be used for verification of the VU_MA certificate and VU_Sign certificate

• The EUR certificate containing the EUR.PK public key to be used for verification of the MSCA_VU-EGF certificate

• The EUR certificate whose validity period directly precedes the validity period of the EUR certificate to be used to verify the MSCA_VU-EGF certificate, if existing

• The link certificate linking these two EUR certificates, if existing

CSM_82 In addition to the cryptographic keys and certificates listed in CSM_81, vehicle units shall also contain the keys and certificates specified in Part A of this Appendix, allowing a vehicle unit to interact with first-generation tachograph cards.

9.1.5 Equipment Level: Tachograph Cards

CSM_83 One unique ECC key pair, designated as Card_MA, shall be generated for each tachograph card. A second unique ECC key pair, designated as Card_Sign, shall additionally be generated for each driver card and each workshop card. This task may be handled by card manufacturers or card personalisers. Whenever a card key pair is generated, the party generating the key shall send the public key to the MSCA of the country in which it resides, in order to obtain a corresponding card certificate signed by the MSCA. The private key shall be used only by the tachograph card.

CSM_84 The Card_MA and Card_Sign certificates of a given driver card or workshop card shall have the same Certificate Effective Date.

CSM_85 A card manufacturer or card personaliser shall choose the strength of a card key pair equal to the strength of the MSCA key pair used to sign the corresponding card certificate.

CSM_86 A tachograph card shall use its Card_MA key pair, consisting of private key Card_MA.SK and public key Card_MA.PK, exclusively to perform mutual authentication and session key agreement towards vehicle units, as specified in sections 10.3 and 10.4 of this Appendix.

CSM_87 A driver card or workshop card shall use the private key Card_Sign.SK of its Card_Sign key pair exclusively to sign downloaded data files, as specified in chapter 14 of this Appendix. The corresponding public key Card_Sign.PK shall be used exclusively to verify signatures created by the card.

CSM_88 The validity period of a Card_MA certificate shall be as follows:

— For driver cards:	5 years
— For company cards:	2 years
— For control cards:	2 years
— For workshop cards:	1 year

CSM_89 The validity period of a Card_Sign certificate shall be as follows:

— For driver cards:	5 years and 1 month
— For workshop cards:	1 year and 1 month

Note: the extended validity period of a Card_Sign certificate allows a driver card to create valid signatures over downloaded data during the first month after it has expired. This is necessary in view of Regulation (EU) No 581/2010, which requires that a data download from a driver card must be possible up to 28 days after the last data has been recorded.

CSM_90 The key pairs and corresponding certificates of a given tachograph card shall not be replaced or renewed once the card has been issued.

CSM_91 When issued, tachograph cards shall contain the following cryptographic keys and certificates:

• The Card_MA private key and corresponding certificate

• For driver cards and workshop cards additionally: the Card_Sign private key and corresponding certificate

• The MSCA_Card certificate containing the MSCA_Card.PK public key to be used for verification of the Card_MA certificate and Card_Sign certificate

• The EUR certificate containing the EUR.PK public key to be used for verification of the MSCA_Card certificate.

• The EUR certificate whose validity period directly precedes the validity period of the EUR certificate to be used to verify the MSCA_Card certificate, if existing.

• The link certificate linking these two EUR certificates, if existing.

CSM_92 In addition to the cryptographic keys and certificates listed in CSM_91, tachograph cards shall also contain the keys and certificates specified in Part A of this Appendix, allowing these cards to interact with first-generation VUs.

9.1.6 Equipment Level: External GNSS Facilities

CSM_93 One unique ECC key pair shall be generated for each external GNSS facility, designated as EGF_MA. This task is handled by external GNSS facility manufacturers. Whenever an EGF_MA key pair is generated, the public key shall be sent to the MSCA of the country in which it resides, in order to obtain a corresponding EGF_MA certificate signed by the MSCA. The private key shall be used only by the external GNSS facility.

CSM_94 An EGF manufacturer shall choose the strength of an EGF_MA key pair equal to the strength of the MSCA key pair used to sign the corresponding EGF_MA certificate.

CSM_95 An external GNSS facility shall use its EGF_MA key pair, consisting of private key EGF_MA.SK and public key EGF_MA.PK, exclusively to perform mutual authentication and session key agreement towards vehicle units, as specified in section 11.4 and 11.4 of this Appendix.

CSM_96 The validity period of an EGF_MA certificate shall be 15 years.

CSM_97 An external GNSS facility shall not use the private key of its EGF_MA key pair for coupling to a vehicle unit after the corresponding certificate has expired.

Note: as explained in section 11.3.3, an EGF may potentially use its private key for mutual authentication towards the VU it is already coupled to, even after the corresponding certificate has expired.

CSM_98 The EGF_MA key pair and corresponding certificate of a given external GNSS facility shall not be replaced or renewed in the field once the EGF has been put in operation.

Note: This requirement does not forbid the possibility of replacing EGF key pairs during a refurbishment or repair in a secure environment controlled by the EGF manufacturer.

CSM_99 When put in operation, an external GNSS facility shall contain the following cryptographic keys and certificates:

• The EGF_MA private key and corresponding certificate

• The MSCA_VU-EGF certificate containing the MSCA_VU-EGF.PK public key to be used for verification of the EGF_MA certificate

• The EUR certificate containing the EUR.PK public key to be used for verification of the MSCA_VU-EGF certificate

• The EUR certificate whose validity period directly precedes the validity period of the EUR certificate to be used to verify the MSCA_VU-EGF certificate, if existing

• The link certificate linking these two EUR certificates, if existing

9.1.7 Overview: Certificate Replacement

Figure 1 below shows how different generations of ERCA root certificates, ERCA link certificates, MSCA certificates and equipment (VU and card) certificates are issued and used over time:

Figure 1

Issuance and usage of different generations of ERCA root certificates, ERCA link certificates, MSCA certificates and equipment certificates

Notes to Figure 1:

1. Different generations of the root certificate are indicated by a number in brackets. E.g. ERCA (1) is the first generation of ERCA root certificate; ERCA (2) is the second generation, etc.

2. Other certificates are indicated by two numbers in brackets, the first one indicating the root certificate generation under which they are issued, the second one the generation of the certificate itself. E.g. MSCA_Card (1-1) is the first MSCA_Card certificate issued under ERCA (1); MSCA_Card (2-1) is the first MSCA_Card certificate issued under ERCA (2); MSCA_Card (2-last) is the last MSCA_Card certificate issued under ERCA (2); Card_MA(2-1) is the first Card certificate for mutual authentication that is issued under ERCA (2), etc.

3. The MSCA_Card (2-1) and MSCA_Card (1-last) certificates are issued at almost but not exactly the same date. MSCA_Card (2-1) is the first MSCA_Card certificate issued under ERCA (2) and will be issued slightly later than MSCA_Card (1-last), the last MSCA_Card certificate under ERCA (1).

4. As shown in the figure, the first VU and Card certificates issued under ERCA (2) will appear almost two years before the last VU and Card certificates issued under ERCA (1) will appear. This is because of the fact that VU and Card certificates are issued under an MSCA certificate, not directly under the ERCA certificate. The MSCA (2-1) certificate will be issued directly after ERCA (2) becomes valid, but the MSCA (1-last) certificate will be issued only slightly before that time, at the last moment the ERCA (1) certificate is still valid. Therefore, these two MSCA certificates will have almost the same validity period, despite the fact that they are of different generations.

5. The validity period shown for cards is the one for driver cards (5 years).

6. To save space, the difference in validity period between the Card_MA and Card_Sign certificates and between the VU_MA and VU_Sign certificates is shown only for the first generation.

9.2. Symmetric Keys

9.2.1 Keys for Securing VU — Motion Sensor Communication

9.2.1.1 General

Note: readers of this section are supposed to be familiar with the contents of [ISO 16844-3] describing the interface between a vehicle unit and a motion sensor. The pairing process between a VU and a motion sensor is described in detail in chapter 12 of this Appendix.

CSM_100 A number of symmetric keys is needed for pairing vehicle units and motion sensors, for mutual authentication between vehicle units and motion sensors and for encrypting communication between vehicle units and motion sensors, as shown in Table 3. All of these keys shall be AES keys, with a key length equal to the length of the motion sensor master key, which shall be linked to the length of the (foreseen) European root key pair as described in CSM_50.

Table 3
Keys for securing vehicle unit — motion sensor communication
a Storage of KM and KID is optional, as these keys can be derived from KM-VU, KM-WC and CV.
Key	Symbol	Generated by	Generation method	Stored by
Motion Sensor Master Key — VU part	KM-VU	ERCA	Random	ERCA, MSCAs involved in issuing VUs certificates, VU manufacturers, vehicle units
Motion Sensor Master Key — Workshop part	KM-WC	ERCA	Random	ERCA, MSCAs, card manufacturers, workshop cards
Motion Sensor Master Key	KM	Not independently generated	Calculated as KM = KM-VU XOR KM-WC	ERCA, MSCAs involved in issuing motion sensors keys (optionally)a
Identification Key	KID	Not independently generated	Calculated as KID = KM XOR CV, where CV is specified in CSM_106	ERCA, MSCAs involved in issuing motion sensors keys (optionally)a
Pairing Key	KP	Motion sensor manufacturer	Random	One motion sensor
Session Key	KS	VU (during pairing of VU and motion sensor)	Random	One VU and one motion sensor

CSM_101 The European Root Certificate Authority shall generate K_M-VU and K_M-WC, two random and unique AES keys from which the motion sensor master key K_M can be calculated as K_M-VU XOR K_M-WC. The ERCA shall communicate K_M, K_M-VU and K_M-WC to Member State Certificate Authorities upon their request.

CSM_102 The ERCA shall assign to each motion sensor master key K_M a unique version number, which shall also be applicable for the constituting keys K_M-VU and K_M-WC and for the related identification key K_ID. The ERCA shall inform the MSCAs about the version number when sending K_M-VU and K_M-WC to them.

Note: The version number is used to distinguish different generations of these keys, as explained in detail in section 9.2.1.2.

CSM_103 A Member State Certificate Authority shall forward K_M-VU, together with its version number, to vehicle unit manufacturers upon their request. The VU manufacturers shall insert K_M-VU and its version number in all manufactured VUs.

CSM_104 A Member State Certificate Authority shall ensure that K_M-WC, together with its version number, is inserted in every workshop card issued under its responsibility.

Notes:

— See the description of data type in Appendix 2.

— as explained in section 9.2.1.2, in fact multiple generations of K_M-WC may have to be inserted in a single workshop card.

CSM_105 In addition to the AES key specified in CSM_104, a MSCA shall ensure that the TDES key Km_WC, specified in requirement CSM_037 in Part A of this Appendix, is inserted in every workshop card issued under its responsibility.

Notes:

— This allows a second-generation workshop card to be used for coupling a first-generation VU.

— A second-generation workshop card will contain two different applications, one complying with Part B of this Appendix and one complying with Part A. The latter will contain the TDES key Km_WC.

CSM_106 An MSCA involved in issuing motion sensors shall derive the identification key from the motion sensor master key by XORing it with a constant vector CV. The value of CV shall be as follows:

• For 128-bit motion sensor master keys: CV = ‘B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5E 83’

• For 192-bit motion sensor master keys: CV = ‘72 AD EA FA 00 BB F4 EE F4 99 15 70 5B 7E EE BB 1C 54 ED 46 8B 0E F8 25’

• For 256-bit motion sensor master keys: CV = ‘1D 74 DB F0 34 C7 37 2F 65 55 DE D5 DC D1 9A C3 23 D6 A6 25 64 CD BE 2D 42 0D 85 D2 32 63 AD 60’

Note: the constant vectors have been generated as follows:

• Pi_10 = first 10 bytes of the decimal portion of the mathematical constant π = ‘24 3F 6A 88 85 A3 08 D3 13 19’

• CV_128-bits = first 16 bytes of SHA-256(Pi_10)

• CV_192-bits = first 24 bytes of SHA-384(Pi_10)

• CV_256-bits = first 32 bytes of SHA-512(Pi_10)

CSM_107 Motion sensor manufacturers shall generate a random and unique pairing key K_P for every motion sensor, and shall send each pairing key to a Member State Certificate Authority. The MSCA shall encrypt each pairing key separately with the motion sensor master key K_M and shall return the encrypted key to the motion sensor manufacturer. For each encrypted key, the MSCA shall notify the motion sensor manufacturer of the version number of the associated K_M.

Note: as explained in section 9.2.1.2, in fact a motion sensor manufacturer may have to generate multiple unique pairing keys for a single motion sensor.

CSM_108 Motion sensor manufacturers shall generate a unique serial number for every motion sensor, and shall send all serial numbers to a Member State Certificate Authority. The MSCA shall encrypt each serial number separately with the identification key K_ID and shall return the encrypted serial number to the motion sensor manufacturer. For each encrypted serial number, the MSCA shall notify the motion sensor manufacturer of the version number of the associated K_ID.

CSM_109 For requirements CSM_107 and CSM_108, the MSCA shall use the AES algorithm in the Cipher Block Chaining mode of operation, as defined in [ISO 10116], with an interleave parameter m = 1 and an initialization vector SV = ‘00’ {16}, i.e. sixteen bytes with binary value 0. When necessary, the MSCA shall use padding method 2 defined in [ISO 9797-1].

CSM_110 The motion sensor manufacturer shall store the encrypted pairing key and the encrypted serial number in the intended motion sensor, together with the corresponding plain text values and the version number of K_M and K_ID used for encrypting.

Note: as explained in section 9.2.1.2, in fact a motion sensor manufacturer may have to insert multiple encrypted pairing keys and multiple encrypted serial numbers in a single motion sensor.

CSM_111 In addition to the AES-based cryptographic material specified in CSM_110, a motion sensor manufacturer may also store in each motion sensor the TDES-based cryptographic material specified in requirement CSM_037 in Part A of this Appendix.

Note: doing so will allow a second-generation motion sensor to be coupled to a first-generation VU.

CSM_112 The length of the session key K_S generated by a VU during the pairing to a motion sensor shall be linked to the length of its K_M-VU, as described in CSM_50.

9.2.1.2 Motion Sensor Master Key Replacement in Second-Generation Equipment

CSM_113 Each motion sensor master key and all related keys (see Table 3) is associated to a particular generation of the ERCA root key pair. These keys shall therefore be replaced every 17 years. The validity period of each motion sensor master key generation shall begin one year before the associated ERCA root key pair becomes valid and shall end when the associated ERCA root key pair expires. This is depicted in Figure 2.

Figure 2

Issuance and usage of different generations of the motion sensor master key in vehicle units, motions sensors and workshop cards

CSM_114 At least one year before generating a new European root key pair, as described in CSM_56, the ERCA shall generate a new motion sensor master key K_M by generating a new K_M-VU and K_M-WC. The length of the motion sensor master key shall be linked to the foreseen strength of the new European root key pair, according to CSM_50. The ERCA shall communicate the new K_M, K_M-VU and K_M-WC to the MSCAs upon their request, together with their version number.

CSM_115 An MSCA shall ensure that all valid generations of K_M-WC are stored in every workshop card issued under its authority, together with their version numbers, as shown in Figure 2.

Note: this implies that in the last year of the validity period of an ERCA certificate, workshop cards will be issued with three different generations of K_M-WC, as shown in Figure 2.

CSM_116 In relation to the process described in CSM_107 and CSM_108 above: An MSCA shall encrypt each pairing key K_P it receives from a motion sensor manufacturer separately with each valid generation of the motion sensor master key K_M. An MSCA shall also encrypt each serial number it receives from a motion sensor manufacturer separately with each valid generation of the identification key K_ID. A motion sensor manufacturer shall store all encryptions of the pairing key and all encryptions of the serial number in the intended motion sensor, together with the corresponding plain text values and the version number(s) of K_M and K_ID used for encrypting.

Note: This implies that in the last year of the validity period of an ERCA certificate, motion sensors will be issued with encrypted data based on three different generations of K_M, as shown in Figure 2.

CSM_117 In relation to the process described in CSM_107 above: Since the length of the pairing key K_P shall be linked to the length of K_M (see CSM_100), a motion sensor manufacturer may have to generate up to three different pairing keys (of different lengths) for one motion sensor, in case subsequent generations of K_M have different lengths. In such a case, the manufacturer shall send each pairing key to the MSCA. The MSCA shall ensure that each pairing key is encrypted with the correct generation of the motion sensor master key, i.e. the one having the same length.

Note: In case the motion sensor manufacturer chooses to generate a TDES-based pairing key for a second-generation motion sensor (see CSM_111), the manufacturer shall indicate to the MSCA that the TDES-based motion sensor master key must be used for encrypting this pairing key. This is because the length of a TDES key may be equal to that of an AES key, so the MSCA cannot judge from the key length alone.

CSM_118 Vehicle unit manufacturers shall insert only one generation of K_M-VU in each vehicle unit, together with its version number. This K_M-VU generation shall be linked to the ERCA certificate upon which the VU's certificates are based.

Notes:

— A vehicle unit based on the generation X ERCA certificate shall only contain the generation X K_M-VU, even if it is issued after the start of the validity period of the generation X+1 ERCA certificate. This is shown in Figure 2.

— A VU of generation X cannot be paired to a motion sensor of generation X-1.

— Since workshop cards have a validity period of one year, the result of CSM_113 — CSM_118 is that all workshop cards will contain the new K_M-WC at the moment the first VU containing the new K_M-VU is issued. Therefore, such a VU will always be able to calculate the new K_M. Moreover, by that time most new motion sensors will contain encrypted data based on the new K_M as well.

9.2.2 Keys for Securing DSRC Communication

9.2.2.1 General

CSM_119 The authenticity and confidentiality of data communicated from a vehicle unit to a control authority over a DSRC remote communication channel shall be ensured by means of a set of VU-specific AES keys derived from a single DSRC master key, KM_DSRC.

CSM_120 The DSRC master key KM_DSRC shall be an AES key that is securely generated, stored and distributed by the ERCA. The key length may be 128, 192 or 256 bits and shall be linked to the length of the European root key pair, as described in CSM_50.

CSM_121 The ERCA shall communicate the DSRC master key to Member State Certificate Authorities upon their request in a secure manner, to allow them to derive VU-specific DSRC keys and to ensure that the DSRC master key is inserted in all control cards and workshop cards issued under their responsibility.

CSM_122 The ERCA shall assign to each DSRC master key a unique version number. The ERCA shall inform the MSCAs about the version number when sending the DSRC master key to them.

Note: The version number is used to distinguish different generations of the DSRC master key, as explained in detail in section 9.2.2.2.

CSM_123 For every vehicle unit, the vehicle unit manufacturer shall create a unique VU serial number and shall send this number to its Member State Certificate Authority in a request to obtain a set of two VU-specific DSRC keys. The VU serial number shall have data type , and the Distinguished Encoding Rules (DER) according to [ISO 8825-1] shall be used for encoding.

CSM_124 Upon receiving a request for VU-specific DSRC keys, the MSCA shall derive two AES keys for the vehicle unit, called K_VU_DSRC_ENC and K_VU_DSRC_MAC. These VU-specific keys shall have the same length as the DSRC master key. The MSCA shall use the key derivation function defined in [RFC 5869]. The hash function that is necessary to instantiate the HMAC-Hash function shall be linked to the length of the DSRC master key, as described in CSM_50. The key derivation function in [RFC 5869] shall be used as follows:

• Step 1 (Extract):

  • PRK = HMAC-Hash (salt, IKM) where salt is an empty string ‘’ and IKM is KM_DSRC.

• Step 2 (Expand):

  • OKM = T(1), where

    T(1) = HMAC-Hash (PRK, T(0) || info || ‘01’) with

    • T(0) = an empty string (‘’)

    • info = VU serial number as specified in CSM_123

  • K_VU_DSRC_ENC = first L octets of OKM and

    K_VU_DSRC_MAC = last L octets of OKM

    where L is the required length of K_VU_DSRC_ENC and K_VU_DSRC_MAC in octets.

CSM_125 The MSCA shall distribute K_VU_DSRC_ENC and K_VU_DSRC_MAC to the VU manufacturer in a secure manner for insertion in the intended vehicle unit.

CSM_126 When issued, a vehicle unit shall have stored K_VU_DSRC_ENC and K_VU_DSRC_MAC in its secure memory, in order to be able to ensure the integrity, authenticity and confidentiality of data sent over the remote communication channel. A vehicle unit shall also store the version number of the DSRC master key used to derive these VU-specific keys.

CSM_127 When issued, control cards and workshop cards shall have stored KM_DSRC in their secure memory, in order to be able to verify the integrity and authenticity of data sent by a VU over the remote communication channel and to decrypt this data. Control cards and workshop cards shall also store the version number of the DSRC master key.

Note: as explained in section 9.2.2.2, in fact multiple generations of KM_DSRC may have to be inserted in a single workshop card or control card.

CSM_128 The MSCA shall keep records of all VU-specific DSRC keys it generated, their version number and the identification of the VU for which each set of keys is intended.

9.2.2.2 DSRC Master Key Replacement

CSM_129 Each DSRC master key is associated to a particular generation of the ERCA root key pair. The ERCA shall therefore replace the DSRC master key every 17 years. The validity period of each DSRC master key generation shall begin two years before the associated ERCA root key pair becomes valid and shall end when the associated ERCA root key pair expires. This is depicted in Figure 3.

Figure 3

Issuance and usage of different generations of the DSRC master key in vehicle units, workshop cards and control cards

CSM_130 At least two years before generating a new European root key pair, as described in CSM_56, the ERCA shall generate a new DSRC master key. The length of the DSRC key shall be linked to the foreseen strength of the new European root key pair, according to CSM_50. The ERCA shall communicate the new DSRC master key to the MSCAs upon their request, together with its version number.

CSM_131 An MSCA shall ensure that all valid generations of KM_DSRC are stored in every control card issued under its authority, together with their version numbers, as shown in Figure 3.

Note: this implies that in the last two years of the validity period of an ERCA certificate, control cards will be issued with three different generations of KM_DSRC, as shown in Figure 3.

CSM_132 An MSCA shall ensure that all generations of KM_DSRC that have been valid for at least a year and are still valid, are stored in every workshop card issued under its authority, together with their version numbers, as shown in Figure 3.

Note: this implies that in the last year of the validity period of an ERCA certificate, workshop cards will be issued with three different generations of KM_DSRC, as shown in Figure 3.

CSM_133 Vehicle unit manufacturers shall insert only one set of VU-specific DSRC keys into each vehicle unit, together with its version number. This set of keys shall be derived from the KM_DSRC generation linked to the ERCA certificate upon which the VU's certificates are based.

Notes:

— This implies that a vehicle unit based on the generation X ERCA certificate shall only contain the generation X K_VU_DSRC_ENC and K_VU_DSRC_MAC_, even if the VU is issued after the start of the validity period of the generation X+1 ERCA certificate. This is shown in Figure 3.

— Since workshop cards have a validity period of one year and control cards of two years, the result of CSM_131 — CSM_133 is that all workshop cards and control cards will contain the new DSRC master key at the moment the first VU containing VU-specific keys based on that master key will be issued.

9.3. Certificates

9.3.1 General

CSM_134 All certificates in the European Smart Tachograph system shall be self-descriptive, card-verifiable (CV) certificates according to [ISO 7816-4] and [ISO 7816-8].

CSM_135 The Distinguished Encoding Rules (DER) according to [ISO 8825-1] shall be used to encode both ASN.1 data structures and (application specific) data objects within certificates.

Note: this encoding results in a Tag-Length-Value (TLV) structure as follows:

Tag

:

The tag is encoded in one or two octets and indicates the content.

Length

:

The length is encoded as an unsigned integer in one, two, or three octets, resulting in a maximum length of 65 535 octets. The minimum number of octets shall be used.

Value

:

The value is encoded in zero or more octets

9.3.2 Certificate Content

CSM_136 All certificates shall have the structure shown in the certificate profile in Table 4.

Table 4
Certificate Profile version 1
Field	Field ID	Tag	Length (bytes)	ASN.1 data type(see Appendix 1)
ECC Certificate	C	‘7F 21’	var
ECC Certificate Body	B	‘7F 4E’	var
Certificate Profile Identifier	CPI	‘5F 29’	‘01’
Certificate Authority Reference	CAR	‘42’	‘08’
Certificate Holder Authorisation	CHA	‘5F 4C’	‘07’
Public Key	PK	‘7F 49’	var
Domain Parameters	DP	‘06’	var
Public Point	PP	‘86’	var
Certificate Holder Reference	CHR	‘5F 20’	‘08’
Certificate Effective Date	CEfD	‘5F 25’	‘04’
Certificate Expiration Date	CExD	‘5F 24’	‘04’
ECC Certificate Signature	S	‘5F 37’	var

Note: the Field ID will be used in later sections of this Appendix to indicate individual fields of a certificate, e.g. X.CAR is the Certificate Authority Reference mentioned in the certificate of user X.

9.3.2.1 Certificate Profile Identifier

CSM_137 Certificates shall use a Certificate Profile Identifier to indicate the certificate profile used. Version 1, as specified in Table 4, shall be identified by a value of ‘00’.

9.3.2.2 Certificate Authority Reference

CSM_138 The Certificate Authority Reference shall be used to identify the public key to be used to verify the certificate signature. The Certificate Authority Reference shall therefore be equal to the Certificate Holder Reference in the certificate of the corresponding certificate authority.

CSM_139 An ERCA root certificate shall be self-signed, i.e., the Certificate Authority Reference and the Certificate Holder Reference in the certificate shall be equal.

CSM_140 For an ERCA link certificate, the Certificate Holder Reference shall be equal to the CHR of the new ERCA root certificate. The Certificate Authority Reference for a link certificate shall be equal to the CHR of the previous ERCA root certificate.

9.3.2.3 Certificate Holder Authorisation

CSM_141 The Certificate Holder Authorisation shall be used to identify the type of certificate. It consists of the six most significant bytes of the Tachograph Application ID, concatenated with the type of equipment for which the certificate is intended.

9.3.2.4 Public Key

The Public Key nests two data elements: the standardized domain parameters to be used with the public key in the certificate and the value of the public point.

CSM_142 The data element Domain Parameters shall contain one of the object identifiers specified in Table 1 to reference a set of standardized domain parameters.

CSM_143 The data element Public Point shall contain the public point. Elliptic curve public points shall be converted to octet strings as specified in [TR-03111]. The uncompressed encoding format shall be used. When recovering an elliptic curve point from its encoded format, the validations described in [TR-03111] shall always be carried out.

9.3.2.5 Certificate Holder Reference

CSM_144 The Certificate Holder Reference is an identifier for the public key provided in the certificate. It shall be used to reference this public key in other certificates.

CSM_145 For card certificates and external GNSS facility certificates, the Certificate Holder Reference shall have the data type specified in Appendix 1.

CSM_146 For vehicle units, the manufacturer, when requesting a certificate, may or may not know the manufacturer-specific serial number of the VU for which that certificate and the associated private key is intended. In the first case, the Certificate Holder Reference shall have the data type specified in Appendix 1. In the latter case, the Certificate Holder Reference shall have the data type specified in Appendix 1.

CSM_147 For ERCA and MSCA certificates, the Certificate Holder Reference shall have the data type specified in Appendix 1.

9.3.2.6 Certificate Effective Date

CSM_148 The Certificate Effective Date shall indicate the starting date and time of the validity period of the certificate. The Certificate Effective Date shall be the date of the certificate generation.

9.3.2.7 Certificate Expiration Date

CSM_149 The Certificate Expiration Date shall indicate the end date and time of the validity period of the certificate.

9.3.2.8 Certificate Signature

CSM_150 The signature on the certificate shall be created over the encoded certificate body, including the certificate body tag and length. The signature algorithm shall be ECDSA, as specified in [DSS], using the hashing algorithm linked to the key size of the signing authority, as specified in CSM_50. The signature format shall be plain, as specified in [TR-03111].

9.3.3 Requesting Certificates

CSM_151 When requesting a certificate, a requester shall send the following data to its Certificate Authority:

• The Certificate Profile Identifier of the requested certificate

• The Certificate Authority Reference expected to be used for signing the certificate.

• The Public Key to be signed

CSM_152 In addition to the data in CSM_151, an MSCA shall send the following data in a certificate request to the ERCA, allowing the ERCA to create the Certificate Holder Reference of the new MSCA certificate:

• The numerical nation code of the Certification Authority (data type defined in Appendix 1)

• The alphanumerical nation code of the Certification Authority (data type defined in Appendix 1)

• The 1-byte serial number to distinguish the different keys of the Certification Authority in the case keys are changed

• The two-byte field containing Certification Authority specific additional info

CSM_153 In addition to the data in CSM_151, an equipment manufacturer shall send the following data in a certificate request to an MSCA, allowing the MSCA to create the Certificate Holder Reference of the new equipment certificate:

• A manufacturer-specific identifier of the equipment type

• If known (see CSM_154), a serial number for the equipment, unique for the manufacturer, the equipment's type and the month of manufacturing. Otherwise, a unique certificate request identifier.

• The month and the year of equipment manufacturing or of the certificate request.

The manufacturer shall ensure that this data is correct and that the certificate returned by the MSCA is inserted in the intended equipment.

CSM_154 In the case of a VU, the manufacturer, when requesting a certificate, may or may not know the manufacturer-specific serial number of the VU for which that certificate and the associated private key is intended. If known, the VU manufacturer shall send the serial number to the MSCA. If not known, the manufacturer shall uniquely identify each certificate request and send this certificate request serial number to the MSCA. The resulting certificate will then contain the certificate request serial number. After inserting the certificate in a specific VU, the manufacturer shall communicate the connection between the certificate request serial number and the VU identification to the MSCA.

10. VU- CARD MUTUAL AUTHENTICATION AND SECURE MESSAGING

10.1. General

CSM_155 On a high level, secure communication between a vehicle unit and a tachograph card shall be based on the following steps:

• First, each party shall demonstrate to the other that it owns a valid public key certificate, signed by a Member State Certificate Authority. In turn, the MSCA public key certificate must be signed by the European root certificate authority. This step is called certificate chain verification and is specified in detail in section 10.2

• Second, the vehicle unit shall demonstrate to the card that it is in possession of the private key corresponding to the public key in the presented certificate. It does so by signing a random number sent by the card. The card verifies the signature over the random number. If this verification is successful, the VU is authenticated. This step is called VU Authentication and is specified in detail in section 10.3.

• Third, both parties independently calculate two AES session keys using an asymmetric key agreement algorithm. Using one of these session keys, the card creates a message authentication code (MAC) over some data sent by the VU. The VU verifies the MAC. If this verification is successful, the card is authenticated. This step is called Card Authentication and is specified in detail in section 10.4.

• Fourth, the VU and the card shall use the agreed session keys to ensure the confidentiality, integrity and authenticity of all exchanged messages. This is called Secure Messaging and is specified in detail in section 10.5.

CSM_156 The mechanism described in CSM_155 shall be triggered by the vehicle unit whenever a card is inserted into one of its card slots.

10.2. Mutual Certificate Chain Verification

10.2.1 Card Certificate Chain Verification by VU

CSM_157 Vehicle units shall use the protocol depicted in Figure 4 for verifying a tachograph card's certificate chain.

Notes to Figure 4:

— The Card certificates and public keys mentioned in the figure are those for mutual authentication. Section 9.1.5 denotes these as Card_MA.

— The Card.CA certificates and public keys mentioned in the figure are those for signing card certificates and it is indicated in the CAR of the Card certificate. Section 9.1.3 denotes these as MSCA_Card.

— The Card.CA.EUR certificate mentioned in the figure is the European root certificate that is indicated in the CAR of the Card.CA certificate.

— The Card.Link certificate mentioned in the figure is the card's link certificate, if present. As specified in section 9.1.2, this is a link certificate for a new European root key pair created by the ERCA and signed by the previous European private key.

— The Card.Link.EUR certificate is the European root certificate that is indicated in the CAR of the Card.Link certificate.

CSM_158 As depicted in Figure 4, verification of the card's certificate chain shall begin upon card insertion. The vehicle unit shall read the card holder reference () from EF ICC. The VU shall check if it knows the card, i.e., if it has successfully verified the card's certificate chain in the past and stored it for future reference. If it does, and the card certificate is still valid, the process continues with the verification of the VU certificate chain. Otherwise, the VU shall successively read from the card the MSCA_Card certificate to be used for verifying the card certificate, the Card.CA. EUR certificate to be used for verifying the MSCA_Card certificate, and possibly the link certificate, until it finds a certificate it knows or it can verify. If such a certificate is found, the VU shall use that certificate to verify the underlying card certificates it has read from the card. If successful, the process continues with the verification of the VU certificate chain. If not successful, the VU shall ignore the card.

Note: There are three ways in which the VU may know the Card.CA.EUR certificate:

• the Card.CA.EUR certificate is the same certificate as the VU's own EUR certificate;

• the Card.CA.EUR certificate precedes the VU's own EUR certificate and the VU contained this certificate already at issuance (see CSM_81);

• the Card.CA.EUR certificate succeeds the VU's own EUR certificate and the VU received a link certificate in the past from another tachograph card, verified it and stored it for future reference.

CSM_159 As indicated in Figure 4, once the VU has verified the authenticity and validity of a previously unknown certificate, it may store this certificate for future reference, such that it does not need to verify that certificate's authenticity again if it is presented to the VU again. Instead of storing the entire certificate, a VU may choose to store only the contents of the Certificate Body, as specified in section 9.3.2.

CSM_160 The VU shall verify the temporal validity of any certificate read from the card or stored in its memory, and shall reject expired certificates. For verifying the temporal validity of a certificate presented by the card a VU shall use its internal clock.

Figure 4

Protocol for Card Certificate Chain Verification by VU

10.2.2 VU Certificate Chain Verification by Card

CSM_161 Tachograph cards shall use the protocol depicted in Figure 5 for verifying a VU's certificate chain.

Figure 5

Protocol for VU Certificate Chain Verification by Card

Notes to Figure 5:

— The VU certificates and public keys mentioned in the figure are those for mutual authentication. Section 9.1.4 denotes these as VU_MA.

— The VU.CA certificates and public keys mentioned in the figure are those for signing VU and external GNSS facility certificates. Section 9.1.3 denotes these as MSCA_VU-EGF.

— The VU.CA.EUR certificate mentioned in the figure is the European root certificate that is indicated in the CAR of the VU.CA certificate.

— The VU.Link certificate mentioned in the figure is the VU's link certificate, if present. As specified in section 9.1.2, this is a link certificate for a new European root key pair created by the ERCA and signed by the previous European private key.

— The VU.Link.EUR certificate is the European root certificate that is indicated in the CAR of the VU.Link certificate.

CSM_162 As depicted in Figure 5, verification of the certificate chain of the vehicle unit shall begin with the vehicle unit attempting to set its own public key for use in the tachograph card. If this succeeds, it means that the card successfully verified the VU's certificate chain in the past, and has stored the VU certificate for future reference. In this case, the VU certificate is set for use and the process continues with VU Authentication. If the card does not know the VU certificate, the VU shall successively present the VU.CA certificate to be used for verifying its VU certificate, the VU.CA.EUR certificate to be used for verifying the VU.CA certificate, and possibly the link certificate, in order to find a certificate known or verifiable by the card. If such a certificate is found, the card shall use that certificate to verify the underlying VU certificates presented to it. If successful, the VU shall finally set its public key for use in the tachograph card. If not successful, the VU shall ignore the card.

Note: There are three ways in which the card may know the VU.CA.EUR certificate:

— the VU.CA.EUR certificate is the same certificate as the card's own EUR certificate;

— the VU.CA.EUR certificate precedes the card's own EUR certificate and the card contained this certificate already at issuance (see CSM_91);

— the VU.CA.EUR certificate succeeds the card's own EUR certificate and the card received a link certificate in the past from another vehicle unit, verified it and stored it for future reference.

CSM_163 The VU shall use the MSE: Set AT command to set its public key for use in the tachograph card. As specified in Appendix 2, this command contains an indication of the cryptographic mechanism that will be used with the key that is set. This mechanism shall be ‘VU Authentication using the ECDSA algorithm, in combination with the hashing algorithm linked to the key size of the VU's VU_MA key pair, as specified in CSM_50’.

CSM_164 The MSE: Set AT command also contains an indication of the ephemeral key pair which the VU will use during session key agreement (see section 10.4). Therefore, before sending the MSE: Set AT command, the VU shall generate an ephemeral ECC key pair. For generating the ephemeral key pair, the VU shall use the standardized domain parameters indicated in the card certificate. The ephemeral key pair is denoted as (VU.SK_eph, VU.PK_eph, Card.DP). The VU shall take the x-coordinate of the ECDH ephemeral public point as the key identification; this is called the compressed representation of the public key and denoted as Comp(VU.PK_eph).

CSM_165 If the MSE: Set AT command is successful, the card shall set the indicated VU.PK for subsequent use during Vehicle Authentication, and shall temporarily store Comp(VU.PK_eph). In case two or more successful MSE: Set AT commands are sent before session key agreement is performed, the card shall store only the last Comp(VU.PK_eph) received.

CSM_166 The card shall verify the temporal validity of any certificate presented by the VU or referenced by the VU while stored in the card's memory, and shall reject expired certificates.

CSM_167 For verifying the temporal validity of a certificate presented by the VU, each tachograph card shall internally store some data representing the current time. This data shall not be directly updatable by a VU. At issuance, the current time of a card shall be set equal to the Effective Date of the card's Card_MA certificate. A card shall update its current time if the Effective Date of an authentic ‘valid source of time’ certificate presented by a VU is more recent than the card's current time. In that case, the card shall set its current time to the Effective Date of that certificate. The card shall accept only the following certificates as a valid source of time:

• Second-generation ERCA link certificates

• Second-generation MSCA certificates

• Second-generation VU certificates issued by the same country as the card's own card certificate(s).

Note: the last requirement implies that a card shall be able to recognize the CAR of the VU certificate, i.e. the MSCA_VU-EGF certificate. This will not be the same as the CAR of its own certificate, which is the MSCA_Card certificate.

CSM_168 As indicated in Figure 5, once the card has verified the authenticity and validity of a previously unknown certificate, it may store this certificate for future reference, such that it does not need to verify that certificate's authenticity again if it is presented to the card again. Instead of storing the entire certificate, a card may choose to store only the contents of the Certificate Body, as specified in section 9.3.2.

10.3. VU Authentication

CSM_169 Vehicle units and cards shall use the VU Authentication protocol depicted in Figure 6 to authenticate the VU towards the card. VU Authentication enables the tachograph card to explicitly verify that the VU is authentic. To do so, the VU shall use its private key to sign a challenge generated by the card.

CSM_170 Next to the card challenge, the VU shall include in the signature the card holder reference taken from the card certificate.

Note: This ensures that the card to which the VU authenticates itself is the same card whose certificate chain the VU has verified previously.

CSM_171 The VU shall also include in the signature the identifier of the ephemeral public key Comp(VU.PK_eph) which the VU will use to set up Secure Messaging during the Chip Authentication process specified in section 10.4.

Note: This ensures that the VU with which a card communicates during a Secure Messaging session is the same VU that was authenticated by the card.

Figure 6

VU Authentication protocol

CSM_172 If multiple GET CHALLENGE commands are sent by the VU during VU Authentication, the card shall return a new 8-byte random challenge each time, but shall store only the last challenge.

CSM_173 The signing algorithm used by the VU for VU Authentication shall be ECDSA as specified in [DSS], using the hashing algorithm linked to the key size of the VU's VU_MA key pair, as specified in CSM_50. The signature format shall be plain, as specified in [TR-03111]. The VU shall send the resulting signature to the card.

CSM_174 Upon receiving the VU's signature in an EXTERNAL AUTHENTICATE command, the card shall

• Calculate the authentication token by concatenating Card.CHR, the card challenge r_card and the identifier of the VU ephemeral public key Comp(VU.PK_eph),

• Calculate the hash over the authentication token, using the hashing algorithm linked to the key size of the VU's VU_MA key pair, as specified in CSM_50,

• Verify the VU's signature using the ECDSA algorithm in combination with VU.PK and the calculated hash.

10.4. Chip Authentication and Session Key Agreement

CSM_175 Vehicle units and cards shall use the Chip Authentication protocol depicted in Figure 7 to authenticate the card towards the VU. Chip Authentication enables the vehicle unit to explicitly verify that the card is authentic.

Figure 7

Chip Authentication and session key agreement

CSM_176 The VU and the card shall take the following steps:

1.

The vehicle unit initiates the Chip Authentication process by sending the MSE: Set AT command indicating ‘Chip Authentication using the ECDH algorithm resulting in an AES session key length linked to the key size of the card's Card_MA key pair, as specified in CSM_50’. The VU shall determine the key size of the card's key pair from the card certificate.

2.

The VU sends the public point VU.PK_eph of its ephemeral key pair to the card. As explained in CSM_164, the VU generated this ephemeral key pair prior to the verification of the VU certificate chain. The VU sent the identifier of the ephemeral public key Comp(VU.PK_eph) to the card, and the card stored it.

3.

The card computes Comp(VU.PK_eph) from VU.PK_eph and compares this to the stored value of Comp(VU.PK_eph).

4.

Using the ECDH algorithm in combination with the card's static private key and the VU's ephemeral public key, the card computes a secret K.

5.

The card chooses a random 8-byte nonce N_PICC and uses it to derive two AES session keys K_MAC and K_ENC from K. See CSM_179.

6.

Using K_MAC, the card computes an authentication token over the VU ephemeral public key identifier: T_PICC = CMAC(K_MAC, VU.PK_eph). The card sends N_PICC and T_PICC to the vehicle unit.

7.

Using the ECDH algorithm in combination with the card's static public key and the VU's ephemeral private key, the VU computes the same secret K as the card did in step 4.

8.

The VU derives session keys K_MAC and K_ENC from K and N_PICC; see CSM_179.

9.

The VU verifies the authentication token T_PICC.

CSM_177 In step 3 above, the card shall compute Comp(VU.PKeph) as the x-coordinate of the public point in VU.PKeph.

CSM_178 In steps 4 and 7 above, the card and the vehicle unit shall use the ECKA-EG algorithm as defined in [TR-03111].

CSM_179 In steps 5 and 8 above, the card and the vehicle unit shall use the key derivation function for AES session keys defined in [TR-03111], with the following precisions and changes:

• The value of the counter shall be ‘00 00 00 01’ for K_ENC and ‘00 00 00 02’ for K_MAC.

• The optional nonce r shall be used and shall be equal to N_PICC.

• For deriving 128-bits AES keys, the hashing algorithm to be used shall be SHA-256.

• For deriving 192-bits AES keys, the hashing algorithm to be used shall be SHA-384.

• For deriving 256-bits AES keys, the hashing algorithm to be used shall be SHA-512.

The length of the session keys (i.e. the length at which the hash is truncated) shall be linked to the size of the Card_MA key pair, as specified in CSM_50.

CSM_180 In steps 6 and 9 above, the card and the vehicle unit shall use the AES algorithm in CMAC mode, as specified in [SP 800-38B]. The length of T_PICC shall be linked to the length of the AES session keys, as specified in CSM_50.

10.5. Secure Messaging

10.5.1 General

CSM_181 All commands and responses exchanged between a vehicle unit and a tachograph card after successful Chip Authentication took place and until the end of the session shall be protected by Secure Messaging.

CSM_182 Except when reading from a file with access condition SM-R-ENC-MAC-G2 (see Appendix 2, section 4), Secure Messaging shall be used in authentication-only mode. In this mode, a cryptographic checksum (a.k.a. MAC) is added to all commands and responses to ensure message authenticity and integrity.

CSM_183 When reading data from a file with access condition SM-R-ENC-MAC-G2, Secure Messaging shall be used in encrypt-then-authenticate mode, i.e. the response data is encrypted first to ensure message confidentiality, and afterwards a MAC over the formatted encrypted data is calculated to ensure authenticity and integrity.

CSM_184 Secure Messaging shall use AES as defined in [AES] with the session keys K_MAC and K_ENC that were agreed during Chip Authentication.

CSM_185 An unsigned integer shall be used as the Send Sequence Counter (SSC) to prevent replay attacks. The size of the SSC shall be equal to the AES block size, i.e. 128 bits. The SSC shall be in MSB-first format. The Send Sequence Counter shall be initialized to zero (i.e. ‘00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00’) when Secure Messaging is started. The SSC shall be increased every time before a command or response APDU is generated, i.e. since the starting value of the SSC in a SM session is 0, in the first command the value of the SSC will be 1. The value of SSC for the first response will be 2.

CSM_186 For message encryption, K_ENC shall be used with AES in the Cipher Block Chaining (CBC) mode of operation, as defined in [ISO 10116], with an interleave parameter m = 1 and an initialization vector SV = E(K_ENC, SSC), i.e. the current value of the Send Sequence Counter encrypted with K_ENC.

CSM_187 For message authentication, K_MAC shall be used with AES in CMAC mode as specified in [SP 800-38B]. The length of the MAC shall be linked to the length of the AES session keys, as specified in CSM_50. The Send Sequence Counter shall be included in the MAC by prepending it before the datagram to be authenticated.

10.5.2 Secure Message Structure

CSM_188 Secure Messaging shall make use only of the Secure Messaging data objects (see [ISO 7816-4]) listed in Table 5. In any message, these data objects shall be used in the order specified in this table.

Table 5
Secure Messaging Data Objects
Data Object Name	Tag	Presence (M)andatory, (C)onditional or (F)orbidden in
		Commands	Responses
Plain value not encoded in BER-TLV	‘81’	C	C
Plain value encoded in BER-TLV, but not including SM DOs	‘B3’	C	C
Padding-content indicator followed by cryptogram, plain value not encoded in BER-TLV	‘87’	C	C
Protected Le	‘97’	C	F
Processing Status	‘99’	F	M
Cryptographic Checksum	‘8E’	M	M

Note: As specified in Appendix 2, tachograph cards may support the READ BINARY and UPDATE BINARY command with an odd INS byte (‘B1’ resp. ‘D7’). These command variants are required to read and update files with more than 32 768 bytes or more. In case such a variant is used, a data object with tag ‘B3’ shall be used instead of an object with tag ‘81’. See Appendix 2 for more information.

CSM_189 All SM data objects shall be encoded in DER TLV as specified in [ISO 8825-1]. This encoding results in a Tag-Length-Value (TLV) structure as follows:

Tag

:

The tag is encoded in one or two octets and indicates the content.

Length

:

The length is encoded as an unsigned integer in one, two, or three octets, resulting in a maximum length of 65 535 octets. The minimum number of octets shall be used.

Value

:

The value is encoded in zero or more octets

CSM_190 APDUs protected by Secure Messaging shall be created as follows:

• The command header shall be included in the MAC calculation, therefore value ‘0C’shall be used for the class byte CLA.

• As specified in Appendix 2, all INS bytes shall be even, with the possible exception of odd INS bytes for the READ BINARY and UPDATE BINARY commands.

• The actual value of Lc will be modified to Lc' after application of secure messaging.

• The Data field shall consist of SM data objects.

• In the protected command APDU the new Le byte shall be set to ‘00’. If required, a data object ‘97’ shall be included in the Data field in order to convey the original value of Le.

CSM_191 Any data object to be encrypted shall be padded according to [ISO 7816-4] using padding-content indicator ‘01’. For the calculation of the MAC, each data object in the APDU shall also be separately padded according to [ISO 7816-4].

Note: Padding for Secure Messaging is always performed by the secure messaging layer, not by the CMAC or CBC algorithms.

Summary and Examples

A command APDU with applied Secure Messaging will have the following structure, depending on the case of the respective unsecured command (DO is data object):

Case 1:	CLA INS P1 P2 || Lc' || DO ‘8E’ || Le
Case 2:	CLA INS P1 P2 || Lc' || DO ‘97’ || DO‘8E’ || Le
Case 3 (even INS byte):	CLA INS P1 P2 || Lc' || DO ‘81’ || DO‘8E’ || Le
Case 3 (odd INS byte):	CLA INS P1 P2 || Lc' || DO ‘B3’ || DO‘8E’ || Le
Case 4 (even INS byte):	CLA INS P1 P2 || Lc' || DO ‘81’ || DO‘97’ || DO‘8E’ || Le
Case 4 (odd INS byte):	CLA INS P1 P2 || Lc' || DO ‘B3’ || DO‘97’ || DO‘8E’ || Le

where Le = ‘00’ or ‘00 00’ depending on whether short length fields or extended length fields are used; see [ISO 7816-4].

A response APDU with applied Secure Messaging will have the following structure, depending on the case of the respective unsecured response:

Case 1 or 3:	DO ‘99’ || DO ‘8E’ || SW1SW2
Case 2 or 4 (even INS byte) with encryption:	DO ‘81’ || DO ‘99’ || DO ‘8E’ || SW1SW2
Case 2 or 4 (even INS byte) without encryption:	DO ‘87’ || DO ‘99’ || DO ‘8E’ || SW1SW2
Case 2 or 4 (odd INS byte) without encryption:	DO ‘B3’ || DO ‘99’ || DO ‘8E’ || SW1SW2

Note: Case 2 or 4 (odd INS byte) with encryption is never used in the communication between a VU and a card.

Below are three example APDU transformations for commands with even INS code. Figure 8 shows an authenticated Case 4 command APDU, Figure 9 shows an authenticated Case 2/Case 4 response APDU, and Figure 10 shows an encrypted and authenticated Case 2/Case 4 response APDU.

Figure 8

Transformation of an authenticated Case 4 Command APDU

Figure 9

Transformation of an authenticated Case 1 / Case 3 Response APDU

Figure 10

Transformation of an encrypted and authenticated Case 2/Case 4 Response APDU

10.5.3 Secure Messaging Session Abortion

CSM_192 A vehicle unit shall abort an ongoing Secure Messaging session if and only if one of the following conditions occur:

• it receives a plain response APDU,

• it detects a Secure Messaging error in a response APDU:

  • An expected Secure Messaging data object is missing, the order of data objects is incorrect, or an unknown data object is included.

  • A Secure Messaging data object is incorrect, e.g. the MAC value is incorrect, the TLV structure is incorrect or the padding indicator in tag ‘87’ is not equal to ‘01’.

• the card sends a status byte indicating it detected an SM error (see CSM_194),

• the limit for the number of commands and associated responses within the current session is reached. For a given VU, this limit shall be defined by its manufacturer, taking into account the security requirements of the hardware used, with a maximum value of 240 SM commands and associated responses per session.

CSM_193 A tachograph card shall abort an ongoing Secure Messaging session if and only if one of the following conditions occur:

• it receives a plain command APDU,

• it detects a Secure Messaging error in a command APDU:

  • An expected Secure Messaging data object is missing, the order of data objects is incorrect, or an unknown data object is included.

  • A Secure Messaging data object is incorrect, e.g. the MAC value is incorrect or the TLV structure is incorrect.

• it is depowered or reset,

• the VU selects an application on the card,

• the VU starts the VU Authentication process,

• the limit for the number of commands and associated responses within the current session is reached. For a given card, this limit shall be defined by its manufacturer, taking into account the security requirements of the hardware used, with a maximum value of 240 SM commands and associated responses per session.

CSM_194 Regarding SM error handling by a tachograph card:

• If in a command APDU some expected Secure Messaging data objects are missing, the order of data objects is incorrect or unknown data objects are included, a tachograph card shall respond with status bytes ‘69 87’.

• If a Secure Messaging data object in a command APDU is incorrect, a tachograph card shall respond with status bytes ‘69 88’.

In such a case, the status bytes shall be returned without using SM.

CSM_195 If a Secure Messaging session between a VU and a tachograph card is aborted, the VU and the tachograph card shall

• securely destroy the stored session keys

• immediately establish a new Secure Messaging session, as described in sections 10.2 — 10.5.

CSM_196 If for any reason the VU decides to restart mutual authentication towards an inserted card, the process shall restart with verification of the card certificate chain, as described in section 10.2, and shall continue as described in sections 10.2 — 10.5.

11. VU — EXTERNAL GNSS FACILITY COUPLING, MUTUAL AUTHENTICATION AND SECURE MESSAGING

11.1. General

CSM_197 The GNSS facility used by a VU to determine its position may be internal, (i.e. built into the VU casing and not detachable), or it may be an external module. In the first case, there is no need to standardize the internal communication between the GNSS facility and the VU, and the requirements in this chapter do not apply. In the latter case, communication between the VU and the external GNSS facility shall be standardized and protected as described in this chapter.

CSM_198 Secure communication between a vehicle unit and an external GNSS facility shall take place in the same way as secure communication between a vehicle unit and a tachograph card, with the external GNSS facility (EGF) taking the role of the card. All requirements mentioned in chapter 10 for tachograph cards shall be satisfied by an EGF, taking into account the deviations, clarifications and additions mentioned in this chapter. In particular, mutual certificate chain verification, VU Authentication and Chip Authentication shall be performed as described in sections 11.3 and 11.4.

CSM_199 Communication between a vehicle unit and an EGF differs from communication between a vehicle unit and a card in the fact that a vehicle unit and an EGF must be coupled once in a workshop before the VU and the EGF can exchange GNSS-based data during normal operation. The coupling process is described in section 11.2.

CSM_200 For communication between a vehicle unit and an EGF, APDU commands and responses based on [ISO 7816-4] and [ISO 7816-8] shall be used. The exact structure of these APDUs is defined in Appendix 2 of this Annex.

11.2. VU and External GNSS Facility Coupling

CSM_201 A vehicle unit and an EGF in a vehicle shall be coupled by a workshop. Only a coupled vehicle unit and EGF shall be able to communicate during normal operation.

CSM_202 Coupling of a vehicle unit and an EGF shall only be possible if the vehicle unit is in calibration mode. The coupling shall be initiated by the vehicle unit.

CSM_203 A workshop may re-couple a vehicle unit to another EGF or to the same EGF at any time. During re-coupling, the VU shall securely destroy the existing EGF_MA certificate in its memory and shall store the EGF_MA certificate of the EGF to which it is being coupled.

CSM_204 A workshop may re-couple an external GNSS facility to another VU or to the same VU at any time. During re-coupling, the EGF shall securely destroy the existing VU_MA certificate in its memory and shall store the VU_MA certificate of the VU to which it is being coupled.

11.3. Mutual Certificate Chain Verification

11.3.1 General

CSM_205 Mutual certificate chain verification between a VU and an EGF shall take place only during the coupling of the VU and the EGF by a workshop. During normal operation of a coupled VU and EGF, no certificates shall be verified. Instead, the VU and EGF shall trust the certificates they stored during the coupling, after checking the temporal validity of these certificates. The VU and the EGF shall not trust any other certificates for protecting the VU — EGF communication during normal operation.

11.3.2 During VU — EGF Coupling

CSM_206 During the coupling to an EGF, a vehicle unit shall use the protocol depicted in Figure 4 (section 10.2.1) for verifying the external GNSS facility's certificate chain.

Notes to Figure 4 within this context:

— Communication control is out of the scope of this Appendix. However, an EGF is not a smart card and hence the VU will probably not send a Reset to initiate the communication and will not receive an ATR.

— The Card certificates and public keys mentioned in the figure shall be interpreted as the EGF's certificates and public keys for mutual authentication. Section 9.1.6 denotes these as EGF_MA.

— The Card.CA certificates and public keys mentioned in the figure shall be interpreted as the MSCA's certificates and public keys for signing EGF certificates. Section 9.1.3 denotes these as MSCA_VU-EGF.

— The Card.CA.EUR certificate mentioned in the figure shall be interpreted as the European root certificate that is indicated in the CAR of the MSCA_VU-EGF certificate.

— The Card.Link certificate mentioned in the figure shall be interpreted as the EGF's link certificate, if present. As specified in section 9.1.2, this is a link certificate for a new European root key pair created by the ERCA and signed by the previous European private key.

— The Card.Link.EUR certificate is the European root certificate that is indicated in the CAR of the Card.Link certificate.

— Instead of the , the VU shall read the from EF ICC.

— Instead of selecting the Tachograph AID, the VU shall select the EGF AID.

— ‘Ignore Card’ shall be interpreted as ‘Ignore EGF’.

CSM_207 Once it has verified the EGF_MA certificate, the vehicle unit shall store this certificate for use during normal operation; see section 11.3.3.

CSM_208 During the coupling to a VU, an external GNSS unit shall use the protocol depicted in Figure 5 (section 10.2.2) for verifying the VU's certificate chain.

Notes to Figure 5 within this context:

— The VU shall generate a fresh ephemeral key pair using the domain parameters in the EGF certificate.

— The VU certificates and public keys mentioned in the figure are those for mutual authentication. Section 9.1.4 denotes these as VU_MA.

— The VU.CA certificates and public keys mentioned in the figure are those for signing VU and external GNSS facility certificates. Section 9.1.3 denotes these as MSCA_VU-EGF.

— The VU.CA.EUR certificate mentioned in the figure is the European root certificate that is indicated in the CAR of the VU.CA certificate.

— The VU.Link certificate mentioned in the figure is the VU's link certificate, if present. As specified in section 9.1.2, this is a link certificate for a new European root key pair created by the ERCA and signed by the previous European private key.

— The VU.Link.EUR certificate is the European root certificate that is indicated in the CAR of the VU.Link certificate.

CSM_209 In deviation from requirement CSM_167, an EGF shall use the GNSS time to verify the temporal validity of any certificate presented.

CSM_210 Once it has verified the VU_MA certificate, the external GNSS unit shall store this certificate for use during normal operation; see section 11.3.3.

11.3.3 During Normal Operation

CSM_211 During normal operation, a vehicle unit and an EGF shall use the protocol depicted in Figure 11 for verifying the temporal validity of the stored EGF_MA and VU_MA certificates and for setting the VU_MA public key for subsequent VU Authentication. No further mutual verification of the certificate chains shall take place during normal operation.

Note that Figure 11 in essence consists of the first steps shown in Figure 4 and Figure 5. Again, note that since an EGF is not a smart card, the VU will probably not send a Reset to initiate the communication and will not receive an ATR. In any case this is out of the scope of this Appendix.

Figure 11

Mutual verification of certificate temporal validity during normal VU — EGF operation

CSM_212 As shown in Figure 11, the vehicle unit shall log an error if the EGF_MA certificate is no longer valid. However, mutual authentication, key agreement and subsequent communication via secure messaging shall proceed normally.

11.4. VU Authentication, Chip Authentication and Session Key Agreement

CSM_213 VU Authentication, Chip Authentication and session key agreement between a VU and an EGF shall take place during coupling and whenever a Secure Messaging session is re-established during normal operation. The VU and the EGF shall carry out the processes described in sections 10.3 and 10.4. All requirements in these sections shall apply.

11.5. Secure Messaging

CSM_214 All commands and responses exchanged between a vehicle unit and an external GNSS facility after successful Chip Authentication took place and until the end of the session shall be protected by Secure Messaging.in authentication-only mode. All requirements in section 10.5 shall apply.

CSM_215 If a Secure Messaging session between a VU and an EGF is aborted, the VU shall immediately establish a new Secure Messaging session, as described in section 11.3.3 and 11.4.

12. VU — MOTION SENSOR PAIRING AND COMMUNICATION

12.1. General

CSM_216 A vehicle unit and a motion sensor shall communicate using the interface protocol specified in [ISO 16844-3] during pairing and in normal operation, with the changes described in this chapter and in section 9.2.1.

Note: readers of this chapter are supposed to be familiar with the contents of [ISO 16844-3].

12.2. VU — Motion Sensor Pairing Using Different Key Generations

As explained in section 9.2.1, the motion sensor master key and all associated keys are regularly replaced. This leads to the presence of up to three motion sensor-related AES keys K_M-WC (of consecutive key generations) in workshop cards. Similarly, in motion sensors up to three different AES-based encryptions of data (based on consecutive generations of the motion sensor master key K_M) may be present. A vehicle unit contains only one motion sensor-related key K_M-VU.

CSM_217 A second-generation VU and a second-generation motion sensor shall be paired as follows (compare Table 6 in [ISO 16844-3]):

1.

A second-generation workshop card is inserted into the VU and the VU is connected to the motion sensor.

2.

The VU reads all available K_M-WC keys from the workshop card, inspects their key version numbers and chooses the one matching the version number of the VU's K_M-VU key. If the matching K_M-WC key is not present on the workshop card, the VU aborts the pairing process and shows an appropriate error message to the workshop card holder.

3.

The VU calculates the motion sensor master key K_M from K_M-VU and K_M-WC, and the identification key K_ID from K_M, as specified in section 9.2.1.

4.

The VU sends the instruction to initiate the pairing process towards the motion sensor, as described in [ISO 16844-3], and encrypts the serial number it receives from the motion sensor with the identification key K_ID. The VU sends the encrypted serial number back to the motion sensor.

5.

The motion sensor matches the encrypted serial number consecutively with each of the encryptions of the serial number it holds internally. If it finds a match, the VU is authenticated. The motion sensor notes the generation of K_ID used by the VU and returns the matching encrypted version of its pairing key; i.e. the encryption that was created using the same generation of K_M.

6.

The VU decrypts the pairing key using K_M, generates a session key K_S, encrypts it with the pairing key and sends the result to the motion sensor. The motion sensor decrypts K_S.

7.

The VU assembles the pairing information as defined in [ISO 16844-3], encrypts the information with the pairing key, and sends the result to the motion sensor. The motion sensor decrypts the pairing information.

8.

The motion sensor encrypts the received pairing information with the received K_S and returns this to the VU. The VU verifies that the pairing information is the same information which the VU sent to the motion sensor in the previous step. If it is, this proves that the motion sensor used the same K_S as the VU and hence in step 5 sent its pairing key encrypted with the correct generation of K_M. Hence, the motion sensor is authenticated.

Note that steps 2 and 5 are different from the standard process in [ISO 16844-3]; the other steps are standard.

Example: Suppose a pairing takes place in the first year of the validity of the ERCA (3) certificate; see Figure 2 in section 9.2.1.2. Moreover

• Suppose the motion sensor was issued in the last year of the validity of the ERCA (1) certificate. It will therefore contain the following keys and data:

  • N_s[1]: its serial number encrypted with generation 1 of K_ID,

  • N_s[2]: its serial number encrypted with generation 2 of K_ID,

  • N_s[3]: its serial number encrypted with generation 3 of K_ID,

  • K_P[1]: its generation-1 pairing key(1), encrypted with generation 1 of K_M,

  • K_P[2]: its generation-2 pairing key, encrypted with generation 2 of K_M,

  • K_P[3]: its generation-3 pairing key, encrypted with generation 3 of K_M,

• Suppose that the workshop card was issued in the first year of the validity of the ERCA (3) certificate. It will therefore contain the generation 2 and generation 3 of the K_M-WC key.

• Suppose the VU is a generation-2 VU, containing the generation 2 of K_M-VU.

In this case, the following will happen in steps 2 — 5:

• Step 2: The VU reads generation 2 and generation 3 of K_M-WC from the workshop card and inspects their version numbers.

• Step 3: The VU combines the generation-2 K_M-WC with its K_M-VU to compute K_M and K_ID.

• Step 4: The VU encrypts the serial number it receives from the motion sensor with K_ID.

• Step 5: The motion sensor compares the received data with N_s[1] and doesn't find a match. Next, it compares the data with N_s[2] and finds a match. It concludes that the VU is a generation-2 VU, and therefore sends back K_P[2].

12.3. VU — Motion Sensor Pairing and Communication using AES

CSM_218 As specified in Table 3 in section 9.2.1, all keys involved in the pairing of a (second-generation) vehicle unit and a motion sensor and in subsequent communication shall be AES keys, rather than double-length TDES keys as specified in [ISO 16844-3]. These AES keys may have a length of 128, 192 or 256 bits. Since the AES block size is 16 bytes, the length of an encrypted message must be a multiple of 16 bytes, compared to 8 bytes for TDES. Moreover, some of these messages will be used to transport AES keys, the length of which may be 128, 192 or 256 bits. Therefore, the number of data bytes per instruction in Table 5 of [ISO 16844-3] shall be changed as shown in Table 6:

Table 6
Number of plaintext and encrypted data bytes per instruction defined in [ISO 16844-3]
Instruction	Request / reply	Description of data	# of plaintext data bytes according to [ISO 16844-3]	# of plaintext data bytes using AES keys	# of encrypted data bytes when using AES keys of bitlength
					128	192	256
10	request	Authentication data + file number	8	8	16	16	16
11	reply	Authentication data + file contents	16 or 32, depend on file	16 or 32, depend on file	16 / 32	16 / 32	16 / 32
41	request	MoS serial number	8	8	16	16	16
41	reply	Pairing key	16	16 / 24 / 32	16	32	32
42	request	Session key	16	16 / 24 / 32	16	32	32
43	request	Pairing information	24	24	32	32	32
50	reply	Pairing information	24	24	32	32	32
70	request	Authentication data	8	8	16	16	16
80	reply	MoS counter value + auth. data	8	8	16	16	16

CSM_219 The pairing information that is sent in instructions 43 (VU request) and 50 (MoS reply) shall be assembled as specified in section 7.6.10 of [ISO 16844-3], except that the AES algorithm shall be used instead of the TDES algorithm in the pairing data encryption scheme, thus resulting in two AES encryptions, and adopting the padding specified in CSM_220 to fit with the AES block size. The key K'_p used for this encryption shall be generated as follows:

• In case the pairing key K_P is 16 bytes long: K'_p = K_P XOR (N_s||N_s)

• In case the pairing key K_P is 24 bytes long: K'_p = K_P XOR (N_s||N_s||N_s)

• In case the pairing key K_P is 32 bytes long: K'_p = K_P XOR (N_s||N_s||N_s||N_s)

where N_s is the 8-byte serial number of the motion sensor.

CSM_220 In case the plaintext data length (using AES keys) is not a multiple of 16 bytes, padding method 2 defined in [ISO 9797-1] shall be used.

Note: in [ISO 16844-3], the number of plaintext data bytes is always a multiple of 8, such that padding is not necessary when using TDES. The definition of data and messages in [ISO 16844-3] is not changed by this part of this Appendix, thus necessitating the application of padding.

CSM_221 For instruction 11 and in case more than one block of data must be encrypted, the Cipher Block Chaining mode of operation shall be used as defined in [ISO 10116], with an interleave parameter m = 1. The IV to be used shall be

• For instruction 11: the 8-byte authentication block specified in section 7.6.3.3 of [ISO 16844-3], padded using padding method 2 defined in [ISO 9797-1]; see also section 7.6.5 and 7.6.6 of [ISO 16844-3].

• For all other instructions in which more than 16 bytes are transferred, as specified in Table 6: ‘00’ {16}, i.e. sixteen bytes with binary value 0.

Note: As shown in section 7.6.5 and 7.6.6 of [ISO 16844-3], when the MoS encrypts data files for inclusion in instruction 11, the authentication block is both

• Used as the initialization vector for the CBC-mode encryption of the data files

• Encrypted and included as the first block in the data that is sent to the VU.

12.4. VU — Motion Sensor Pairing For Different Equipment Generations

CSM_222 As explained in section 9.2.1, a second-generation motion sensor may contain the TDES-based encryption of the pairing data (as defined in Part A of this Appendix), which allows the motion sensor to be paired to a first-generation VU. If this is the case, a first-generation VU and a second-generation motion sensor shall be paired as described in Part A of this Appendix and in [ISO 16844-3]. For the pairing process either a first-generation or a second-generation workshop card may be used.

Notes:

— It is not possible to pair a second-generation VU to a first-generation motion sensor.

— It is not possible to use a first-generation workshop card for coupling a second-generation VU to a motion sensor.

13. SECURITY FOR REMOTE COMMUNICATION OVER DSRC

13.1. General

As specified in Appendix 14, a VU regularly generates Remote Tachograph Monitoring (RTM) data and sends this data to the (internal or external) Remote Communication Facility (RCF). The remote communication facility is responsible for sending this data over the DSRC interface described in Appendix 14 to the remote interrogator. Appendix 1 specifies that the RTM data is the concatenation of:

Encrypted tachograph payload

the encryption of the plaintext tachograph payload

DSRC security data

described below

The plaintext tachograph payload data format is specified in Appendix 1 and further described in Appendix 14. This section describes the structure of the DSRC security data; the formal specification is in Appendix 1.

CSM_223 The plaintext data communicated by a VU to a Remote Communication Facility (if the RCF is external to the VU) or from the VU to a remote interrogator over the DSRC interface (if the RCF is internal in the VU) shall be protected in encrypt-then-authenticate mode, i.e. the tachograph payload data is encrypted first to ensure message confidentiality, and afterwards a MAC is calculated to ensure data authenticity and integrity.

CSM_224 The DSRC security data shall consist of the concatenation of the following data elements in the following order; see also Figure 12:

Current date time

the current date and time of the VU (data type )

Counter

a 3-byte counter, see CSM_225

VU serial number

the VU's serial number (data type )

DSRC master key version number

the 1-byte version number of the DSRC master key from which the VU-specific DSRC keys were derived, see section 9.2.2.

MAC

the MAC calculated over all previous bytes in the RTM data.

CSM_225 The 3-byte counter in the DSRC security data shall be in MSB-first format. The first time a VU calculates a set of RTM data after it is taken into production, it shall set the value of the counter to 0. The VU shall increase the value of the counter data by 1, each time before it calculates a next set of RTM data.

13.2. Tachograph Payload Encryption and MAC Generation

CSM_226 Given a plaintext data element with data type as described in Appendix 14, a VU shall encrypt this data as shown in Figure 12: the VU's DSRC key for encryption K_VU_DSRC_ENC (see section 9.2.2) shall be used with AES in the Cipher Block Chaining (CBC) mode of operation, as defined in [ISO 10116], with an interleave parameter m = 1. The initialization vector shall be equal to IV = current date time || ‘00 00 00 00 00 00 00 00 00’ || counter, where current date time and counter are specified in CSM_224. The data to be encrypted shall be padded using method 2 defined in [ISO 9797-1].

CSM_227 A VU shall calculate the MAC in the DSRC security data as shown in Figure 12: the MAC shall be calculated over all preceding bytes in the RTM data, up to and including the DSRC master key version number, and including the tags and lengths of the data objects. The VU shall use its DSRC key for authenticity K_VU_DSRC_MAC (see section 9.2.2) with the AES algorithm in CMAC mode as specified in [SP 800-38B]. The length of the MAC shall be linked to the length of the VU-specific DSRC keys, as specified in CSM_50.

Figure 12

Tachograph payload encryption and MAC generation

13.3. Verification and Decryption of Tachograph Payload

CSM_228 When a remote interrogator receives RTM data from a VU, it shall send the entire RTM data to a control card in the data field of a PROCESS DSRC MESSAGE command, as described in Appendix 2. Then:

1.

The control card shall inspect the DSRC master key version number in the DSRC security data. If the control card does not know the indicated DSRC master key, it shall return an error specified in Appendix 2 and abort the process.

2.

The control card shall use the indicated DSRC master key in combination with the VU serial number in the DSRC security data to derive the VU-specific DSRC keys K_VU_DSRC_ENC and K_VU_DSRC_MAC, as specified in CSM_124.

3.

The control card shall use K_VU_DSRC_MAC to verify the MAC in the DSRC security data, as specified in CSM_227. If the MAC is incorrect, the control card shall return an error specified in Appendix 2 and abort the process.

4.

The control card shall use K_VU_DSRC_ENC to decrypt the encrypted tachograph payload, as specified in CSM_226. The control card shall remove the padding and shall return the decrypted tachograph payload data to the remote interrogator.

CSM_229 In order to prevent replay attacks, the remote interrogator shall verify the freshness of the RTM data by verifying that the current date time in the DSRC security data does not deviate too much from the current time of the remote interrogator.

Notes:

— This requires the remote interrogator to have an accurate and reliable source of time.

— Since Appendix 14 requires a VU to calculate a new set of RTM data every 60 seconds, and the clock of the VU is allowed to deviate 1 minute from the real time, a lower limit for the freshness of the RTM data is 2 minutes. The actual freshness to be required also depends on the accuracy of the clock of the remote interrogator.

CSM_230 When a workshop verifies the correct functioning of the DSRC functionality of a VU, it shall send the entire RTM data received from the VU to a workshop card in the data field of a PROCESS DSRC MESSAGE command, as described in Appendix 2. The workshop card shall perform all checks and actions specified in CSM_228.

14. SIGNING DATA DOWNLOADS AND VERIFYING SIGNATURES

14.1. General

CSM_231 The Intelligent Dedicated Equipment (IDE) shall store data received from a VU or a card during one download session within one physical data file. Data may be stored on an ESM (external storage medium). This file contains digital signatures over data blocks, as specified in Appendix 7. This file shall also contain the following certificates (refer to section 9.1):

• In case of a VU download:

  • The VU_Sign certificate

  • The MSCA_VU-EGF certificate containing the public key to be used for verification of the VU_Sign certificate

• In case of a Card download:

  • The Card_Sign certificate

  • The MSCA_Card certificate containing the public key to be used for verification of the Card_Sign certificate

CSM_232 The IDE shall also dispose of.

• In case it uses a control card to verify the signature, as shown in Figure 13: The link certificate linking the latest EUR certificate to the EUR certificate whose validity period directly precedes it, if existing.

• In case it verifies the signature itself: all valid European root certificates.

Note: the method the IDE uses to retrieve these certificates is not specified in this Appendix.

14.2. Signature generation

CSM_233 The signing algorithm to create digital signatures over downloaded data shall be ECDSA as specified in [DSS], using the hashing algorithm linked to the key size of the VU or the card, as specified in CSM_50. The signature format shall be plain, as specified in [TR-03111].

14.3. Signature verification

CSM_234 An IDE may perform verification of a signature over downloaded data itself or it may use a control card for this purpose. In case it uses a control card, signature verification shall take place as shown in Figure 13. In case it performs signature verification itself, the IDE shall verify the authenticity and validity of all certificates in the certificate chain in the data file, and it shall verify the signature over the data following the signature scheme defined in [DSS].

Notes to Figure 13:

— The equipment that signed the data to be analysed is denoted EQT.

— The EQT certificates and public keys mentioned in the figure are those for signing, i.e. VU_Sign or Card_Sign.

— The EQT.CA certificates and public keys mentioned in the figure are those for signing VU or Card certificates, as applicable.

— The EQT.CA.EUR certificate mentioned in the figure is the European root certificate that is indicated in the CAR of the EQT.CA certificate.

— The EQT.Link certificate mentioned in the figure is the EQT's link certificate, if present. As specified in section 9.1.2, this is a link certificate for a new European root key pair created by the ERCA and signed with the previous European private key.

— The EQT.Link.EUR certificate is the European root certificate that is indicated in the CAR of the EQT.Link certificate.

CSM_235 For calculating the hash M sent to the control card in the PSO:Hash command, the IDE shall use the hashing algorithm linked to the key size of the VU or the card from which the data is downloaded, as specified in CSM_50.

CSM_236 For verifying the EQT's signature, the control card shall follow the signature scheme defined in [DSS].

Note: This document does not specify any action to undertake if a signature over a downloaded data file cannot be verified or if the verification is unsuccessful.

Figure 13

Protocol for verification of the signature over a downloaded data file

(1)

Note that the generation-1, generation-2 and generation-3 pairing keys may actually be the same key, or may be three different keys having different lengths, as explained in CSM_117.