Appendix 11

This Appendix specifies the security mechanisms ensuring

• mutual authentication between different components of the tachograph system.

• confidentiality, integrity, authenticity and/or non-repudiation of data transferred between different components of the tachograph system or downloaded to external storage media.

This Appendix consists of two parts. Part A defines the security mechanisms for the first-generation tachograph system (digital tachograph). Part B defines the security mechanisms for the second-generation tachograph system (smart tachograph).

The mechanisms specified in Part A of this Appendix shall apply if at least one of the components of the tachograph system involved in a mutual authentication and/or data transfer process is of the first generation.

The mechanisms specified in Part B of this Appendix shall apply if both components of the tachograph system involved in the mutual authentication and/or data transfer process are of the second generation.

Appendix 15 provides more information regarding the use of first generation components in combination with second-generation components.

The following references are used in this Appendix:

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

• authentication between vehicle units and cards,

• transport of Triple-DES session keys between vehicle units and tachograph cards,

• digital signature of data downloaded from vehicle units or tachograph cards to external media.

Vehicle units and tachograph cards shall use a Triple DES symmetric cryptographic system to provide a mechanism for data integrity during user data exchange between vehicle units and tachograph cards, and to provide, where applicable, confidentiality of data exchange between vehicle units and tachograph cards.

X.SK[m] = s = m^d mod n

X.PK[s] = m = s^e mod n

A more comprehensive description of the RSA function can be found in reference [PKCS1]. Public exponent, e, for RSA calculations is an integer between 3 and n-1 satisfying gcd(e, lcm(p-1, q-1))=1.

The digital signature mechanisms shall use the SHA-1 hash algorithm as defined in reference [SHA-1].

DES based algorithms shall be used in Cipher Block Chaining mode of operation.

• European level,

• Member State level,

• Equipment level.

At European level, a single European key pair (EUR.SK and EUR.PK) shall be generated. The European private key shall be used to certify the Member States public keys. Records of all certified keys shall be kept. These tasks shall be handled by a European Certification Authority, under the authority and responsibility of the European Commission.

At Member State level, a Member State key pair (MS.SK and MS.PK) shall be generated. Member States public keys shall be certified by the European Certification Authority. The Member State private key shall be used to certify public keys to be inserted in equipment (vehicle unit or tachograph card). Records of all certified public keys shall be kept with the identification of the equipment to which it is intended. These tasks shall be handled by a Member State Certification Authority. A Member State may regularly change its key pair.

At equipment level, one single key pair (EQT.SK and EQT.PK) shall be generated and inserted in each equipment. Equipment public keys shall be certified by a Member State Certification Authority. These tasks may be handled by equipment manufacturers, equipment personalisers or Member State authorities. This key pair is used for authentication, digital signature and encipherement services

The following picture summarises the data flow of this process:

For the purpose of equipment testing (including interoperability tests) the European Certification Authority shall generate a different single European test key pair and at least two Member State test key pairs, the public keys of which shall be certified with the European private test key. Manufacturers shall insert, in equipment undergoing type approval tests, test keys certified by one of these Member State test keys.

The confidentiality of the three Triple DES keys described below shall be appropriately maintained during generation, transport (if any) and storage.

In order to support tachograph components compliant with ISO 16844, the European Certification Authority and the Member State Certification Authorities shall, in addition, ensure the following:

The European Certification authority shall generate KmVU and KmWC, two independent and unique Triple DES keys, and generate Km as: Km = Km_VU XOR Km_WC. The European Certification Authority shall forward these keys, under appropriately secured procedures, to Member States Certification Authorities at their request.

• use Km to encrypt motion sensor data requested by motion sensor manufacturers (data to be encrypted with Km is defined in ISO 16844-3),

• forward Km_VU to vehicle unit manufacturers, under appropriately secured procedures, for insertion in vehicle units,

• ensure that Km_WC will be inserted in all workshop cards ( in elementary file) during card personalisation.

Vehicle units and tachograph cards shall, as a part of the mutual authentication process, generate and exchange necessary data to elaborate a common Triple DES session key. This exchange of data shall be protected for confidentiality through an RSA crypt-mechanism.

This key shall be used for all subsequent cryptographic operations using secure messaging. Its validity shall expire at the end of the session (withdrawal of the card or reset of the card) and/or after 240 use (one use of the key = one command using secure messaging sent to the card and associated response).

RSA keys shall have (whatever the level) the following lengths: modulus n1 024 bits, public exponent e 64 bits maximum, private exponent d1 024 bits.

Triple DES keys shall have the form (K_a, K_b, K_a) where K_a and K_b are independent 64 bits long keys. No parity error detecting bits shall be set.

RSA Public key certificates shall be ‘non self-descriptive’‘Card Verifiable’ certificates (Ref.: ISO/IEC 7816-8)

The headerlist associated with this certificate content is as follows:

The ‘Certification Authority Reference’ (CAR) has the purpose of identifying the certificate issuing CA, in such a way that the Data Element can be used at the same time as an Authority Key Identifier to reference the Public Key of the Certification Authority (for coding, see Key Identifier below).

The ‘Certificate Holder Authorisation’ (CHA) is used to identify the rights of the certificate holder. It consists of the Tachograph Application ID and of the type of equipment to which the certificate is intended (according to data element, ‘00’ for a Member State).

The ‘Certificate Holder Reference’ (CHR) has the purpose of identifying uniquely the certificate holder, in such a way that the Data Element can be used at the same time as a Subject Key Identifier to reference the Public Key of the certificate holder.

1. 5.1

   Equipment (VU or Card):

   Data	Equipment serial number	Date	Type	Manufacturer
   Length	4 Bytes	2 Bytes	1 Byte	1 Byte
   Value	Integer	mm yy BCD coding	Manufacturer specific	Manufacturer code

   In the case of a VU, the manufacturer, when requesting certificates, may or may not know the identification of the equipment in which the keys will be inserted.

   In the first case, the manufacturer will send the equipment identification with the public key to its Member State authority for certification. The certificate will then contain the equipment identification, and the manufacturer must ensure that keys and certificate are inserted in the intended equipment. The Key identifier has the form shown above.

   In the later case, the manufacturer must uniquely identify each certificate request and send this identification with the public key to its Member State authority for certification. The certificate will contain the request identification. The manufacturer must feed back its Member State authority with the assignment of key to equipment (i.e. certificate request identification, equipment identification) after key installation in the equipment. The key identifier has the following form:

   Data	Certificate request serial number	Date	Type	Manufacturer
   Length	4 Bytes	2 Bytes	1 Byte	1 Byte
   Value	Integer	mm yy BCD coding	‘FF’	Manufacturer code

2. 5.2

   Certification Authority:

   Data	Authority Identification	Key serial number	Additional info	Identifier
   Length	4 Bytes	1 Byte	2 Bytes	1 Byte
   Value	1 Byte nation numerical code 3 Bytes nation alphanumerical code	Integer	additional coding (CA specific) ‘FF FF’ if not used	‘01’

   The key serial number is used to distinguish the different keys of a Member State, in the case the key is changed.

Certificate verifiers shall implicitly know that the public key certified is an RSA key relevant to authentication, digital signature verification and encipherement for confidentiality services (the certificate contains no Object Identifier to specify it).

X.C = X.CA.SK[‘6A’ || C_r || Hash(Cc) || ‘BC’] || C_n || X.CAR

This certificate is 194 bytes long.

CAR, being hidden by the signature, is also appended to the signature, such that the Public Key of the Certification Authority may be selected for the verification of the certificate.

The certificate verifier shall implicitly know the algorithm used by the Certification Authority to sign the certificate.

Certificate verification and unwrapping consists in verifying the signature in accordance with ISO/IEC 9796-2, retrieving the certificate content and the public key contained: X.PK = X.CA.PK _o X.C, and verifying the validity of the certificate.

• Verify signature and retrieve content:

  — from X.C retrieve Sign, Cn' and CAR':	X.C =	Sign	||	Cn'	||	CAR'
  		128 Bytes		58 Bytes		8 Bytes

  • from CAR' select appropriate Certification Authority Public Key (if not done before through other means)

  • open Sign with CA Public Key: Sr'= X.CA.PK [Sign],

  • check Sr' starts with ‘6A’ and ends with ‘BC’

  — compute Cr' and H' from: Sr' =	‘6A’	||	Cr'	||	H'	||	‘BC’
  			106 Bytes		20 Bytes

  • Recover certificate content C' = C_r' || C_n',

  • check Hash(C') = H'

• If the checks are OK the certificate is a genuine one, its content is C'.

• Verify validity. From C':

  • if applicable, check End of validity date,

• Retrieve and store public key, Key Identifier, Certificate Holder Authorisation and Certificate End of Validity from C':

  • X.PK = n || e

  • X.KID = CHR

  • X.CHA = CHA

  • X.EOV = EOV

Mutual authentication between cards and VUs is based on the following principle:

Each party shall demonstrate to the other that it owns a valid key pair, the public key of which has been certified by a Member State certification authority, itself being certified by the European certification authority.

Demonstration is made by signing with the private key a random number sent by the other party, who must recover the random number sent when verifying this signature.

The mechanism is triggered at card insertion by the VU. It starts with the exchange of certificates and unwrapping of public keys, and ends with the setting of a session key.

VU-Cards data transfers integrity shall be protected through Secure Messaging in accordance with references [ISO/IEC 7816-4] and [ISO/IEC 7816-8].

When data need to be protected during transfer, a Cryptographic Checksum Data Object shall be appended to the Data Objects sent within the command or the response. The Cryptographic Checksum shall be verified by the receiver.

The cryptographic checksum of data sent within a command shall integrate the command header, and all data objects sent (=>CLA = ‘0C’, and all data objects shall be encapsulated with tags in which b1=1).

The response status-information bytes shall be protected by a cryptographic checksum when the response contains no data field.

The structure of commands and responses when using secure messaging is therefore the following:

• The DOs used are a partial set of the Secure Messaging DOs described in ISO/IEC 7816-4:

  Tag	Mnemonic	Meaning
  ‘81’	TPV	Plain Value not BER-TLV coded data (to be protected by CC)
  ‘97’	TLE	Value of Le in the unsecured command (to be protected by CC)
  ‘99’	TSW	Status-Info (to be protected by CC)
  ‘8E’	TCC	Cryptographic Checksum
  ‘87’	TPI CG	Padding Indicator Byte || Cryptogram (Plain Value not coded in BER-TLV)

• Given an unsecured command response pair:

  Command header				Command body
  CLA	INS	P1	P2	[Lc field]	[Data field]	[Le field]
  four bytes				L bytes, denoted as B1 to BL

  Response body	Response trailer
  [Data field]	SW1	SW2
  Lr data bytes	two bytes

• The corresponding secured command response pair is:

  • Secured command:

    Command header (CH)				Command body
    CLA	INS	P1	P2	[New Lc field]	[New Data field]									[New Le field]
    ‘OC’				Length of New Data field	TPV	LPV	PV	TLE	LLE	Le	TCC	LCC	CC	‘00’
    					‘81’	Lc	Data field	‘97’	‘01’	Le	‘8E’	‘04’	CC

    Data to be integrated in checksum = CH || PB || T_PV || L_PV || PV || T_LE || L_LE || L_e || PB

    PB = Padding Bytes (80 .. 00) in accordance with ISO-IEC 7816-4 and ISO 9797 method 2.

    DOs PV and LE are present only when there is some corresponding data in the unsecured command.

  • Secured response:

    1. 1..

       Case where response data field is not empty and needs not to be protected for confidentiality:

       Response body						Response trailer
       [New Data field]						new SW1 SW2
       TPV	LPV	PV	TCC	LCC	CC
       ‘81’	Lr	Data field	‘8E’	‘04’	CC

       Data to be integrated in checksum = T_PV || L_PV || PV || PB

    2. 2..

       Case where response data field is not empty and needs to be protected for confidentiality:

       Response body						Response trailer
       [New Data field]						new SW1 SW2
       TPI CG	LPI CG	PI CG	TCC	LCC	CC
       ‘87’		PI || CG	‘8E’	‘04’	CC

       Data to be carried by CG: non BER-TLV coded data and padding bytes.

       Data to be integrated in checksum = T_{PI CG} || L_{PI CG} || PI CG || PB

    3. 3..

       Case where response data field is empty:

       Response body						Response trailer
       [New Data field]						new SW1 SW2
       TSW	LSW	SW	TCC	LCC	CC
       ‘99’	‘02’	New SW1 SW2	‘8E’	‘04’	CC

       Data to be integrated in checksum = T_SW || L_SW || SW || PB

When the tachograph card returns status bytes without SM DOs or with an erroneous SM DO, the session must be aborted by the VU.

• Initial stage: The initial check block y0 is E(Ka, SSC).

• Sequential stage: The check blocks y1, .., yn are calculated using Ka.

• Final stage: The cryptographic checksum is calculated from the last check block yn as follows: E(Ka, D(Kb, yn)).

where E() means encryption with DES, and D() means decryption with DES.

The four most significant bytes of the cryptographic checksum are transferred

Initial SSC: Rnd3 (4 least significant bytes) || Rnd1 (4 least significant bytes).

The following figure shows the calculation of the retail MAC:

The following figure shows the application of keys in TDES:

The Intelligent Dedicated Equipment (IDE) stores data received from an equipment (VU or card) during one download session within one physical data file. This file must contain the certificates MS_i.C and EQT.C. The file contains digital signatures of data blocks as specified in Appendix 7 Data Downloading Protocols.

Digital signatures of downloaded data shall use a digital signature scheme with appendix such, that downloaded data may be read without any decipherment if desired.

• Signature = EQT.SK[‘00’ || ‘01’ || PS || ‘00’ || DER(SHA-1(Data))]

• PS = Padding string of octets with value ‘FF’ such that length is 128.

• DER(SHA-1(M)) is the encoding of the algorithm ID for the hash function and the hash value into an ASN.1 value of type DigestInfo (distinguished encoding rules):

  ‘30’||‘21’||‘30’||‘09’||‘06’||‘05’||‘2B’||‘0E’||‘03’||‘02’||‘1A’||‘05’||‘00’||‘04’||‘14’||Hash Value.

The European public key EUR.PK needs to be known independently (and trusted) by the verifier.

The following table illustrates the protocol an IDE carrying a Control card can follow to verify the integrity of data downloaded and stored on the ESM (External Storage media). The control card is used to perform the decipherement of digital signatures. This function may in this case not be implemented in the IDE.

The equipment that has downloaded and signed the data to be analysed is denoted EQT.

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

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

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

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

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

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

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

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

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

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.

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.

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

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

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

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

• European level,

• Member State level,

• Equipment level.

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

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.

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.

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.

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.

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.

• 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

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.

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.

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.

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.

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.

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.

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.

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.

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.

• 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

• 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

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

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

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.

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.

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.

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.

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.

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

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.

• 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

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.

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

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

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.

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.

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.

• For driver cards: 5 years

• For company cards: 5 years

• For control cards: 2 years

• For workshop cards: 1 year

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

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.

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

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.

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 of this Appendix.

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

• 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

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:

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.

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.

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).

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.

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

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

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.

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.

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.

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.

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

Each 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 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 .

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].

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.

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.

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.

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.

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.

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.

• 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 or certificate request ID, 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.

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.

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.

The 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.

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.

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.

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].

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’.

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.

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.

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.

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 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).

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.

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

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.

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.

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

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

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

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

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].

• 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

• 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

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

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.

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

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

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

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.

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

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.

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

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.

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.

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’.

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).

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

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.

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

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

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.

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.

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.

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

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.

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

   The VU sends the public point VU.PK _eph 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.PK _eph ) to the card, and the card stored it.

3. 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. 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. 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. 6..

   Using K _MAC , the card computes an authentication token over the VU ephemeral public point: T _PICC = CMAC(K _MAC , VU.PK _eph ). The public point shall be in the format used by the VU (see bullet 2 above). The card sends N _PICC and T _PICC to the vehicle unit.

7. 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. 8..

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

9. 9..

   The VU verifies the authentication token T_PICC.

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

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

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

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.

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.

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.

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.

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

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.

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.

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.

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

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):

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:

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 1/Case 3 response APDU, and Figure 10 shows an encrypted and authenticated Case 2/Case 4 response APDU.

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

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

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

• securely destroy the stored session keys

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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’.

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.

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.

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

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

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.

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.

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.

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.

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.

1. 1..

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

2. 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. 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. 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. 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. 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. 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. 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.

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^f2, 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].

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

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

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.

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:

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.

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.

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.

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].

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.

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

   The control card shall use the indicated DSRC master key in combination with the VU serial number or the certificate request ID 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. 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. 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.

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.

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.

• 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

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

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].

• Second-generation ERCA link certificates

• Second-generation MSCA certificates

• Second-generation VU_Sign or Card_Sign certificates issued by the same country as the control card’s own card certificate.

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]. In both cases, for every certificate read from the data file, it is necessary to verify that the Certificate Holder Authorisation (CHA) field is correct:

• The CHA field of the EQT certificate shall indicate a VU or Card (as applicable) certificate for signing (see Appendix 1, data type EquipmentType).

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

• The CHA of the EQT.Link certificate shall indicate the ERCA.

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.

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.