(36)

Appendix 11 is amended as follows: (a) in point 8.2.3, paragraph CSM_49 is replaced by the following: ‘CSM_49 Vehicle units, tachograph cards and external GNSS facilities shall support the SHA-256, SHA-384 and SHA-512 algorithms specified in [SHS].’; (b) in point 9.1.2, the first sub-paragraph of paragraph CSM_58 is replaced by the following: ‘CSM_58 Whenever it generates a new European root key pair, the ERCA shall create a link certificate for the new European public key and sign it with the previous European private key. The validity period of the link certificate shall be 17 years plus 3 months. This is shown in Figure 1 in section 9.1.7 as well.’; (c) in point 9.1.4, paragraph CSM_72 is replaced by the following: ‘CSM_72 Two unique ECC key pairs shall be generated for each vehicle unit, designated as VU_MA and VU_Sign. This task is handled by VU manufacturers. Whenever a VU key pair is generated, the party generating the key shall send the public key to its MSCA, in order to obtain a corresponding VU certificate signed by the MSCA. The private key shall be used only by the vehicle unit.’; (d) point 9.1.5 is amended as follows: (i) paragraph CSM_83 is replaced by the following: ‘CSM_83 One unique ECC key pair, designated as Card_MA, shall be generated for each tachograph card. A second unique ECC key pair, designated as Card_Sign, shall additionally be generated for each driver card and each workshop card. This task may be handled by card manufacturers or card personalisers. Whenever a card key pair is generated, the party generating the key shall send the public key to its MSCA, in order to obtain a corresponding card certificate signed by the MSCA. The private key shall be used only by the tachograph card.’; (ii) paragraph CSM_88 is replaced by the following: ‘CSM_88 The validity period of a Card_MA certificate shall be as follows: — For driver cards: 5 years — For company cards: 5 years — For control cards: 2 years — For workshop cards: 1 year’; (iii) the following text is added in paragraph CSM_91: ‘— Additionally, for control cards, company cards and workshop cards only, and only if such cards are issued during the first three months of the validity period of a new EUR certificate: the EUR certificate that is two generations older, if existing. Note to last bullet: For example, in the first three months of the ERCA(3) certificate (see Figure 1), the mentioned cards shall contain the ERCA(1) certificate. This is needed to ensure that these cards can be used to perform data downloads from ERCA(1) VUs whose normal 15-year life period plus the 3-months data downloading period expires during these months; see the last bullet of requirement 13) in Annex IC.’; (e) point 9.1.6 is amended as follows: (i) paragraph CSM_93 is replaced by the following: ‘CSM_93 One unique ECC key pair shall be generated for each external GNSS facility, designated as EGF_MA. This task is handled by external GNSS facility manufacturers. Whenever an EGF_MA key pair is generated, the party generating th e key shall send the public key to its MSCA in order to obtain a corresponding EGF_MA certificate signed by the MSCA. The private key shall be used only by the external GNSS facility.’; (ii) paragraph CSM_95 is replaced by the following: ‘CSM_95 An external GNSS facility shall use its EGF_MA key pair, consisting of private key EGF_MA.SK and public key EGF_MA.PK, exclusively to perform mutual authentication and session key agreement towards vehicle units, as specified in section 11.4 of this Appendix.’; (f) point 9.1.7 is amended as follows: (i) Figure 1 is replaced by the following: ‘Figure 1 Issuance and usage of different generations of ERCA root certificates, ERCA link certificates, MSCA certificates and equipment certificates Text of image Legend Private key usage period / Remaining certificate validity Second generation ERCA certificate and certificates based on it Third generation ERCA certificate and certificates based on it First generation ERCA certificate and certificates based on it Year Year Year (ii) paragraph 6 in the Notes to Figure 1 is replaced by the following: ‘6. To save space, the difference in validity period between the Card_MA and Card_Sign certificates is shown only for the first generation.’; (g) point 9.2.1.1 is amended as follows: (i) in paragraph CSM_106, the first dash is replaced by the following: ‘— For 128-bit motion sensor master keys: CV = “B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83” ’; (ii) in paragraph CSM_107, the first sub-paragraph is replaced by the following: ‘Each Motion sensor manufacturer shall generate a random and unique pairing key KP for every motion sensor, and shall send each pairing key to its Member State Certificate Authority. The MSCA shall encrypt each pairing key separately with the motion sensor master key KM and shall return the encrypted key to the motion sensor manufacturer. For each encrypted key, the MSCA shall notify the motion sensor manufacturer of the version number of the associated KM.’; (iii) paragraph CSM_108 is replaced by the following: ‘CSM_108 Each motion sensor manufacturer shall generate a unique serial number for every motion sensor, and shall send all serial numbers to its Member State Certificate Authority. The MSCA shall encrypt each serial number separately with the identification key KID and shall return the encrypted serial number to the motion sensor manufacturer. For each encrypted serial number, the MSCA shall notify the motion sensor manufacturer of the version number of the associated KID.’; (h) point 9.2.2.1 is amended as follows: (i) paragraph CSM_123 is replaced by the following: ‘CSM_123 For every vehicle unit, the vehicle unit manufacturer shall create a unique VU serial number and shall send this number to its Member State Certificate Authority in a request to obtain a set of two VU-specific DSRC keys. The VU serial number shall have data type . Note: — This VU serial number shall be identical to the vuSerialNumber element of VuIdentification, see Appendix 1 and to the Certificate Holder Reference in the VU’s certificates. — The VU serial number may not be known at the moment a vehicle unit manufacturer requests the VU-specific DSRC keys. In this case, the VU manufacturer shall send instead the unique certificate request ID it used when requesting the VU’s certificates; see CSM_153. This certificate request ID shall therefore be equal to the Certificate Holder Reference in the VU’s certificates.’; (ii) in paragraph CSM_124, the info requirement in step 2 is replaced by the following: ‘info = VU serial number or certificate request ID, as specified in CSM_123’; (iii) paragraph CSM_128 is replaced by the following: ‘CSM_128 The MSCA shall keep records of all VU-specific DSRC keys it generated, their version number and the VU serial number or certificate request ID used in deriving them.’; (i) in point 9.3.1, the first sub-paragraph in paragraph CSM_135 is replaced by the following: ‘The Distinguished Encoding Rules (DER) according to [ISO 8825-1] shall be used to encode the data objects within certificates. Table 4 shows the full certificate encoding, including all tag and length bytes.’; (j) in point 9.3.2.3, paragraph CSM_141 is replaced by the following: ‘CSM_141 The Certificate Holder Authorisation shall be used to identify the type of certificate. It consists of the six most significant bytes of the Tachograph Application ID, concatenated with the equipment type, which indicates the type of equipment for which the certificate is intended. In the case of a VU certificate, a driver card certificate or a workshop card certificate, the equipment type is also used to differentiate between a certificate for Mutual Authentication and a certificate for creating digital signatures (see section 9.1 and Appendix 1, data type EquipmentType).’; (k) in point 9.3.2.5, the following sub-paragraph is added in paragraph CSM_146: ‘Note: For a card certificate, the value of the CHR shall be equal to the value of the cardExtendedSerialNumber in EF_ICC; see Appendix 2. For an EGF certificate, the value of the CHR shall be equal to the value of the sensorGNSSSerialNumber in EF_ICC; see Appendix 14. For a VU certificate, the value of the CHR shall be equal to the vuSerialNumber element of VuIdentification, see Appendix 1, unless the manufacturer does not know the manufacturer-specific serial number at the time the certificate is requested.’; (l) in point 9.3.2.6, paragraph CSM_148 is replaced by the following: ‘CSM_148 The Certificate Effective Date shall indicate the starting date and time of the validity period of the certificate.’; (m) point 9.3.3 is amended as follows: (i) in paragraph CSM_151, the first sub-paragraph is replaced by the following: ‘When requesting a certificate, an MSCA shall send the following data to the ERCA:’; (ii) paragraph CSM_153 is replaced by the following: ‘CSM_153 An equipment manufacturer shall send the following data in a certificate request to an MSCA, allowing the MSCA to create the Certificate Holder Reference of the new equipment certificate: — If known (see CSM_154), a serial number for the equipment, unique for the manufacturer, the equipment's type and the month of manufacturing. Otherwise, a unique certificate request identifier. — The month and the year of equipment manufacturing or of the certificate request. The manufacturer shall ensure that this data is correct and that the certificate returned by the MSCA is inserted in the intended equipment.’; (n) point 10.2.1 is amended as follows: (i) in paragraph CSM_157, the text before the Notes to Figure 4 is replaced by the following: ‘Vehicle 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: — 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.’; (ii) in paragraph CSM_159, the following sentence is added: ‘Whereas storing of all other types of certificate is optional, it is mandatory for a VU to store a new link certificate presented by a card.’; (o) point 10.2.2 is amended as follows: (i) in paragraph CSM_161, the text before the Figure 5 is replaced by the following: ‘Tachograph 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: — 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).’; (ii) paragraph CSM_165 is replaced by the following: ‘CSM_165 If the MSE: Set AT command is successful, the card shall set the indicated VU.PK for subsequent use during Vehicle Authentication, and shall temporarily store Comp(VU.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.’; (p) point 10.3 is amended as follows: (i) the first sub-paragraph in paragraph CSM_170 is replaced by the following: ‘Next to the card challenge, the VU shall include in the signature the certificate holder reference taken from the card certificate.’; (ii) in paragraph CSM_171, Figure 6 is replaced by the following: ‘Figure 6 VU Authentication protocol ’ (iii) paragraph CSM_174 is replaced by the following: ‘CSM_174 Upon receiving the VU’s signature in an EXTERNAL AUTHENTICATE command, the card shall — Calculate the authentication token by concatenating Card.CHR, the card challenge 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.’; (q) in point 10.4, paragraph CSM_176 is amended as follows: (i) sub-paragraph 2 is replaced by the following: ‘2. The VU sends the public point VU.PKeph 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.PKeph) to the card, and the card stored it.’; (ii) sub-paragraph 6 is replaced by the following: ‘6. Using KMAC, the card computes an authentication token over the VU ephemeral public point: TPICC = CMAC(KMAC, VU.PKeph). The public point shall be in the format used by the VU (see bullet 2 above). The card sends NPICC and TPICC to the vehicle unit.’; (r) in point 10.5.2, paragraph CSM_191 is replaced by the following: ‘CSM_191 Any data object to be encrypted shall be padded according to [ISO 7816-4] using padding-content indicator ‘01’. For the calculation of the MAC, 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 Figure 9 Transformation of an authenticated Case 1 / Case 3 Response APDU Figure 10 Transformation of an encrypted and authenticated Case 2/Case 4 Response APDU ’ (s) in point 10.5.3, paragraph CSM_193 is replaced by the following: ‘CSM_193 A tachograph card shall abort an ongoing Secure Messaging session if and only if one of the following conditions occur: — it receives a plain command APDU, — it detects a Secure Messaging error in a command APDU: — An expected Secure Messaging data object is missing, the order of data objects is incorrect, or an unknown data object is included. — A Secure Messaging data object is incorrect, e.g. the MAC value is incorrect or the TLV structure is incorrect. — it is depowered or reset, — the VU 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’; (t) point 11.3.2 is amended as follows: (i) the first sub-paragraph of paragraph CSM_208 is replaced by the following: ‘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’; (ii) paragraph CSM_210 is replaced by the following: ‘CSM_210 Once it has verified the VU_MA certificate, the external GNSS facility shall store this certificate for use during normal operation; see section 11.3.3.’; (u) in point 11.3.3, the first sub-paragraph in paragraph CSM_211, is replaced by the following: ‘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.’; (v) in point 12.3, Table 6 is replaced by the following: ‘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 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’ (w) in point 13.1, the requirement on the VU serial number in subparagraph CSM_224 is replaced by the following: ‘VU serial number the VU’s serial number or certificate request ID (data type VuSerialNumber or CertificateRequestID) – see CSM_123’; (x) in point 13.3, the second indent in paragraph CSM_228 is replaced by the following: ‘2. The control card shall use the indicated DSRC master key in combination with the VU serial number or the certificate request ID in the DSRC security data to derive the VU-specific DSRC keys K_VUDSRC_ENC and K_VUDSRC_MAC, as specified in CSM_124.’; (y) point 14.3 is amended as follows: (i) in paragraph CSM_234, the text before the Notes to figure 13 is replaced by the following: ‘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.’; (ii) Figure 13 is replaced by the following: ‘Figure 13 Protocol for verification of the signature over a downloaded data file ’