Please note that the date you requested in the address for this web page is not an actual date upon which a change occurred to this item of legislation. You are being shown the legislation from , which is the first date before then upon which a change was made.
ANNEX I CU.K.Requirements for construction, testing, installation, and inspection
Appendix 11
COMMON SECURITY MECHANISMS U.K.
PART BU.K. SECOND-GENERATION TACHOGRAPH SYSTEM
10.VU- CARD MUTUAL AUTHENTICATION AND SECURE MESSAGINGU.K.
10.1. General U.K.
CSM_155On a high level, secure communication between a vehicle unit and a tachograph card shall be based on the following steps:U.K.
First, each party shall demonstrate to the other that it owns a valid public key certificate, signed by a Member State Certificate Authority. In turn, the MSCA public key certificate must be signed by the European root certificate authority. This step is called certificate chain verification and is specified in detail in section 10.2
Second, the vehicle unit shall demonstrate to the card that it is in possession of the private key corresponding to the public key in the presented certificate. It does so by signing a random number sent by the card. The card verifies the signature over the random number. If this verification is successful, the VU is authenticated. This step is called VU Authentication and is specified in detail in section 10.3.
Third, both parties independently calculate two AES session keys using an asymmetric key agreement algorithm. Using one of these session keys, the card creates a message authentication code (MAC) over some data sent by the VU. The VU verifies the MAC. If this verification is successful, the card is authenticated. This step is called Card Authentication and is specified in detail in section 10.4.
Fourth, the VU and the card shall use the agreed session keys to ensure the confidentiality, integrity and authenticity of all exchanged messages. This is called Secure Messaging and is specified in detail in section 10.5.
CSM_156The mechanism described in CSM_155 shall be triggered by the vehicle unit whenever a card is inserted into one of its card slots.U.K.
10.2. Mutual Certificate Chain Verification U.K.
10.2.1 Card Certificate Chain Verification by VU U.K.
CSM_157 [F1Vehicle units shall use the protocol depicted in Figure 4 for verifying a tachograph card’s certificate chain. For every certificate it reads from the card, the VU shall verify that the Certificate Holder Authorisation (CHA) field is correct: U.K.
The CHA field of the Card certificate shall indicate a card certificate for mutual authentication (see Appendix 1, data type EquipmentType).
The CHA of the Card.CA certificate shall indicate an MSCA.
The CHA of the Card.Link certificate shall indicate the ERCA.]
Notes to Figure 4: U.K.
—The Card certificates and public keys mentioned in the figure are those for mutual authentication. Section 9.1.5 denotes these as Card_MA.U.K.
—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.U.K.
—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.U.K.
—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.U.K.
—The Card.Link.EUR certificate is the European root certificate that is indicated in the CAR of the Card.Link certificate.U.K.
Textual Amendments
CSM_158As depicted in Figure 4, verification of the card's certificate chain shall begin upon card insertion. The vehicle unit shall read the card holder reference (
) 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.U.K.
Note: There are three ways in which the VU may know the Card.CA.EUR certificate:U.K.
the Card.CA.EUR certificate is the same certificate as the VU's own EUR certificate;
the Card.CA.EUR certificate precedes the VU's own EUR certificate and the VU contained this certificate already at issuance (see CSM_81);
the Card.CA.EUR certificate succeeds the VU's own EUR certificate and the VU received a link certificate in the past from another tachograph card, verified it and stored it for future reference.
CSM_159As indicated in Figure 4, once the VU has verified the authenticity and validity of a previously unknown certificate, it may store this certificate for future reference, such that it does not need to verify that certificate's authenticity again if it is presented to the VU again. Instead of storing the entire certificate, a VU may choose to store only the contents of the Certificate Body, as specified in section 9.3.2. [F2Whereas 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.] U.K.Textual Amendments
Textual Amendments
CSM_160The VU shall verify the temporal validity of any certificate read from the card or stored in its memory, and shall reject expired certificates. For verifying the temporal validity of a certificate presented by the card a VU shall use its internal clock.U.K.
10.2.2 VU Certificate Chain Verification by Card U.K.
CSM_161 [F1Tachograph cards shall use the protocol depicted in Figure 5 for verifying a VU's certificate chain. For every certificate presented by the VU, the card shall verify that the Certificate Holder Authorisation (CHA) field is correct: U.K.
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).]
Notes to Figure 5: U.K.
—The VU certificates and public keys mentioned in the figure are those for mutual authentication. Section 9.1.4 denotes these as VU_MA.U.K.
—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.U.K.
—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.U.K.
—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.U.K.
—The VU.Link.EUR certificate is the European root certificate that is indicated in the CAR of the VU.Link certificate.U.K.
CSM_162As depicted in Figure 5, verification of the certificate chain of the vehicle unit shall begin with the vehicle unit attempting to set its own public key for use in the tachograph card. If this succeeds, it means that the card successfully verified the VU's certificate chain in the past, and has stored the VU certificate for future reference. In this case, the VU certificate is set for use and the process continues with VU Authentication. If the card does not know the VU certificate, the VU shall successively present the VU.CA certificate to be used for verifying its VU certificate, the VU.CA.EUR certificate to be used for verifying the VU.CA certificate, and possibly the link certificate, in order to find a certificate known or verifiable by the card. If such a certificate is found, the card shall use that certificate to verify the underlying VU certificates presented to it. If successful, the VU shall finally set its public key for use in the tachograph card. If not successful, the VU shall ignore the card.U.K.
Note: There are three ways in which the card may know the VU.CA.EUR certificate: U.K.
—the VU.CA.EUR certificate is the same certificate as the card's own EUR certificate;U.K.
—the VU.CA.EUR certificate precedes the card's own EUR certificate and the card contained this certificate already at issuance (see CSM_91);U.K.
—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.U.K.
CSM_163The VU shall use the MSE: Set AT command to set its public key for use in the tachograph card. As specified in Appendix 2, this command contains an indication of the cryptographic mechanism that will be used with the key that is set. This mechanism shall be ‘VU Authentication using the ECDSA algorithm, in combination with the hashing algorithm linked to the key size of the VU's VU_MA key pair, as specified in CSM_50’.U.K.
CSM_164The MSE: Set AT command also contains an indication of the ephemeral key pair which the VU will use during session key agreement (see section 10.4). Therefore, before sending the MSE: Set AT command, the VU shall generate an ephemeral ECC key pair. For generating the ephemeral key pair, the VU shall use the standardized domain parameters indicated in the card certificate. The ephemeral key pair is denoted as (VU.SKeph, VU.PKeph, Card.DP). The VU shall take the x-coordinate of the ECDH ephemeral public point as the key identification; this is called the compressed representation of the public key and denoted as Comp(VU.PKeph).U.K.
[F1CSM_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.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.] U.K.
CSM_166The card shall verify the temporal validity of any certificate presented by the VU or referenced by the VU while stored in the card's memory, and shall reject expired certificates.U.K.
CSM_167For verifying the temporal validity of a certificate presented by the VU, each tachograph card shall internally store some data representing the current time. This data shall not be directly updatable by a VU. At issuance, the current time of a card shall be set equal to the Effective Date of the card's Card_MA certificate. A card shall update its current time if the Effective Date of an authentic ‘valid source of time’ certificate presented by a VU is more recent than the card's current time. In that case, the card shall set its current time to the Effective Date of that certificate. The card shall accept only the following certificates as a valid source of time:U.K.
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.U.K.
CSM_168As indicated in Figure 5, once the card has verified the authenticity and validity of a previously unknown certificate, it may store this certificate for future reference, such that it does not need to verify that certificate's authenticity again if it is presented to the card again. Instead xof storing the entire certificate, a card may choose to store only the contents of the Certificate Body, as specified in section 9.3.2.U.K.
10.3. VU Authentication U.K.
CSM_169Vehicle units and cards shall use the VU Authentication protocol depicted in Figure 6 to authenticate the VU towards the card. VU Authentication enables the tachograph card to explicitly verify that the VU is authentic. To do so, the VU shall use its private key to sign a challenge generated by the card.U.K.
CSM_170 [F1Next to the card challenge, the VU shall include in the signature the certificate holder reference taken from the card certificate.] U.K.
Note: This ensures that the card to which the VU authenticates itself is the same card whose certificate chain the VU has verified previously.U.K.
CSM_171The VU shall also include in the signature the identifier of the ephemeral public key Comp(VU.PKeph) which the VU will use to set up Secure Messaging during the Chip Authentication process specified in section 10.4.U.K.
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.U.K.
[F1Figure 6 VU Authentication protocol U.K.
CSM_172If multiple GET CHALLENGE commands are sent by the VU during VU Authentication, the card shall return a new 8-byte random challenge each time, but shall store only the last challenge.U.K.
CSM_173The signing algorithm used by the VU for VU Authentication shall be ECDSA as specified in [DSS], using the hashing algorithm linked to the key size of the VU's VU_MA key pair, as specified in CSM_50. The signature format shall be plain, as specified in [TR-03111]. The VU shall send the resulting signature to the card.U.K.
[F1CSM_174 Upon receiving the VU’s signature in an EXTERNAL AUTHENTICATE command, the card shall U.K.
Calculate the authentication token by concatenating Card.CHR, the card challenge rcard and the identifier of the VU ephemeral public key Comp(VU.PKeph),
Verify the VU’s signature using the ECDSA algorithm, using the hashing algorithm linked to the key size of the VU’s VU_MA key pair as specified in CSM_50, in combination with VU.PK and the calculated authentication token.]
10.4. Chip Authentication and Session Key Agreement U.K.
CSM_175Vehicle units and cards shall use the Chip Authentication protocol depicted in Figure 7 to authenticate the card towards the VU. Chip Authentication enables the vehicle unit to explicitly verify that the card is authentic.U.K.
CSM_176The VU and the card shall take the following steps:U.K.
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.
[F1The 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.]
The card computes Comp(VU.PKeph) from VU.PKeph and compares this to the stored value of Comp(VU.PKeph).
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.
The card chooses a random 8-byte nonce NPICC and uses it to derive two AES session keys KMAC and KENC from K. See CSM_179.
[F1Using 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.]
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.
The VU derives session keys KMAC and KENC from K and NPICC; see CSM_179.
The VU verifies the authentication token TPICC.
CSM_177In step 3 above, the card shall compute Comp(VU.PKeph) as the x-coordinate of the public point in VU.PKeph.U.K.
CSM_178In steps 4 and 7 above, the card and the vehicle unit shall use the ECKA-EG algorithm as defined in [TR-03111].U.K.
CSM_179In 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:U.K.
The value of the counter shall be ‘00 00 00 01’ for KENC and ‘00 00 00 02’ for KMAC.
The optional nonce r shall be used and shall be equal to NPICC.
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_180In 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 TPICC shall be linked to the length of the AES session keys, as specified in CSM_50.U.K.
10.5. Secure Messaging U.K.
10.5.1 General U.K.
CSM_181All 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.U.K.
CSM_182Except 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.U.K.
CSM_183When 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.U.K.
CSM_184Secure Messaging shall use AES as defined in [AES] with the session keys KMAC and KENC that were agreed during Chip Authentication.U.K.
CSM_185An 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.U.K.
CSM_186For message encryption, KENC 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(KENC, SSC), i.e. the current value of the Send Sequence Counter encrypted with KENC.U.K.
CSM_187For message authentication, KMAC 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.U.K.
10.5.2 Secure Message Structure U.K.
CSM_188Secure 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.U.K.
| 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.U.K.
CSM_189All 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:U.K.
:
The tag is encoded in one or two octets and indicates the content.
:
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.
:
The value is encoded in zero or more octets
CSM_190APDUs protected by Secure Messaging shall be created as follows:U.K.
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.
[F1CSM_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, data objects in the APDU shall be padded according to [ISO 7816-4]. U.K.
Note: Padding for Secure Messaging is always performed by the secure messaging layer, not by the CMAC or CBC algorithms. U.K.
Summary and Examples U.K.
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):
:
CLA INS P1 P2 || Lc' || DO ‘ 8E ’ || Le
:
CLA INS P1 P2 || Lc' || DO ‘ 97 ’ || DO ‘ 8E ’ || Le
:
CLA INS P1 P2 || Lc' || DO ‘ 81 ’ || DO ‘ 8E ’ || Le
:
CLA INS P1 P2 || Lc' || DO ‘ B3 ’ || DO ‘ 8E ’ || Le
:
CLA INS P1 P2 || Lc' || DO ‘ 81 ’ || DO ‘ 97 ’ || DO ‘ 8E ’ || Le
:
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:
:
DO ‘ 99 ’ || DO ‘ 8E ’ || SW1SW2
:
DO ‘ 81 ’ || DO ‘ 99 ’ || DO ‘ 8E ’ || SW1SW2
:
DO ‘ 87 ’ || DO ‘ 99 ’ || DO ‘ 8E ’ || SW1SW2
:
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. U.K.
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.
Figure 10 Transformation of an encrypted and authenticated Case 2/Case 4 Response APDU U.K.
10.5.3 Secure Messaging Session Abortion U.K.
CSM_192A vehicle unit shall abort an ongoing Secure Messaging session if and only if one of the following conditions occur:U.K.
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.
[F1CSM_193 A tachograph card shall abort an ongoing Secure Messaging session if and only if one of the following conditions occur: U.K.
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.]
CSM_194Regarding SM error handling by a tachograph card:U.K.
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_195If a Secure Messaging session between a VU and a tachograph card is aborted, the VU and the tachograph card shallU.K.
securely destroy the stored session keys
immediately establish a new Secure Messaging session, as described in sections 10.2 — 10.5.