Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) No 165/2014 of the European Parliament and of the Council laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)

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

• CSM_43Vehicle 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_44Vehicle 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_45Vehicle units, tachograph cards and external GNSS facilities shall support elliptic curve cryptography with a key size of 256, 384 and 512/521 bits.

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

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

• CSM_48Vehicle 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]	Image omitted; see official source
BrainpoolP256r1	256	[RFC 5639]	Image omitted; see official source
NIST P-384	384	[DSS], [RFC 5480]	Image omitted; see official source
BrainpoolP384r1	384	[RFC 5639]	Image omitted; see official source
BrainpoolP512r1	512	[RFC 5639]	Image omitted; see official source
NIST P-521	521	[DSS], [RFC 5480]	Image omitted; see official source

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.

Image omitted; see official source

8.2.3   Hashing algorithms

• CSM_49Vehicle units, tachograph cards and external GNSS facilities shall support the SHA-256, SHA-384 and SHA-512 algorithms specified in [SHS].

8.2.4   Cipher Suites

• CSM_50In 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.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_51Within 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_52Within 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_53At 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_54The 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_55The 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_56As 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_57Before 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_58Whenever 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 plus 3 months. 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_59The 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_60At 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_61At 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_62The 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_63An 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_64An 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_65An 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_66An 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_67The 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_68As 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_69An 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_70At 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_71If 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_72Two 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 its MSCA, in order to obtain a corresponding VU certificate signed by the MSCA. The private key shall be used only by the vehicle unit.

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

• CSM_74A 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_75A 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_76A 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_77A 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_78As 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_79A vehicle unit shall not use the private key of a VU key pair for any purpose after the corresponding certificate has expired.

• CSM_80The 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_81When 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_82In 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_83One 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 its MSCA, in order to obtain a corresponding card certificate signed by the MSCA. The private key shall be used only by the tachograph card.

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

• CSM_85A 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_86A 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_87A 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_88The validity period of a Card_MA certificate shall be as follows:

• — For driver cards: 5 years

• — For company cards: 5 years

• — For control cards: 2 years

• — For workshop cards: 1 year

• CSM_89The 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_90The key pairs and corresponding certificates of a given tachograph card shall not be replaced or renewed once the card has been issued.

• CSM_91When 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.

• — Additionally, for control cards, company cards and workshop cards only, and only if such cards are issued during the first three months of the validity period of a new EUR certificate: the EUR certificate that is two generations older, if existing.

Note to last bullet: For example, in the first three months of the ERCA(3) certificate (see Figure 1), the mentioned cards shall contain the ERCA(1) certificate. This is needed to ensure that these cards can be used to perform data downloads from ERCA(1) VUs whose normal 15-year life period plus the 3-months data downloading period expires during these months; see the last bullet of requirement 13) in Annex IC.

- CSM_92In 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_93One 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 party generating th e key shall send the public key to its MSCA 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_94An 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_95An 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 of this Appendix.

• CSM_96The validity period of an EGF_MA certificate shall be 15 years.

• CSM_97An 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_98The 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_99When 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

Image omitted; see official source

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 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_100A 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

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) [^E0018]
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) [^E0018]
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

Storage of KM and KID is optional, as these keys can be derived from KM-VU, KM-WC and CV.

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

• CSM_102The ERCA shall assign to each motion sensor master key KM a unique version number, which shall also be applicable for the constituting keys KM-VU and KM-WC and for the related identification key KID. The ERCA shall inform the MSCAs about the version number when sending KM-VU and KM-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_103A Member State Certificate Authority shall forward KM-VU, together with its version number, to vehicle unit manufacturers upon their request. The VU manufacturers shall insert KM-VU and its version number in all manufactured VUs.

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

Notes:

• —See the description of data type Image omitted; see official source in Appendix 2.

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

• CSM_105In addition to the AES key specified in CSM_104, a MSCA shall ensure that the TDES key KmWC, 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 KmWC.

• CSM_106An 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 5D 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 Each Motion sensor manufacturer shall generate a random and unique pairing key KP for every motion sensor, and shall send each pairing key to its Member State Certificate Authority. The MSCA shall encrypt each pairing key separately with the motion sensor master key KM 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 KM.

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_108Each motion sensor manufacturer shall generate a unique serial number for every motion sensor, and shall send all serial numbers to its Member State Certificate Authority. The MSCA shall encrypt each serial number separately with the identification key KID 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 KID.

• CSM_109For 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_110The 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 KM and KID 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_111In 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_112The length of the session key KS generated by a VU during the pairing to a motion sensor shall be linked to the length of its KM-VU, as described in CSM_50.

9.2.1.2   Motion Sensor Master Key Replacement in Second-Generation Equipment

• CSM_113Each 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 Image omitted; see official source

• CSM_114At 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 KM by generating a new KM-VU and KM-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 KM, KM-VU and KM-WC to the MSCAs upon their request, together with their version number.

• CSM_115An MSCA shall ensure that all valid generations of KM-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 KM-WC, as shown in Figure 2.

• CSM_116In relation to the process described in CSM_107 and CSM_108 above: An MSCA shall encrypt each pairing key KP it receives from a motion sensor manufacturer separately with each valid generation of the motion sensor master key KM. An MSCA shall also encrypt each serial number it receives from a motion sensor manufacturer separately with each valid generation of the identification key KID. 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 KM and KID 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 KM, as shown in Figure 2.

• CSM_117In relation to the process described in CSM_107 above: Since the length of the pairing key KP shall be linked to the length of KM (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 KM 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_118Vehicle unit manufacturers shall insert only one generation of KM-VU in each vehicle unit, together with its version number. This KM-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 KM-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 KM-WC at the moment the first VU containing the new KM-VU is issued. Therefore, such a VU will always be able to calculate the new KM. Moreover, by that time most new motion sensors will contain encrypted data based on the new KM as well.

9.2.2   Keys for Securing DSRC Communication

9.2.2.1   General

• CSM_119The 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, KMDSRC.

• CSM_120The DSRC master key KMDSRC 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_121The 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_122The 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_123For 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 Image omitted; see official source .

Note:

• — This VU serial number shall be identical to the vuSerialNumber element of VuIdentification, see Appendix 1 and to the Certificate Holder Reference in the VU’s certificates.

• — The VU serial number may not be known at the moment a vehicle unit manufacturer requests the VU-specific DSRC keys. In this case, the VU manufacturer shall send instead the unique certificate request ID it used when requesting the VU’s certificates; see CSM_153. This certificate request ID shall therefore be equal to the Certificate Holder Reference in the VU’s certificates.

- CSM_124Upon receiving a request for VU-specific DSRC keys, the MSCA shall derive two AES keys for the vehicle unit, called K_VUDSRC_ENC and K_VUDSRC_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 KMDSRC.

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 or certificate request ID, as specified in CSM_123

• — K_VUDSRC_ENC = first L octets of OKM and K_VUDSRC_MAC = last L octets of OKM where L is the required length of K_VUDSRC_ENC and K_VUDSRC_MAC in octets.

• CSM_125The MSCA shall distribute K_VUDSRC_ENC and K_VUDSRC_MAC to the VU manufacturer in a secure manner for insertion in the intended vehicle unit.

• CSM_126When issued, a vehicle unit shall have stored K_VUDSRC_ENC and K_VUDSRC_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_127When issued, control cards and workshop cards shall have stored KMDSRC 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 KMDSRC may have to be inserted in a single workshop card or control card.

• CSM_128The MSCA shall keep records of all VU-specific DSRC keys it generated, their version number and the VU serial number or certificate request ID used in deriving them.

9.2.2.2   DSRC Master Key Replacement

• CSM_129Each 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 Image omitted; see official source

• CSM_130At 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_131An MSCA shall ensure that all valid generations of KMDSRC 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 KMDSRC, as shown in Figure 3.

• CSM_132An MSCA shall ensure that all generations of KMDSRC 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 KMDSRC, as shown in Figure 3.

• CSM_133Vehicle 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 KMDSRC 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_VUDSRC_ENC and K_VUDSRC_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_134All 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 the data objects within certificates. Table 4 shows the full certificate encoding, including all tag and length bytes.

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_136All 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’	Image omitted; see official source
Certificate Authority Reference	CAR	‘42’	‘08’	Image omitted; see official source
Certificate Holder Authorisation	CHA	‘5F 4C’	‘07’	Image omitted; see official source Image omitted; see official source
Public Key	PK	‘7F 49’	var
Domain Parameters	DP	‘06’	var	Image omitted; see official source
Public Point	PP	‘86’	var	Image omitted; see official source
Certificate Holder Reference	CHR	‘5F 20’	‘08’	Image omitted; see official source
Certificate Effective Date	CEfD	‘5F 25’	‘04’	Image omitted; see official source
Certificate Expiration Date	CExD	‘5F 24’	‘04’	Image omitted; see official source
ECC Certificate Signature	S	‘5F 37’	var	Image omitted; see official source

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_137Certificates 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_138The 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_139An 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_140For 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_141The 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 equipment type, which indicates the type of equipment for which the certificate is intended. In the case of a VU certificate, a driver card certificate or a workshop card certificate, the equipment type is also used to differentiate between a certificate for Mutual Authentication and a certificate for creating digital signatures (see section 9.1 and Appendix 1, data type EquipmentType).

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_142The data element Domain Parameters shall contain one of the object identifiers specified in Table 1 to reference a set of standardized domain parameters.

• CSM_143The 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_144The 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_145For card certificates and external GNSS facility certificates, the Certificate Holder Reference shall have the Image omitted; see official source data type specified in Appendix 1.

• CSM_146For 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 Image omitted; see official source data type specified in Appendix 1. In the latter case, the Certificate Holder Reference shall have the Image omitted; see official source data type specified in Appendix 1.

Note: For a card certificate, the value of the CHR shall be equal to the value of the cardExtendedSerialNumber in EF_ICC; see Appendix 2. For an EGF certificate, the value of the CHR shall be equal to the value of the sensorGNSSSerialNumber in EF_ICC; see Appendix 14. For a VU certificate, the value of the CHR shall be equal to the vuSerialNumber element of VuIdentification, see Appendix 1, unless the manufacturer does not know the manufacturer-specific serial number at the time the certificate is requested.

• CSM_147For ERCA and MSCA certificates, the Certificate Holder Reference shall have the Image omitted; see official source data type specified in Appendix 1.

9.3.2.6   Certificate Effective Date

• CSM_148The Certificate Effective Date shall indicate the starting date and time of the validity period of the certificate.

9.3.2.7   Certificate Expiration Date

• CSM_149The Certificate Expiration Date shall indicate the end date and time of the validity period of the certificate.

9.3.2.8   Certificate Signature

• CSM_150The 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, an MSCA shall send the following data to the ERCA:

• — 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_152In 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 Image omitted; see official source defined in Appendix 1)

• — The alphanumerical nation code of the Certification Authority (data type Image omitted; see official source 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_153An 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:

• — 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_154In 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.1.   General

• CSM_155On 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_156The 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. For every certificate it reads from the card, the VU shall verify that the Certificate Holder Authorisation (CHA) field is correct:

• — The CHA field of the Card certificate shall indicate a card certificate for mutual authentication (see Appendix 1, data type EquipmentType).

• — The CHA of the Card.CA certificate shall indicate an MSCA.

• — The CHA of the Card.Link certificate shall indicate the ERCA.

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_158As 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 (Image omitted; see official source) 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_159As 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.  Whereas storing of all other types of certificate is optional, it is mandatory for a VU to store a new link certificate presented by a card.

- CSM_160The 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

Image omitted; see official source

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. For every certificate presented by the VU, the card shall verify that the Certificate Holder Authorisation (CHA) field is correct:

• — The CHA of the VU.Link certificate shall indicate the ERCA.

• — The CHA of the VU.CA certificate shall indicate an MSCA.

• — The CHA field of the VU certificate shall indicate a VU certificate for mutual authentication (see Appendix 1, data type EquipmentType).

Figure 5

Protocol for VU Certificate Chain Verification by Card

Image omitted; see official source

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_162As 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_163The 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_164The 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.SKeph, VU.PKeph, 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.PKeph).

• CSM_165If 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.PKeph). 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.PKeph) received. The card shall reset Comp(VU.PKeph) after a successful GENERAL AUTHENTICATE command.

• CSM_166The 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_167For 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_168As 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 xof 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_169Vehicle 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 certificate 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_171The VU shall also include in the signature the identifier of the ephemeral public key Comp(VU.PKeph) 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

Image omitted; see official source

• CSM_172If 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_173The 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_174Upon receiving the VU’s signature in an EXTERNAL AUTHENTICATE command, the card shall

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

• — Verify the VU’s signature using the ECDSA algorithm, using the hashing algorithm linked to the key size of the VU’s VU_MA key pair as specified in CSM_50, in combination with VU.PK and the calculated authentication token.

10.4.   Chip Authentication and Session Key Agreement

• CSM_175Vehicle 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

Image omitted; see official source

• CSM_176The 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.

• 1. The VU sends the public point VU.PKeph of its ephemeral key pair to the card. The public point shall be converted to an octet string as specified in [TR-03111]. The uncompressed encoding format shall be used. 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.PKeph) to the card, and the card stored it.

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

• 1. 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.

• 1. The card chooses a random 8-byte nonce NPICC and uses it to derive two AES session keys KMAC and KENC from K. See CSM_179.

• 1. Using KMAC, the card computes an authentication token over the VU ephemeral public point: TPICC = CMAC(KMAC, VU.PKeph). The public point shall be in the format used by the VU (see bullet 2 above). The card sends NPICC and TPICC to the vehicle unit.

• 1. 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.

• 1. The VU derives session keys KMAC and KENC from K and NPICC; see CSM_179.

• 1. The VU verifies the authentication token TPICC.

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