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)

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

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

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

10.5.   Secure Messaging

10.5.1   General

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

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

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

• CSM_184Secure Messaging shall use AES as defined in [AES] with the session keys KMAC and KENC that were agreed during Chip Authentication.

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

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

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

10.5.2   Secure Message Structure

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

Table 5

Secure Messaging Data Objects

Data Object Name	Tag	Presence (M)andatory, (C)onditional or (F)orbidden in	Presence (M)andatory, (C)onditional or (F)orbidden in
Data Object Name	Tag	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_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:

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

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) without encryption	:	DO ‘81’ || DO ‘99’ || DO ‘8E’ || SW1SW2

| | | |

| --- | --- | --- | | Case 2 or 4 (even INS byte) with 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 1/Case 3 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

Image omitted; see official source

Figure 9

Transformation of an authenticated Case 1 / Case 3 Response APDU

Image omitted; see official source

Figure 10

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

Image omitted; see official source

10.5.3   Secure Messaging Session Abortion

• CSM_192A 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_193A 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 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:

• — 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 shall

• — securely destroy the stored session keys

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

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

11.1.   General

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

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

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

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

11.2.   VU and External GNSS Facility Coupling

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

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

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

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

11.3.   Mutual Certificate Chain Verification

11.3.1   General

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

11.3.2   During VU — EGF Coupling

• CSM_206During the coupling to an EGF, a vehicle unit shall use the protocol depicted in Figure 4 (section 10.2.1) for verifying the external GNSS facility's certificate chain.

Notes to Figure 4 within this context:

- —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 Image omitted; see official source, the VU shall read the Image omitted; see official source from EF ICC.

• —Instead of selecting the Tachograph AID, the VU shall select the EGF AID.

• —‘Ignore Card’ shall be interpreted as ‘Ignore EGF’.

• CSM_207Once it has verified the EGF_MA certificate, the vehicle unit shall store this certificate for use during normal operation; see section 11.3.3.

• CSM_208 During the coupling to a VU, an external GNSS facility shall use the protocol depicted in Figure 5 (section 10.2.2) for verifying the VU's certificate chain.

Notes to Figure 5 within this context:

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

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

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

11.3.3   During Normal Operation

• CSM_211 During normal operation, a vehicle unit and an EGF shall use the protocol depicted in Figure 11 for verifying the temporal validity of the stored EGF_MA certificate and for setting the VU_MA public key for subsequent VU Authentication. No further mutual verification of the certificate chains shall take place during normal operation.

Note that Figure 11 in essence consists of the first steps shown in Figure 4 and Figure 5. Again, note that since an EGF is not a smart card, the VU will probably not send a Reset to initiate the communication and will not receive an ATR. In any case this is out of the scope of this Appendix.

Figure 11

Mutual verification of certificate temporal validity during normal VU — EGF operation

Image omitted; see official source

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

11.4.   VU Authentication, Chip Authentication and Session Key Agreement

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

11.5.   Secure Messaging

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

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

12.1.   General

• CSM_216A vehicle unit and a motion sensor shall communicate using the interface protocol specified in [ISO 16844-3] during pairing and in normal operation, with the changes described in this chapter and in section 9.2.1.

Note: readers of this chapter are supposed to be familiar with the contents of [ISO 16844-3].

12.2.   VU — Motion Sensor Pairing Using Different Key Generations

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 KM-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 KM) may be present. A vehicle unit contains only one motion sensor-related key KM-VU.

• CSM_217A second-generation VU and a second-generation motion sensor shall be paired as follows (compare Table 6 in [ISO 16844-3]):

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

• 1. The VU reads all available KM-WC keys from the workshop card, inspects their key version numbers and chooses the one matching the version number of the VU's KM-VU key. If the matching KM-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.

• 1. The VU calculates the motion sensor master key KM from KM-VU and KM-WC, and the identification key KID from KM, as specified in section 9.2.1.

- 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 KID. The VU sends the encrypted serial number back to the motion sensor.

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

- 6. The VU decrypts the pairing key using KM, generates a session key KS, encrypts it with the pairing key and sends the result to the motion sensor. The motion sensor decrypts KS.

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

• 1. The motion sensor encrypts the received pairing information with the received KS 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 KS as the VU and hence in step 5 sent its pairing key encrypted with the correct generation of KM. Hence, the motion sensor is authenticated.

Note that steps 2 and 5 are different from the standard process in [ISO 16844-3]; the other steps are standard.

- 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: — Ns[1]: its serial number encrypted with generation 1 of KID, — Ns[2]: its serial number encrypted with generation 2 of KID, — Ns[3]: its serial number encrypted with generation 3 of KID, — KP[1]: its generation-1 pairing key ([^E0019]), encrypted with generation 1 of KM, — KP[2]: its generation-2 pairing key, encrypted with generation 2 of KM, — KP[3]: its generation-3 pairing key, encrypted with generation 3 of KM,

• — 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 KM-WC key.

• — Suppose the VU is a generation-2 VU, containing the generation 2 of KM-VU.

• In this case, the following will happen in steps 2 — 5:

• — Step 2: The VU reads generation 2 and generation 3 of KM-WC from the workshop card and inspects their version numbers.

• — Step 3: The VU combines the generation-2 KM-WC with its KM-VU to compute KM and KID.

• — Step 4: The VU encrypts the serial number it receives from the motion sensor with KID.

• — Step 5: The motion sensor compares the received data with Ns[1] and doesn't find a match. Next, it compares the data with Ns[2] and finds a match. It concludes that the VU is a generation-2 VU, and therefore sends back KP[2].

12.3.   VU — Motion Sensor Pairing and Communication using AES

• CSM_218As specified in Table 3 in section 9.2.1, all keys involved in the pairing of a (second-generation) vehicle unit and a motion sensor and in subsequent communication shall be AES keys, rather than double-length TDES keys as specified in [ISO 16844-3]. These AES keys may have a length of 128, 192 or 256 bits. Since the AES block size is 16 bytes, the length of an encrypted message must be a multiple of 16 bytes, compared to 8 bytes for TDES. Moreover, some of these messages will be used to transport AES keys, the length of which may be 128, 192 or 256 bits. Therefore, the number of data bytes per instruction in Table 5 of [ISO 16844-3] shall be changed as shown in Table 6:

Table 6

Number of plaintext and encrypted data bytes per instruction defined in [ISO 16844-3]

| Instruction | Request / reply | Description of data | # of plaintext data bytes according to [ISO 16844-3] | # of plaintext data bytes using AES keys | # of encrypted data bytes when using AES keys of bitlength | # of encrypted data bytes when using AES keys of bitlength | # of encrypted data bytes when using AES keys of bitlength |

| --- | --- | --- | --- | --- | --- | --- | --- | | Instruction | Request / reply | Description of data | # of plaintext data bytes according to [ISO 16844-3] | # of plaintext data bytes using AES keys | 128 | 192 | 256 | | 10 | request | Authentication data + file number | 8 | 8 | 16 | 16 | 16 | | 11 | reply | Authentication data + file contents | 16 or 32, depend on file | 16 or32, depend on file | 32 / 48 | 32 / 48 | 32 / 48 | | 41 | request | MoS serial number | 8 | 8 | 16 | 16 | 16 | | 41 | reply | Pairing key | 16 | 16 / 24 / 32 | 16 | 32 | 32 | | 42 | request | Session key | 16 | 16 / 24 / 32 | 16 | 32 | 32 | | 43 | request | Pairing information | 24 | 24 | 32 | 32 | 32 | | 50 | reply | Pairing information | 24 | 24 | 32 | 32 | 32 | | 70 | request | Authentication data | 8 | 8 | 16 | 16 | 16 | | 80 | reply | MoS counter value + auth. data | 8 | 8 | 16 | 16 | 16 |

• CSM_219The pairing information that is sent in instructions 43 (VU request) and 50 (MoS reply) shall be assembled as specified in section 7.6.10 of [ISO 16844-3], except that the AES algorithm shall be used instead of the TDES algorithm in the pairing data encryption scheme, thus resulting in two AES encryptions, and adopting the padding specified in CSM_220 to fit with the AES block size. The key K'p used for this encryption shall be generated as follows:

• — In case the pairing key KP is 16 bytes long: K'p = KP XOR (Ns||Ns)

• — In case the pairing key KP is 24 bytes long: K'p = KP XOR (Ns||Ns||Ns)

• — In case the pairing key KP is 32 bytes long: K'p = KP XOR (Ns||Ns||Ns||Ns)

• where Ns is the 8-byte serial number of the motion sensor.

- CSM_220In case the plaintext data length (using AES keys) is not a multiple of 16 bytes, padding method 2 defined in [ISO 9797-1] shall be used.

Note: in [ISO 16844-3], the number of plaintext data bytes is always a multiple of 8, such that padding is not necessary when using TDES. The definition of data and messages in [ISO 16844-3] is not changed by this part of this Appendix, thus necessitating the application of padding.

• CSM_221For instruction 11 and in case more than one block of data must be encrypted, the Cipher Block Chaining mode of operation shall be used as defined in [ISO 10116], with an interleave parameter m = 1. The IV to be used shall be

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

Note: As shown in section 7.6.5 and 7.6.6 of [ISO 16844-3], when the MoS encrypts data files for inclusion in instruction 11, the authentication block is both

• — Used as the initialization vector for the CBC-mode encryption of the data files

- — Encrypted and included as the first block in the data that is sent to the VU.

12.4.   VU — Motion Sensor Pairing For Different Equipment Generations

• CSM_222As explained in section 9.2.1, a second-generation motion sensor may contain the TDES-based encryption of the pairing data (as defined in Part A of this Appendix), which allows the motion sensor to be paired to a first-generation VU. If this is the case, a first-generation VU and a second-generation motion sensor shall be paired as described in Part A of this Appendix and in [ISO 16844-3]. For the pairing process either a first-generation or a second-generation workshop card may be used.

Notes:

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

13.1.   General

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:

Encrypted tachograph payloadthe encryption of the plaintext tachograph payload

DSRC security datadescribed below

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.

• CSM_223The plaintext Image omitted; see official source 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.

- CSM_224The DSRC security data shall consist of the concatenation of the following data elements in the following order; see also Figure 12:

• Current date time the current date and time of the VU (data type Image omitted; see official source)

- Counter a 3-byte counter, see CSM_225

• VU serial number the VU’s serial number or certificate request ID (data type VuSerialNumber or CertificateRequestID) – see CSM_123

• DSRC master key version number the 1-byte version number of the DSRC master key from which the VU-specific DSRC keys were derived, see section 9.2.2.

• MAC the MAC calculated over all previous bytes in the RTM data.

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

13.2.   Tachograph Payload Encryption and MAC Generation

• CSM_226Given a plaintext data element with data type Image omitted; see official source as described in Appendix 14, a VU shall encrypt this data as shown in Figure 12: the VU's DSRC key for encryption K_VUDSRC_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].

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

Figure 12

Tachograph payload encryption and MAC generation

Image omitted; see official source

13.3.   Verification and Decryption of Tachograph Payload

• CSM_228When a remote interrogator receives RTM data from a VU, it shall send the entire RTM data to a control card in the data field of a PROCESS DSRC MESSAGE command, as described in Appendix 2. Then:

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

• 1. 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_VUDSRC_ENC and K_VUDSRC_MAC, as specified in CSM_124.

• 1. The control card shall use K_VUDSRC_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.

• 1. The control card shall use K_VUDSRC_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.

• CSM_229In order to prevent replay attacks, the remote interrogator shall verify the freshness of the RTM data by verifying that the current date time in the DSRC security data does not deviate too much from the current time of the remote interrogator.

Notes:

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

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

14. SIGNING DATA DOWNLOADS AND VERIFYING SIGNATURES

14.1.   General

• CSM_231The Intelligent Dedicated Equipment (IDE) shall store data received from a VU or a card during one download session within one physical data file. Data may be stored on an ESM (external storage medium). This file contains digital signatures over data blocks, as specified in Appendix 7. This file shall also contain the following certificates (refer to section 9.1):

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

- CSM_232The IDE shall also dispose of.

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

Note: the method the IDE uses to retrieve these certificates is not specified in this Appendix.

14.2.   Signature generation

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

14.3.   Signature verification

- CSM_234

An IDE may perform verification of a signature over downloaded data itself or it may use a control card for this purpose. In case it uses a control card, signature verification shall take place as shown in Figure 13. For verifying the temporal validity of a certificate presented by the IDE, the control card shall use its internal current time, as specified in CSM_167. The control card shall update its current time if the Effective Date of an authentic ‘valid source of time’ certificate is more recent than the card’s current time. 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_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.

Notes to Figure 13:

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

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

• CSM_236For verifying the EQT's signature, the control card shall follow the signature scheme defined in [DSS].

Note: This document does not specify any action to undertake if a signature over a downloaded data file cannot be verified or if the verification is unsuccessful.

Figure 13

Protocol for verification of the signature over a downloaded data file

Image omitted; see official source

Appendix 12

POSITIONING BASED ON GLOBAL NAVIGATION SATELLITE SYSTEM (GNSS)

TABLE OF CONTENT	TABLE OF CONTENT
1.	INTRODUCTION
1.1.	Scope
1.1.1	References
1.2.	Acronyms and notations
2.	BASIC CHARACTERISTICS OF THE GNSS RECEIVER
3.	SENTENCES PROVIDED BY THE GNSS RECEIVER
4.	VEHICLE UNIT WITH AN EXTERNAL GNSS FACILITY
4.1.	Configuration
4.1.1	Main components and interfaces
4.1.2	External GNSS facility state at the end of production
4.2.	Communication between the external GNSS facility and the vehicle unit
4.2.1	Communication Protocol
4.2.2	Secure transfer of GNSS data
4.2.3	Structure of the Read Record command
4.2.4	Structure of the WriteRecord command
4.2.5	Other commands
4.3.	Coupling, mutual authentication and session key agreement of the external GNSS facility with vehicle unit
4.4.	Error Handling
4.4.1	Communication error with the external GNSS facility
4.4.2	Breach of the physical integrity of the external GNSS facility
4.4.3	Absence of position information from GNSS receiver
4.4.4	External GNSS facility certificate expired
5.	VEHICLE UNIT WITHOUT AN EXTERNAL GNSS FACILITY
5.1.	Configuration
5.2.	Transfer of information from the GNSS receiver to the VU
—————
5.3.	Transfer of information from the VU to the GNSS receiver
5.4.	Error handling
5.4.1.	Absence of position information from GNSS receiver
6.	POSITION DATA PROCESSING AND RECORDING BY THE VU
7.	GNSS TIME CONFLICT
8.	VEHICLE MOTION CONFLICT

This Appendix provides the technical requirements for the GNSS receiver and GNSS data used by the Vehicle Unit, including the protocols that must be implemented to assure the secure and correct data transfer of the positioning information.

1.1.   Scope

• GNS_1 The Vehicle Unit shall collect location data from at least one GNSS satellite network.

The Vehicle Unit may be with or without an external GNSS facility as described in Figure 1:

1.1.1   References

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

• NMEA NMEA (National Marine Electronics Association) 0183 Interface Standard, V4.11

Figure 1

Different configurations for GNSS receiver

Image omitted; see official source

1.2.   Acronyms and notations

The following acronyms are used in this appendix:

• DOP Dilution of Precision

- EGF Elementary file GNSS Facility

• EGNOS European Geostationary Navigation Overlay Service

• GNSS Global Navigation Satellite System

• GSA GPS DOP and active satellites

• HDOP Horizontal Dilution of Precision

• ICD Interface Control Document

• NMEA National Marine Electronics Association

• OSNMA Galileo Open Service Navigation Messages Authentication

• PDOP Position Dilution of Precision

• RMC Recommended Minimum Specific

• RTC Real Time Clock

• SIS Signal in Space

• VDOP Vertical Dilution of Precision

• VU Vehicle Unit

Regardless of the configuration of the Smart Tachograph with or without an external GNSS facility, the provision of accurate and reliable positioning information is an essential element of the effective operation of the Smart Tachograph. Therefore, it is appropriate to require its compatibility with the services provided by the Galileo and European Geostationary Navigation Overlay Service (EGNOS) programmes as set out in Regulation (EU) No 1285/2013 of the European Parliament and of the Council ([^E0020]). The system established under the Galileo programme is an independent global satellite navigation system and the one established under the EGNOS programme is a regional satellite navigation system improving the quality of the Global Positioning System signal.

• GNS_2Manufacturers shall ensure that the GNSS receivers in the Smart Tachographs are compatible with the positioning services provided by the Galileo and the EGNOS systems. Manufacturers may also choose, in addition, compatibility with other satellite navigation systems.

• GNS_3The GNSS receiver shall have the capability to support Navigation Messages Authentication on the Open Service of Galileo (OSNMA).

• GNS_3aThe GNSS receiver shall perform a number of consistency checks in order to verify that the measurements computed by the GNSS receiver on the basis of the OSNMA data have resulted in the correct information about the position, velocity and data of the vehicle, and have therefore not been influenced by any external attack such as meaconing. These consistency checks shall consist, for instance, of:

• — detection of abnormal power emissions by means of combined monitoring of the Automatic Gain Control (AGC) and Carrier-to-Noise density ratio (C/N0),

• — pseudorange measurement consistency and Doppler measurement consistency over time, including the detection of abrupt measurement jumps,

• — receiver autonomous integrity monitoring (RAIM) techniques, including the detection of inconsistent measurements with the estimated position,

• — position and velocity checks, including abnormal position and velocity solutions, sudden jumps and behaviour not consistent with the dynamics of the vehicle,

• — time and frequency consistency, including clock jumps and drifts that are not consistent with the receiver clock characteristics.

• GNS_3bThe European Commission shall develop and approve the following documents:

• — A Signal in Space Interface Control Document (SIS ICD), specifying in detail the OSNMA information transmitted in the Galileo signal.

• — OSNMA Receiver Guidelines, providing the requirements and processes in the receivers to guarantee a secure implementation of OSNMA, as well as recommendations to enhance OSNMA performance.

• GNSS receivers fitted in tachographs, either internal or external, shall be constructed in accordance with the SIS ICD and the OSNMA receiver guidelines.

• GNS_3cThe GNSS receiver shall provide position messages, called authenticated position messages in this Annex and its Appendixes, which are elaborated using only satellites from which the authenticity of the navigation messages has been successfully verified.

• GNS_3dThe GNSS receiver shall also provide standard position messages, elaborated using the satellites in view, regardless whether they are authenticated or not.

• GNS_3eThe GNSS receiver shall use the VU Real Time Clock (RTC) as time reference for the time synchronisation necessary for OSNMA.

• GNS_3fThe VU RTC time shall be provided to the GNSS receiver by the VU.

• GNS_3gThe maximal time drift specified in requirement 41 of Annex IC, shall be provided to the GNSS receiver by the VU, along with the VU RTC time.

This section describes the sentences used in the functioning of the Smart Tachograph, for transmitting standard and authenticated position messages. This section is valid both for the configuration of the Smart Tachograph with or without an external GNSS facility.

• GNS_4 The standard position data is based on the NMEA sentence Recommended Minimum Specific (RMC) GNSS Data, which contains the Position information (Latitude, Longitude), Time in UTC format (hhmmss.ss), and Speed Over Ground in Knots plus additional values.

The format of the RMC sentence is the following (as from NMEA V4.11 standard):

Image omitted; see official source Figure 2

Structure of the RMC sentence

$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh

• (1)Time (UTC)

• (2)Status, A= Valid position, V= Warning

• (3)Latitude

• (4)N or S

• (5)Longitude

• (6)E or W

• (7)Speed over ground in knots

• (8)Track made good, degrees true

• (9)Date, ddmmyy

• (10)Magnetic Variation, degrees

• (11)E or W

• (12)FAA Mode Indicator

• (13)Navigational status

• (14)Checksum

The Navigational status is optional and may not be present in the RMC sentence.

The Status gives indication if the GNSS signal is available. Until the value of the Status is not set to ‘A’, the received data (e.g., on Time or Latitude/Longitude) cannot be used to record the position of the vehicle in the VU.

The resolution of the position is based on the format of the RMC sentence described above. The first part of the fields 3) and 5) are used to represent the degrees. The rest are used to represent the minutes with three decimals. So the resolution is 1/1 000 of minute or 1/60 000 of degree (because one minute is 1/60 of a degree).

• GNS_4a The authenticated position data is based on a NMEA-like sentence, Authenticated Minimum Specific (AMC) Data, which contains the Position information (Latitude, Longitude), Time in UTC format (hhmmss.ss), and Speed Over Ground in Knots plus additional values.

The format of the AMC sentence is the following (as from NMEA V4.11 standard, except for value number 2):

Image omitted; see official source Figure 3

Structure of the AMC sentence

$--AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh

• (1)Time (UTC)

• (2)Status, A=Authenticated position (established using at least 4 satellites from which the authenticity of the navigation messages has been successfully verified), J=jamming or O=other GNSS attack in the absence of failed authentication of navigation messages (by implemented consistency checks according to GNS_3a), F=failed authentication of navigation messages (as detected by OSNMA verifications specified in the documents referred to in GNS_3b), V=Void (authenticated position is not available for any other reason)

• (3)Latitude

• (4)N or S

• (5)Longitude

• (6)E or W

• (7)Speed over ground in knots

• (8)Track made good, degrees true

• (9)Date, ddmmyy

• (10)Magnetic Variation, degrees

• (11)E or W

• (12)FAA Mode Indicator

• (13)Navigational status

• (14)Checksum

The Navigational status is optional and may not be present in the AMC sentence.

The Status gives indication if an authenticated GNSS position is available, if an attack on the GNSS signals has been detected, if authentication of navigation messages has failed, or if GNSS position is void. When the value of the Status is not set to ‘A’, the received data (e.g. Time or Latitude/Longitude) are considered to be not valid, and may not be used to record the position of the vehicle in the VU. When the value of the Status is set to ‘J’ (jamming), ‘O’ (other GNSS attack), or ‘F’ (failed authentication of navigation messages), a GNSS anomaly event shall be recorded in the VU, as defined in Annex IC and Appendix 1 (EventFaultCode).

• GNS_5 The Vehicle Unit shall store in the VU database the position information for latitude and longitude with a resolution of 1/10 of minute or 1/600 of a degree as described in Appendix 1 for type GeoCoordinates.

The GPS DOP and active satellites (GSA) command, as from NMEA V4.11 standard, can be used by the VU to determine and record the signal availability and accuracy of standard positions. In particular the HDOP is used to provide an indication on the level of accuracy of the recorded location data (see 4.2.2). The VU will store the value of the Horizontal Dilution of Precision (HDOP) calculated as the minimum of the HDOP values collected on the available GNSS systems.

The GNSS Id. indicates the corresponding NMEA Id. for every GNSS constellation and Satellite-Based Augmentation System (SBAS).

Image omitted; see official source

Figure 4

Structure of the GSA sentence (standard positions)

$--GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh

• (1)Selection mode

• (2)Mode

• (3)ID of 1^st satellite used for fix

• (4)ID of 2^nd satellite used for fix

…

• (14)ID of 12th satellite used for fix

• (15)PDOP

• (16)HDOP

• (17)VDOP

• (18)System ID

• (19)Checksum

The System ID is optional and may not be present in the GSA sentence.

Similarly, the NMEA-like sentence authenticated active satellites (ASA) command can be used by the VU to determine and record the signal availability and accuracy of authenticated positions. Values 1 to 18 are defined in NMEA V4.11 standard.

Image omitted; see official source Figure 5

Structure of the ASA sentence (authenticated positions)

$--ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh

• (1)Selection mode

• (2)Mode

• (3)ID of 1^st satellite used for fix

• (4)ID of 2^nd satellite used for fix

…

• (14)ID of 12^th satellite used for fix

• (15)PDOP

- (16)HDOP

- (17)VDOP

• (18)System ID

• (19)Checksum

The System ID is optional and may not be present in the ASA sentence.

• GNS_6 When an external GNSS facility is used, the GSA sentence shall be stored in the GNSS Secure Transceiver with record number ‘02’ to ‘06’, and the ASA sentence shall be stored with record number ‘12’ to ‘16’.

• GNS_7 The maximum size of the sentences (e.g., RMC, AMC, GSA, ASA or others), which can be used for the sizing of the read record command shall be 85 bytes (see Table 1).

4.1.   Configuration

4.1.1   Main components and interfaces

In this configuration, the GNSS receiver is a part of the external GNSS facility.

• GNS_8The external GNSS facility must be powered with a specific vehicle interface.

• GNS_9The external GNSS facility shall consist of the following components (see Figure 6):

• (a) A commercial GNSS receiver to provide the position data through the GNSS data interface. For example, the GNSS data interface can be NMEA standard V4.11 where the GNSS receiver acts as a talker and transmits NMEA sentences to the GNSS Secure Transceiver with a frequency of 1Hz for the pre-defined set of NMEA and NMEA-like sentences, which must include at least the RMC, AMC, GSA and ASA sentences. The implementation of the GNSS data interface is a choice of the manufacturers of the external GNSS facility.

• (b) A transceiver unit (GNSS Secure Transceiver) with the capability to support standard ISO/IEC 7816-4:2013 (see 4.2.1) to communicate with the vehicle unit and support the GNSS data interface to the GNSS receiver. The unit is provided with a memory to store the identification data of the GNSS receiver and external GNSS facility.

• (c) An enclosure system with tamper detection function, which encapsulates both the GNSS receiver and the GNSS Secure Transceiver. The tamper detection function shall implement the security protection measures as requested in the Protection Profile of the Smart Tachograph.

• (d) A GNSS antenna installed on the vehicle and connected to the GNSS receiver through the enclosure system.

- GNS_10The external GNSS facility has at least the following external interfaces:

- (a) the interface to the GNSS antenna installed on the vehicle truck, if an external antenna is used.

• (b) the interface to the Vehicle Unit.

• GNS_11In the VU, the VU Secure Transceiver is the other end of the secure communication with the GNSS Secure Transceiver and it must support ISO/IEC 7816-4:2013 for the connection to the external GNSS facility.

- GNS_12For the physical layer of the communication with the external GNSS facility, the vehicule unit shall support ISO/IEC 7816-12:2005 or another standard able to support ISO/IEC 7816-4:2013. (see 4.2.1).

4.1.2   External GNSS facility state at the end of production

• GNS_13The external GNSS facility shall store the following values in the non-volatile memory of the GNSS Secure Transceiver when it leaves the factory:

• — the EGF_MA key pair 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,

• — the extended serial-number of the external GNSS facility,

• — operating system identifier of the GNSS facility,

• — type approval number of the external GNSS facility;

• — Identifier of the security component of the external GNSS module.

4.2.   Communication between the external GNSS facility and the vehicle unit

4.2.1   Communication Protocol

• GNS_14The communication protocol between the external GNSS facility and the vehicle unit shall support the following functions:

• 1. The collection and distribution of GNSS data (e.g., position, timing, speed),

• 1. The collection of the configuration data of the external GNSS facility,

• 1. The management protocol to support the coupling, mutual authentication and session key agreement between the external GNSS facility and the VU,

• 1. The transmission to the external GNSS facility of the VU RTC time and of the maximal difference between true time and the VU RTC time.

• GNS_15The communication protocol shall be based on standard ISO/IEC 7816-4:2013 with the VU Secure Transceiver playing the master role and the GNSS Secure Transceiver playing the slave role. The physical connection between the external GNSS facility and the vehicule unit is based on ISO/IEC 7816-12:2005 or another standard able to support ISO/IEC 7816-4:2013

• GNS_16In the communication protocol, extended length fields shall not be supported.

• GNS_17The communication protocol of ISO 7816 (both -4:2013 and -12:2005) between the external GNSS facility and the VU shall be set to T = 1.

• GNS_18Regarding the functions 1) the collection and distribution of GNSS data and 2) the collection of the configuration data of the external GNSS facility and 3) management protocol, the GNSS Secure Transceiver shall simulate a smart card with a file system architecture composed by a Master File (MF), a Dedicated File (DF) with Application Identifier specified in Appendix 1 chapter 6.2 (‘FF 44 54 45 47 4D’) and with 3 EFs containing certificates and one single Elementary File (EF.EGF) with file identifier equal to ‘2F2F’ as described in Table 1.

• GNS_18aRegarding the function 4) the transmission to the external GNSS facility of the VU RTC time and of the maximal difference between true time and the VU RTC time, the GNSS Secure Transceiver shall use an EF (EF VU) in the same DF with file identifier equal to ‘2F30’ as described in Table 1.

- GNS_19The GNSS Secure Transceiver shall store the data coming from the GNSS receiver and the configuration in the EF.EGF. This is a linear, variable-length record file with an identifier equal to ‘2F2F’ in hexadecimal format.

• GNS_19aThe GNSS Secure Transceiver shall store the data coming from the VU in the EF VU. This is a linear, fixed-length record file with an identifier equal to ‘2F30’ in hexadecimal format.

• GNS_20The GNSS Secure Transceiver shall use a memory to store the data and be able to perform as many read/write cycles as needed during a lifetime of at least 15 years. Apart from this aspect, the internal design and implementation of the GNSS Secure Transceiver is left to the manufacturers.

• The mapping of record numbers and data is provided in Table 1. Note that there are five GSA sentences for the GNSS constellations and Satellite-Based Augmentation System (SBAS).

• GNS_21The file structure is provided in Table 1. For the access conditions (ALW, NEV, SM-MAC) see Appendix 2 chapter 3.5.

Table 1

File Structure

		Access conditions	Access conditions	Access conditions
File	File ID	Read	Update	Encrypted
MF	3F00
EF.ICC	0002	ALW	NEV (by VU)	No
DF GNSS Facility	0501	ALW	NEV	No
EF EGF_MACertificate	C100	ALW	NEV	No
EF CA_Certificate	C108	ALW	NEV	No
EF Link_Certificate	C109	ALW	NEV	No
EF EGF	2F2F	SM-MAC	NEV (by VU)	No
EF VU	2F30	SM-MAC	SM-MAC	No
File / Data element	Record no	Size (bytes)	Size (bytes)	Default values
---	---	---	---	---
		Min	Max
MF		552	1031
EF.ICC
sensorGNSSSerialNumber		8	8
DF GNSS Facility		612	1023
EF EGF_MACertificate		204	341
EGFCertificate		204	341	{00..00}
EF CA_Certificate		204	341
MemberStateCertificate		204	341	{00..00}
EF Link_Certificate		204	341
LinkCertificate		204	341	{00..00}
EF EGF
RMC NMEA Sentence	'01'	85	85
1st GSA NMEA Sentence	'02'	85	85
2nd GSA NMEA Sentence	'03'	85	85
3rd GSA NMEA Sentence	'04'	85	85
4th GSA NMEA Sentence	'05'	85	85
5th GSA NMEA Sentence	'06'	85	85
Extended serial-number of the external GNSS facility defined in Appendix 1 as SensorGNSSSerialNumber.	'07'	8	8
Operating system identifier of the GNSS Secure Transceiver defined in Appendix 1 as SensorOSIdentifier.	'08'	2	2
Type approval number of the external GNSS facility defined in Appendix 1 as SensorExternalGNSSApprovalNumber.	'09'	16	16
Identifier of the security component of the external GNSS facility defined in Appendix 1 as SensorExternalGNSSSCIdentifier	'10'	8	8
AMC Sentence	'11'	85	85
1st ASA Sentence	'12'	85	85
2nd ASA Sentence	'13'	85	85
3rd ASA Sentence	'14'	85	85
4th ASA Sentence	'15'	85	85
5th ASA Sentence	'16'	85	85
RFU – Reserved for Future Use	From '17' to 'FD'
EF VU
VuRtcTime (see Appendix 1)	'01'	4	4	{00..00}
VuGnssMaximalTimeDifference (see Appendix 1)	'02'	2	2	{00..00}

4.2.2   Secure transfer of GNSS data

• GNS_22The secure transfer of GNSS position data, VU RTC time and maximal time difference between true time and the VU RTC time shall be allowed only in the following conditions:

• 1. The coupling process has been completed as described in Appendix 11. Common security mechanisms.

- 2. The periodic mutual authentication and session key agreement between the VU and the external GNSS facility also described in Appendix 11. Common security mechanisms has been executed with the indicated frequency.

• GNS_23Every T seconds, where T is a value lower or equal to 20, unless coupling or mutual authentication and session key agreement takes place, the VU requests from the external GNSS facility the position information on the basis of the following flow:

• 1. The VU requests position data from the External GNSS facility together with Dilution of Precision data (from the GSA and ASA sentences). The VU Secure Transceiver shall use the ISO/IEC 7816-4:2013 SELECT and READ RECORD(S) commands in secure messaging authentication-only mode as described in section 11.5 of Appendix 11 with the file identifier ‘2F2F’ and RECORD number equal to ‘01’ for RMC NMEA sentence, ‘02’,‘03’,‘04’,‘05’,‘06’ for GSA NMEA sentence, ‘11’ for AMC sentence, and ‘12’,‘13’,‘14’,‘15’,‘16’ for ASA sentence.

- 2. The last position data received is stored in the EF with identifier ‘2F2F’ and the records described in Table 1 in the GNSS secure transceiver as the GNSS secure transceiver receives NMEA data with a frequency of at least 1 Hz from the GNSS receiver through the GNSS data interface.

• 1. The GNSS Secure Transceiver sends the response to the VU Secure Transceiver by using the APDU response message in secure messaging authentication-only mode as described in section 11.5 of Appendix 11.

- 4. The VU Secure Transceiver checks the authenticity and integrity of the received response. In case of positive outcome, the position data is transferred to the VU processor through the GNSS data interface.

• 1. The VU processor checks the received data extracting the information (e.g., latitude, longitude, time) from the RMC NMEA sentence. The RMC NMEA sentence includes the information if the non-authenticated position is valid. If the non-authenticated position is valid, the VU processor also extracts the values of HDOP from GSA NMEA sentences and calculates the minimum value on the available satellite systems (i.e., when the fix is available).

- 6. The VU processor also extracts the information (e.g., latitude, longitude, time) from the AMC sentence. The AMC sentence includes the information if the authenticated position is not valid or GNSS signal has been attacked. If the position is valid, the VU processor also extracts the values of HDOP from ASA sentences and calculates the minimum value on the available satellite systems (i.e., when the fix is available).

• GNS_23aThe VU shall also write VU RTC time and maximal time difference between true time and the VU RTC time as needed, by using the ISO/IEC 7816-4:2013 SELECT and WRITE RECORD(S) commands in secure messaging authentication-only mode as described in section 11.5 of Appendix 11 with the file identifier ‘2F30’ and RECORD number equal to ‘01’ for VuRtcTime and ‘02’ for MaximalTimeDifference.

4.2.3   Structure of the Read Record command

This section describes in detail the structure of the Read Record command. Secure messaging (authentication-only mode) is added as described in Appendix 11 Common security mechanisms.

- GNS_24The command shall support the Secure Messaging authentication-only-mode, see Appendix 11.

• GNS_25Command Message

| Byte | Length | Value | Description |

| --- | --- | --- | --- | | CLA | 1 | ‘0Ch’ | Secure messaging asked. | | INS | 1 | ‘B2h’ | Read Record | | P1 | 1 | ‘XXh’ | Record number (‘00’ references the current record) | | P2 | 1 | ‘04h’ | Read the record with the record number indicated in P1 | | Le | 1 | ‘XXh’ | Length of data expected. Number of Bytes to be read. |

• GNS_26The record referenced in P1 becomes the current record.

Byte	Length	Value	Description
#1-#X	X	‘XX..XXh’	Data read
SW	2	‘XXXXh’	Status Words (SW1,SW2)

• — If the command is successful, the GNSS secure transceiver returns ‘ 9000 ’.

• — If the current file is not record oriented, the GNSS secure transceiver returns ‘6981’.

- — If the command is used with P1 = ‘00’ but there is no current EF the GNSS secure transceiver returns ‘6986’ (command not allowed).

- — If the record is not found, the GNSS secure transceiver returns ‘6A83’.

• — If the external GNSS facility has detected tampering, it shall return status words ‘6690’.

4.2.4   Structure of the WriteRecord command

This section describes in detail the structure of the Write Record command. Secure messaging (authentication-only mode) is added as described in Appendix 11 Common security mechanisms.

- GNS_26a The command shall support the Secure Messaging authentication-only-mode, see Appendix 11.

• GNS_26b Command Message

Byte	Length	Value	Description
CLA	1	‘0Ch’	Secure messaging asked.
INS	1	‘D2h’	Write Record
P1	1	‘XXh’	Record number ('00' references the current record)
P2	1	‘04h’	Write the record with the record number indicated in P1
Data	X	‘XXh’	Data

• GNS_26c The record referenced in P1 becomes the current record.

| Byte | Length | Value | Description |

| --- | --- | --- | --- | | SW | 2 | ‘XXXXh’ | Status Words (SW1,SW2) |

• — If the command is successful, the GNSS secure transceiver returns ‘ 9000 ’.

- — If the current file is not record oriented, the GNSS secure transceiver returns '6981'.

• — If the command is used with P1 = '00' but there is no current EF the GNSS secure transceiver returns '6986' (command not allowed).

- — If the record is not found, the GNSS secure transceiver returns '6A83'.

• — If the external GNSS facility has detected tampering, it shall return status words ‘6690’.

4.2.5   Other commands

• GNS_27 The GNSS Secure Transceiver shall support the following tachograph generation 2 commands specified in Appendix 2: