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

10. VU- CARD MUTUAL AUTHENTICATION AND SECURE MESSAGING

10.1. General

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

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

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

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

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

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

10.2. Mutual Certificate Chain Verification

10.2.1 Card Certificate Chain Verification by VU

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

Notes to Figure 4:

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

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

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

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

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

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

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

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

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

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

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

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

Figure 4

Protocol for Card Certificate Chain Verification by VU

10.2.2 VU Certificate Chain Verification by Card

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

Figure 5

Protocol for VU Certificate Chain Verification by Card

Notes to Figure 5:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Second-generation ERCA link certificates

• Second-generation MSCA certificates

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

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

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

10.3. VU Authentication

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

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

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

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

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

Figure 6

VU Authentication protocol

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

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

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

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

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

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

10.4. Chip Authentication and Session Key Agreement

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

Figure 7

Chip Authentication and session key agreement

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

1.

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

2.

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

3.

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

4.

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

5.

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

6.

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

7.

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

8.

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

9.

The VU verifies the authentication token T_PICC.

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

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

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

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

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

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

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

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

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

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

10.5. Secure Messaging

10.5.1 General

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

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

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

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

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

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

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

10.5.2 Secure Message Structure

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

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

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

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

Tag

:

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

Length

:

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

Value

:

The value is encoded in zero or more octets

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

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

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

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

• The Data field shall consist of SM data objects.

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

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

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

Summary and Examples

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

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

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

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

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

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

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

Figure 8

Transformation of an authenticated Case 4 Command APDU

Figure 9

Transformation of an authenticated Case 1 / Case 3 Response APDU

Figure 10

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

10.5.3 Secure Messaging Session Abortion

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

• it receives a plain response APDU,

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

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

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

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

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

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

• it receives a plain command APDU,

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

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

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

• it is depowered or reset,

• the VU selects an application on the card,

• the VU starts the VU Authentication process,

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

CSM_194 Regarding SM error handling by a tachograph card:

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

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

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

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

• securely destroy the stored session keys

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

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