- Latest available (Revised)
- Original (As adopted by EU)
Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) No 165/2014 of the European Parliament and of the Council laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)
After exit day there will be three versions of this legislation to consult for different purposes. The legislation.gov.uk version is the version that applies in the UK. The EU Version currently on EUR-lex is the version that currently applies in the EU i.e you may need this if you operate a business in the EU.
The web archive version is the official version of this legislation item as it stood on exit day before being published to legislation.gov.uk and any subsequent UK changes and effects applied. The web archive also captured associated case law and other language formats from EUR-Lex.
There are outstanding changes not yet made to Commission Implementing Regulation (EU) 2016/799. Any changes that have already been made to the legislation appear in the content and are referenced with annotations.
Revised legislation carried on this site may not be fully up to date. Changes and effects are recorded by our editorial team in lists which can be found in the ‘Changes to Legislation’ area. Where those effects have yet to be applied to the text of the legislation by the editorial team they are also listed alongside the legislation in the affected provisions. Use the ‘more’ link to open the changes and effects relevant to the provision you are viewing.
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 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.]
Textual Amendments
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.
Textual Amendments
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).]
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.
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.
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.
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.]
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.
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.
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.
:
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
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.
Note: Padding for Secure Messaging is always performed by the secure messaging layer, not by the CMAC or CBC algorithms. 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.
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.
The Whole Regulation you have selected contains over 200 provisions and might take some time to download. You may also experience some issues with your browser, such as an alert box that a script is taking a long time to run.
Would you like to continue?
The Schedules you have selected contains over 200 provisions and might take some time to download. You may also experience some issues with your browser, such as an alert box that a script is taking a long time to run.
Would you like to continue?
Latest Available (revised):The latest available updated version of the legislation incorporating changes made by subsequent legislation and applied by our editorial team. Changes we have not yet applied to the text, can be found in the ‘Changes to Legislation’ area.
Original (As adopted by EU): The original version of the legislation as it stood when it was first adopted in the EU. No changes have been applied to the text.
Geographical Extent: Indicates the geographical area that this provision applies to. For further information see ‘Frequently Asked Questions’.
Show Timeline of Changes: See how this legislation has or could change over time. Turning this feature on will show extra navigation options to go to these specific points in time. Return to the latest available version by using the controls above in the What Version box.
Access essential accompanying documents and information for this legislation item from this tab. Dependent on the legislation item being viewed this may include:
This timeline shows the different versions taken from EUR-Lex before exit day and during the implementation period as well as any subsequent versions created after the implementation period as a result of changes made by UK legislation.
The dates for the EU versions are taken from the document dates on EUR-Lex and may not always coincide with when the changes came into force for the document.
For any versions created after the implementation period as a result of changes made by UK legislation the date will coincide with the earliest date on which the change (e.g an insertion, a repeal or a substitution) that was applied came into force. For further information see our guide to revised legislation on Understanding Legislation.
Use this menu to access essential accompanying documents and information for this legislation item. Dependent on the legislation item being viewed this may include:
Click 'View More' or select 'More Resources' tab for additional information including: