{
  "url": "https://openlegislation.uk/eu-regulation-2016-799/annex-1/appendix-11",
  "json_url": "https://openlegislation.uk/eu-regulation-2016-799/annex-1/appendix-11.json",
  "legislation": "eur/2016/799",
  "legislation_title": "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)",
  "legislation_url": "https://openlegislation.uk/eu-regulation-2016-799",
  "path": "annex/1/appendix/11",
  "kind": "appendix",
  "number": "11",
  "heading": null,
  "text": "COMMON SECURITY MECHANISMS\nPREAMBLE\nThis Appendix specifies the security mechanisms ensuring\nmutual authentication between different components of the tachograph system.\nconfidentiality, integrity, authenticity and/or non-repudiation of data transferred between different components of the tachograph system or downloaded to external storage media.\nThis Appendix consists of two parts. Part A defines the security mechanisms for the first-generation tachograph system (digital tachograph). Part B defines the security mechanisms for the second-generation tachograph system (smart tachograph).\nThe mechanisms specified in Part A of this Appendix shall apply if at least one of the components of the tachograph system involved in a mutual authentication and/or data transfer process is of the first generation.\nThe mechanisms specified in Part B of this Appendix shall apply if both components of the tachograph system involved in the mutual authentication and/or data transfer process are of the second generation.\nAppendix 15 provides more information regarding the use of first generation components in combination with second-generation components.\nPART A\nFIRST-GENERATION TACHOGRAPH SYSTEM\n1.\nINTRODUCTION\n1.1.\nReferences\nThe following references are used in this Appendix:\nSHA-1National Institute of Standards and Technology (NIST). FIPS Publication 180-1: Secure Hash Standard. April 1995.\nPKCS1RSA Laboratories. PKCS # 1: RSA Encryption Standard. Version 2.0. October 1998.\nTDESNational Institute of Standards and Technology (NIST). FIPS Publication 46-3: Data Encryption Standard. Draft 1999.\nTDES-OPANSI X9.52, Triple Data Encryption Algorithm Modes of Operation. 1998.\nISO/IEC 7816-4Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 4: Interindustry commands for interexchange. First edition: 1995 + Amendment 1: 1997.\nISO/IEC 7816-6Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 6: Interindustry data elements. First edition: 1996 + Cor 1: 1998.\nISO/IEC 7816-8Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 8: Security related interindustry commands. First edition 1999.\nISO/IEC 9796-2Information Technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Mechanisms using a hash function. First edition: 1997.\nISO/IEC 9798-3Information Technology — Security techniques — Entity authentication mechanisms — Part 3: Entity authentication using a public key algorithm. Second edition 1998.\nISO 16844-3Road vehicles — Tachograph systems — Part 3: Motion sensor interface.\n1.2.\nNotations and abbreviated terms\nThe following notations and abbreviated terms are used in this Appendix:\n(Ka, Kb, Kc)a key bundle for use by the Triple Data Encryption Algorithm,\nCACertification Authority,\nCARCertification Authority Reference,\nCCCryptographic Checksum,\nCGCryptogram,\nCHCommand Header,\nCHACertificate Holder Authorisation,\nCHRCertificate Holder Reference,\nD()Decryption with DES,\nDEData Element,\nDOData Object,\ndRSA private key, private exponent,\neRSA public key, public exponent,\nE()Encryption with DES,\nEQTEquipment,\nHash()hash value, an output of Hash,\nHashhash function,\nKIDKey Identifier,\nKmTDES key. Master Key defined in ISO 16844-3.\nKmVU TDES key inserted in vehicle units.\nKmWC TDES key inserted in workshop cards.\nmmessage representative, an integer between 0 and n-1,\nnRSA keys, modulus,\nPBPadding Bytes,\nPIPadding Indicator byte (for use in Cryptogram for confidentiality DO),\nPVPlain Value,\nssignature representative, an integer between 0 and n-1,\nSSCSend Sequence Counter,\nSMSecure Messaging,\nTCBCTDEA Cipher Block Chaining Mode of Operation\nTDEATriple Data Encryption Algorithm,\nTLVTag Length Value,\nVUVehicle Unit,\nX.Cthe certificate of user X issued by a certification authority,\nX.CAa certification authority of user X,\nX.CA.PK o X.Cthe operation of unwrapping a certificate to extract a public key. It is an infix operator, whose left operand is the public key of a certification authority, and whose right operand is the certificate issued by that certification authority. The outcome is the public key of the user X whose certificate is the right operand,\nX.PKRSA public key of a user X,\nX.PK[I]RSA encipherment of some information I, using the public key of user X,\nX.SKRSA private key of a user X,\nX.SK[I]RSA encipherment of some information I, using the private key of user X,\n‘xx’an Hexadecimal value,\n||concatenation operator.\n2.\nCRYPTOGRAPHIC SYSTEMS AND ALGORITHMS\n2.1.\nCryptographic systems\nCSM_001\nVehicle units and tachograph cards shall use a classical RSA public-key cryptographic system to provide the following security mechanisms:\nauthentication between vehicle units and cards,\ntransport of Triple-DES session keys between vehicle units and tachograph cards,\ndigital signature of data downloaded from vehicle units or tachograph cards to external media.\nCSM_002\nVehicle units and tachograph cards shall use a Triple DES symmetric cryptographic system to provide a mechanism for data integrity during user data exchange between vehicle units and tachograph cards, and to provide, where applicable, confidentiality of data exchange between vehicle units and tachograph cards.\n2.2.\nCryptographic algorithms\n2.2.1\nRSA algorithm\nCSM_003\nThe RSA algorithm is fully defined by the following relations:\nX.SK[m] = s = md mod n\nX.PK[s] = m = se mod n\nA more comprehensive description of the RSA function can be found in reference [PKCS1]. Public exponent, e, for RSA calculations is an integer between 3 and n-1 satisfying gcd(e, lcm(p-1, q-1))=1.\n2.2.2\nHash algorithm\nCSM_004\nThe digital signature mechanisms shall use the SHA-1 hash algorithm as defined in reference [SHA-1].\n2.2.3\nData Encryption Algorithm\nCSM_005\nDES based algorithms shall be used in Cipher Block Chaining mode of operation.\n3.\nKEYS AND CERTIFICATES\n3.1.\nKeys generation and distribution\n3.1.1\nRSA Keys generation and distribution\nCSM_006\nRSA keys shall be generated through three functional hierarchical levels:\nEuropean level,\nMember State level,\nEquipment level.\nCSM_007\nAt European level, a single European key pair (EUR.SK and EUR.PK) shall be generated. The European private key shall be used to certify the Member States public keys. Records of all certified keys shall be kept. These tasks shall be handled by a European Certification Authority, under the authority and responsibility of the European Commission.\nCSM_008\nAt Member State level, a Member State key pair (MS.SK and MS.PK) shall be generated. Member States public keys shall be certified by the European Certification Authority. The Member State private key shall be used to certify public keys to be inserted in equipment (vehicle unit or tachograph card). Records of all certified public keys shall be kept with the identification of the equipment to which it is intended. These tasks shall be handled by a Member State Certification Authority. A Member State may regularly change its key pair.\nCSM_009\nAt equipment level, one single key pair (EQT.SK and EQT.PK) shall be generated and inserted in each equipment. Equipment public keys shall be certified by a Member State Certification Authority. These tasks may be handled by equipment manufacturers, equipment personalisers or Member State authorities. This key pair is used for authentication, digital signature and encipherement services\nCSM_010\nPrivate keys confidentiality shall be maintained during generation, transport (if any) and storage.\nThe following picture summarises the data flow of this process:\n3.1.2\nRSA Test keys\nCSM_011\nFor the purpose of equipment testing (including interoperability tests) the European Certification Authority shall generate a different single European test key pair and at least two Member State test key pairs, the public keys of which shall be certified with the European private test key. Manufacturers shall insert, in equipment undergoing type approval tests, test keys certified by one of these Member State test keys.\n3.1.3\nMotion sensor keys\nThe confidentiality of the three Triple DES keys described below shall be appropriately maintained during generation, transport (if any) and storage.\nIn order to support tachograph components compliant with ISO 16844, the European Certification Authority and the Member State Certification Authorities shall, in addition, ensure the following:\nCSM_036\nThe European Certification authority shall generate KmVU and KmWC, two independent and unique Triple DES keys, and generate Km as: Km = KmVU XOR KmWC. The European Certification Authority shall forward these keys, under appropriately secured procedures, to Member States Certification Authorities at their request.\nCSM_037\nMember States Certification Authorities shall:\nuse Km to encrypt motion sensor data requested by motion sensor manufacturers (data to be encrypted with Km is defined in ISO 16844-3),\nforward KmVU to vehicle unit manufacturers, under appropriately secured procedures, for insertion in vehicle units,\nensure that KmWC will be inserted in all workshop cards ( in elementary file) during card personalisation.\n3.1.4\nT-DES session keys generation and distribution\nCSM_012\nVehicle units and tachograph cards shall, as a part of the mutual authentication process, generate and exchange necessary data to elaborate a common Triple DES session key. This exchange of data shall be protected for confidentiality through an RSA crypt-mechanism.\nCSM_013\nThis key shall be used for all subsequent cryptographic operations using secure messaging. Its validity shall expire at the end of the session (withdrawal of the card or reset of the card) and/or after 240 use (one use of the key = one command using secure messaging sent to the card and associated response).\n3.2.\nKeys\nCSM_014\nRSA keys shall have (whatever the level) the following lengths: modulus n1 024 bits, public exponent e 64 bits maximum, private exponent d1 024 bits.\nCSM_015\nTriple DES keys shall have the form (Ka, Kb, Ka) where Ka and Kb are independent 64 bits long keys. No parity error detecting bits shall be set.\n3.3.\nCertificates\nCSM_016\nRSA Public key certificates shall be ‘non self-descriptive’‘Card Verifiable’ certificates (Ref.: ISO/IEC 7816-8)\n3.3.1\nCertificates content\nCSM_017\nRSA Public key certificates are built with the following data in the following order:\nData\nFormat\nBytes\nObs\nCPI\nINTEGER\n1\nCertificate Profile Identifier (‘01’ for this version)\nCAR\nOCTET STRING\n8\nCertification Authority Reference\nCHA\nOCTET STRING\n7\nCertificate Holder Authorisation\nEOV\nTimeReal\n4\nCertificate end of validity. Optional, ‘FF’ padded if not used.\nCHR\nOCTET STRING\n8\nCertificate Holder Reference\nn\nOCTET STRING\n128\nPublic key (modulus)\ne\nOCTET STRING\n8\nPublic Key (public exponent)\n164\nNotes:\n1.\nThe ‘Certificate Profile Identifier’ (CPI) delineates the exact structure of an authentication certificate. It can be used as an equipment internal identifier of a relevant headerlist which describes the concatenation of Data Elements within the certificate.\nThe headerlist associated with this certificate content is as follows:\n‘4D’\n‘16’\n‘5F 29’\n‘01’\n‘42’\n‘08’\n‘5F 4B’\n‘07’\n‘5F 24’\n‘04’\n‘5F 20’\n‘08’\n‘7F 49’\n‘05’\n‘81’\n‘81 80’\n‘82’\n‘08’\nExtended Headerlist Tag\nLength of header list\nCPI Tag\nCPI Length\nCAR Tag\nCAR Length\nCHA Tag\nCHA Length\nEOV Tag\nEOV Length\nCHR Tag\nCHR Length\nPublic Key Tag (Constructed)\nLength of subsequent DOs\nmodulus Tag\nmodulus length\npublic exponent Tag\npublic exponent length\n2.\nThe ‘Certification Authority Reference’ (CAR) has the purpose of identifying the certificate issuing CA, in such a way that the Data Element can be used at the same time as an Authority Key Identifier to reference the Public Key of the Certification Authority (for coding, see Key Identifier below).\n3.\nThe ‘Certificate Holder Authorisation’ (CHA) is used to identify the rights of the certificate holder. It consists of the Tachograph Application ID and of the type of equipment to which the certificate is intended (according to data element, ‘00’ for a Member State).\n4.\nThe ‘Certificate Holder Reference’ (CHR) has the purpose of identifying uniquely the certificate holder, in such a way that the Data Element can be used at the same time as a Subject Key Identifier to reference the Public Key of the certificate holder.\n5.\nKey Identifiers uniquely identify certificate holder or certification authorities. They are coded as follows:\n5.1Equipment (VU or Card):\nData\nEquipment serial number\nDate\nType\nManufacturer\nLength\n4 Bytes\n2 Bytes\n1 Byte\n1 Byte\nValue\nInteger\nmm yy BCD coding\nManufacturer specific\nManufacturer code\nIn the case of a VU, the manufacturer, when requesting certificates, may or may not know the identification of the equipment in which the keys will be inserted.\nIn the first case, the manufacturer will send the equipment identification with the public key to its Member State authority for certification. The certificate will then contain the equipment identification, and the manufacturer must ensure that keys and certificate are inserted in the intended equipment. The Key identifier has the form shown above.\nIn the later case, the manufacturer must uniquely identify each certificate request and send this identification with the public key to its Member State authority for certification. The certificate will contain the request identification. The manufacturer must feed back its Member State authority with the assignment of key to equipment (i.e. certificate request identification, equipment identification) after key installation in the equipment. The key identifier has the following form:\nData\nCertificate request serial number\nDate\nType\nManufacturer\nLength\n4 Bytes\n2 Bytes\n1 Byte\n1 Byte\nValue\nInteger\nmm yy BCD coding\n‘FF’\nManufacturer code\n5.2Certification Authority:\nData\nAuthority Identification\nKey serial number\nAdditional info\nIdentifier\nLength\n4 Bytes\n1 Byte\n2 Bytes\n1 Byte\nValue\n1 Byte nation numerical code\n3 Bytes nation alphanumerical code\nInteger\nadditional coding\n(CA specific)\n‘FF FF’ if not used\n‘01’\nThe key serial number is used to distinguish the different keys of a Member State, in the case the key is changed.\n6.\nCertificate verifiers shall implicitly know that the public key certified is an RSA key relevant to authentication, digital signature verification and encipherement for confidentiality services (the certificate contains no Object Identifier to specify it).\n3.3.2\nCertificates issued\nCSM_018\nThe certificate issued is a digital signature with partial recovery of the certificate content in accordance with ISO/IEC 9796-2 (except for its annex A4), with the ‘Certification Authority Reference’ appended.\nX.C = X.CA.SK[‘6A’ || Cr || Hash(Cc) || ‘BC’] || Cn || X.CAR\nWith certificate content = Cc =\nCr\n||\nCn\n106 bytes\n58 bytes\nNotes:\n1.\nThis certificate is 194 bytes long.\n2.\nCAR, being hidden by the signature, is also appended to the signature, such that the Public Key of the Certification Authority may be selected for the verification of the certificate.\n3.\nThe certificate verifier shall implicitly know the algorithm used by the Certification Authority to sign the certificate.\n4.\nThe headerlist associated with this issued certificate is as follows:\n‘7F 21’\n‘09’\n‘5F 37’\n‘81 80’\n‘5F 38’\n‘3A’\n‘42’\n‘08’\nCV Certificate Tag (Constructed)\nLength of subsequent DOs\nSignature Tag\nSignature Length\nRemainder Tag\nRemainder Length\nCAR Tag\nCAR Length\n3.3.3\nCertificate verification and unwrapping\nCertificate verification and unwrapping consists in verifying the signature in accordance with ISO/IEC 9796-2, retrieving the certificate content and the public key contained: X.PK = X.CA.PK o X.C, and verifying the validity of the certificate.\nCSM_019\nIt involves the following steps:\nVerify signature and retrieve content:\n—\nfrom X.C retrieve Sign, Cn' and CAR':\nX.C =\nSign\n||\nCn'\n||\nCAR'\n128 Bytes\n58 Bytes\n8 Bytes\nfrom CAR' select appropriate Certification Authority Public Key (if not done before through other means)\nopen Sign with CA Public Key: Sr'= X.CA.PK [Sign],\ncheck Sr' starts with ‘6A’ and ends with ‘BC’\n—\ncompute Cr' and H' from: Sr' =\n‘6A’\n||\nCr'\n||\nH'\n||\n‘BC’\n106 Bytes\n20 Bytes\nRecover certificate content C' = Cr' || Cn',\ncheck Hash(C') = H'\nIf the checks are OK the certificate is a genuine one, its content is C'.\nVerify validity. From C':\nif applicable, check End of validity date,\nRetrieve and store public key, Key Identifier, Certificate Holder Authorisation and Certificate End of Validity from C':\nX.PK = n || e\nX.KID = CHR\nX.CHA = CHA\nX.EOV = EOV\n4.\nMUTUAL AUTHENTICATION MECHANISM\nMutual authentication between cards and VUs is based on the following principle:\nEach party shall demonstrate to the other that it owns a valid key pair, the public key of which has been certified by a Member State certification authority, itself being certified by the European certification authority.\nDemonstration is made by signing with the private key a random number sent by the other party, who must recover the random number sent when verifying this signature.\nThe mechanism is triggered at card insertion by the VU. It starts with the exchange of certificates and unwrapping of public keys, and ends with the setting of a session key.\nCSM_020\nThe following protocol shall be used (arrows indicate commands and data exchanged (see Appendix 2)):\n5.\nVU-CARDS DATA TRANSFER CONFIDENTIALITY, INTEGRITY AND AUTHENTICATION MECHANISMS\n5.1.\nSecure Messaging\nCSM_021\nVU-Cards data transfers integrity shall be protected through Secure Messaging in accordance with references [ISO/IEC 7816-4] and [ISO/IEC 7816-8].\nCSM_022\nWhen data need to be protected during transfer, a Cryptographic Checksum Data Object shall be appended to the Data Objects sent within the command or the response. The Cryptographic Checksum shall be verified by the receiver.\nCSM_023\nThe cryptographic checksum of data sent within a command shall integrate the command header, and all data objects sent (=>CLA = ‘0C’, and all data objects shall be encapsulated with tags in which b1=1).\nCSM_024\nThe response status-information bytes shall be protected by a cryptographic checksum when the response contains no data field.\nCSM_025\nCryptographic checksums shall be 4 Bytes long.\nThe structure of commands and responses when using secure messaging is therefore the following:\nThe DOs used are a partial set of the Secure Messaging DOs described in ISO/IEC 7816-4:\nTag\nMnemonic\nMeaning\n‘81’\nTPV\nPlain Value not BER-TLV coded data (to be protected by CC)\n‘97’\nTLE\nValue of Le in the unsecured command (to be protected by CC)\n‘99’\nTSW\nStatus-Info (to be protected by CC)\n‘8E’\nTCC\nCryptographic Checksum\n‘87’\nTPI CG\nPadding Indicator Byte || Cryptogram (Plain Value not coded in BER-TLV)\nGiven an unsecured command response pair:\nCommand header\nCommand body\nCLA\nINS\nP1\nP2\n[Lc field]\n[Data field]\n[Le field]\nfour bytes\nL bytes, denoted as B1 to BL\nResponse body\nResponse trailer\n[Data field]\nSW1\nSW2\nLr data bytes\ntwo bytes\nThe corresponding secured command response pair is:\nSecured command:\nCommand header (CH)\nCommand body\nCLA\nINS\nP1\nP2\n[New Lc field]\n[New Data field]\n[New Le field]\n‘OC’\nLength of New Data field\nTPV\nLPV\nPV\nTLE\nLLE\nLe\nTCC\nLCC\nCC\n‘00’\n‘81’\nLc\nData field\n‘97’\n‘01’\nLe\n‘8E’\n‘04’\nCC\nData to be integrated in checksum = CH || PB || TPV || LPV || PV || TLE || LLE || Le || PB\nPB = Padding Bytes (80 .. 00) in accordance with ISO-IEC 7816-4 and ISO 9797 method 2.\nDOs PV and LE are present only when there is some corresponding data in the unsecured command.\nSecured response:\n1..Case where response data field is not empty and needs not to be protected for confidentiality:\nResponse body\nResponse trailer\n[New Data field]\nnew SW1 SW2\nTPV\nLPV\nPV\nTCC\nLCC\nCC\n‘81’\nLr\nData field\n‘8E’\n‘04’\nCC\nData to be integrated in checksum = TPV || LPV || PV || PB\n2..Case where response data field is not empty and needs to be protected for confidentiality:\nResponse body\nResponse trailer\n[New Data field]\nnew SW1 SW2\nTPI CG\nLPI CG\nPI CG\nTCC\nLCC\nCC\n‘87’\nPI || CG\n‘8E’\n‘04’\nCC\nData to be carried by CG: non BER-TLV coded data and padding bytes.\nData to be integrated in checksum = TPI CG || LPI CG || PI CG || PB\n3..Case where response data field is empty:\nResponse body\nResponse trailer\n[New Data field]\nnew SW1 SW2\nTSW\nLSW\nSW\nTCC\nLCC\nCC\n‘99’\n‘02’\nNew SW1 SW2\n‘8E’\n‘04’\nCC\nData to be integrated in checksum = TSW || LSW || SW || PB\n5.2.\nTreatment of Secure Messaging errors\nCSM_026\nWhen the tachograph card recognises an SM error while interpreting a command, then the status bytes must be returned without SM. In accordance with ISO/IEC 7816-4, the following status bytes are defined to indicate SM errors:\n‘66 88’Verification of Cryptographic Checksum failed,\n‘69 87’Expected SM Data Objects missing,\n‘69 88’SM Data Objects incorrect.\nCSM_027\nWhen the tachograph card returns status bytes without SM DOs or with an erroneous SM DO, the session must be aborted by the VU.\n5.3.\nAlgorithm to compute Cryptographic Checksums\nCSM_028\nCryptographic checksums are built using a retail MACs in accordance with ANSI X9.19 with DES:\nInitial stage: The initial check block y0 is E(Ka, SSC).\nSequential stage: The check blocks y1, .., yn are calculated using Ka.\nFinal stage: The cryptographic checksum is calculated from the last check block yn as follows: E(Ka, D(Kb, yn)).\nwhere E() means encryption with DES, and D() means decryption with DES.\nThe four most significant bytes of the cryptographic checksum are transferred\nCSM_029\nThe Send Sequence Counter (SSC) shall be initiated during key agreement procedure to:\nInitial SSC: Rnd3 (4 least significant bytes) || Rnd1 (4 least significant bytes).\nCSM_030\nThe Send Sequence Counter shall be increased by 1 each time before a MAC is calculated (i.e. the SSC for the first command is Initial SSC + 1, the SSC for the first response is Initial SSC + 2).\nThe following figure shows the calculation of the retail MAC:\n5.4.\nAlgorithm to compute cryptograms for confidentiality DOs\nCSM_031\nCryptograms are computed using TDEA in TCBC mode of operation in accordance with references [TDES] and [TDES-OP] and with the Null vector as Initial Value block.\nThe following figure shows the application of keys in TDES:\n6.\nDATA DOWNLOAD DIGITAL SIGNATURE MECHANISMS\nCSM_032\nThe Intelligent Dedicated Equipment (IDE) stores data received from an equipment (VU or card) during one download session within one physical data file. This file must contain the certificates MSi.C and EQT.C. The file contains digital signatures of data blocks as specified in Appendix 7 Data Downloading Protocols.\nCSM_033\nDigital signatures of downloaded data shall use a digital signature scheme with appendix such, that downloaded data may be read without any decipherment if desired.\n6.1.\nSignature generation\nCSM_034\nData signature generation by the equipment shall follow the signature scheme with appendix defined in reference [PKCS1] with the SHA-1 hash function:\nSignature = EQT.SK[‘00’ || ‘01’ || PS || ‘00’ || DER(SHA-1(Data))]\nPS = Padding string of octets with value ‘FF’ such that length is 128.\nDER(SHA-1(M)) is the encoding of the algorithm ID for the hash function and the hash value into an ASN.1 value of type DigestInfo (distinguished encoding rules):\n‘30’||‘21’||‘30’||‘09’||‘06’||‘05’||‘2B’||‘0E’||‘03’||‘02’||‘1A’||‘05’||‘00’||‘04’||‘14’||Hash Value.\n6.2.\nSignature verification\nCSM_035\nData signature verification on downloaded data shall follow the signature scheme with appendix defined in reference [PKCS1] with the SHA-1 hash function.\nThe European public key EUR.PK needs to be known independently (and trusted) by the verifier.\nThe following table illustrates the protocol an IDE carrying a Control card can follow to verify the integrity of data downloaded and stored on the ESM (External Storage media). The control card is used to perform the decipherement of digital signatures. This function may in this case not be implemented in the IDE.\nThe equipment that has downloaded and signed the data to be analysed is denoted EQT.\nPART B\nSECOND-GENERATION TACHOGRAPH SYSTEM\n7.\nINTRODUCTION\n7.1.\nReferences\nThe following references are used in this part of this Appendix.\nAESNational Institute of Standards and Technology (NIST), FIPS PUB 197: Advanced Encryption Standard (AES), November 26, 2001\nDSSNational Institute of Standards and Technology (NIST), FIPS PUB 186-4: Digital Signature Standard (DSS), July 2013\nISO 7816-4ISO/IEC 7816-4, Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange. Third edition 2013-04-15\nISO 7816-8ISO/IEC 7816-8, Identification cards — Integrated circuit cards — Part 8: Commands for security operations. Second edition 2004-06-01\nISO 8825-1ISO/IEC 8825-1, Information technology — ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). Fourth edition, 2008-12-15\nISO 9797-1ISO/IEC 9797-1, Information technology — Security techniques — Message Authentication Codes (MACs) — Part 1: Mechanisms using a block cipher. Second edition, 2011-03-01\nISO 10116ISO/IEC 10116, Information technology — Security techniques — Modes of operation of an n-bit block cipher. Third edition, 2006-02-01\nISO 16844-3ISO/IEC 16844-3, Road vehicles — Tachograph systems — Part 3: Motion sensor interface. First edition 2004, including Technical Corrigendum 1 2006\nRFC 5480Elliptic Curve Cryptography Subject Public Key Information, March 2009\nRFC 5639Elliptic Curve Cryptography (ECC) — Brainpool Standard Curves and Curve Generation, 2010\nRFC 5869HMAC-based Extract-and-Expand Key Derivation Function (HKDF), May 2010\nSHSNational Institute of Standards and Technology (NIST), FIPS PUB 180-4: Secure Hash Standard, March 2012\nSP 800-38BNational Institute of Standards and Technology (NIST), Special Publication 800-38B: Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication, 2005\nTR-03111BSI Technical Guideline TR-03111, Elliptic Curve Cryptography, version 2.00, 2012-06-28\n7.2.\nNotations and Abbreviations\nThe following notations and abbreviated terms are used in this Appendix:\nAESAdvanced Encryption Standard\nCACertificate Authority\nCARCertificate Authority Reference\nCBCCipher Block Chaining (mode of operation)\nCHCommand Header\nCHACertificate Holder Authorisation\nCHRCertificate Holder Reference\nCVConstant Vector\nDERDistinguished Encoding Rules\nDOData Object\nDSRCDedicated Short Range Communication\nECCElliptic Curve Cryptography\nECDSAElliptic Curve Digital Signature Algorithm\nECDHElliptic Curve Diffie-Hellman (key agreement algorithm)\nEGFExternal GNSS Facility\nEQTEquipment\nIDEIntelligent Dedicated Equipment\nKM Motion Sensor Master Key, allowing the pairing of a Vehicle Unit to a Motion Sensor\nKM-VU Key inserted in vehicle units, allowing a VU to derive the Motion Sensor Master Key if a workshop card is inserted into the VU\nKM-WC Key inserted in workshop cards, allowing a VU to derive the Motion Sensor Master Key if a workshop card is inserted into the VU\nMACMessage Authentication Code\nMoSMotion Sensor\nMSBMost Significant Bit\nPKIPublic Key Infrastructure\nRCFRemote Communication Facility\nSSCSend Sequence Counter\nSMSecure Messaging\nTDESTriple Data Encryption Standard\nTLVTag Length Value\nVUVehicle Unit\nX.Cthe public key certificate of user X\nX.CAthe certificate authority that issued the certificate of user X\nX.CARthe certificate authority reference mentioned in the certificate of user X\nX.CHRthe certificate holder reference mentioned in the certificate of user X\nX.PKpublic key of user X\nX.SKprivate key of user X\nX.PKeph ephemeral public key of user X\nX.SKeph ephemeral private key of user X\n‘xx’a hexadecimal value\n||concatenation operator\n7.3.\nDefinitions\nThe definitions of terms used in this Appendix are included in section I of Annex 1C.\n8.\nCRYPTOGRAPHIC SYSTEMS AND ALGORITHMS\n8.1.\nCryptographic Systems\nCSM_38\nVehicle units and tachograph cards shall use an elliptic curve-based public-key cryptographic system to provide the following security services:\nmutual authentication between a vehicle unit and a card,\nagreement of AES session keys between a vehicle unit and a card,\nensuring the authenticity, integrity and non-repudiation of data downloaded from vehicle units or tachograph cards to external media.\nCSM_39\nVehicle units and external GNSS facilities shall use an elliptic curve-based public-key cryptographic system to provide the following security services:\ncoupling of a vehicle unit and an external GNSS facility,\nmutual authentication between a vehicle unit and an external GNSS facility,\nagreement of an AES session key between a vehicle unit and an external GNSS facility.\nCSM_40\nVehicle units and tachograph cards shall use an AES-based symmetric cryptographic system to provide the following security services:\nensuring authenticity and integrity of data exchanged between a vehicle unit and a tachograph card,\nwhere applicable, ensuring confidentiality of data exchanged between a vehicle unit and a tachograph card.\nCSM_41\nVehicle units and external GNSS facilities shall use an AES-based symmetric cryptographic system to provide the following security services:\nensuring authenticity and integrity of data exchanged between a vehicle unit and an external GNSS facility.\nCSM_42\nVehicle units and motion sensors shall use an AES-based symmetric cryptographic system to provide the following security services:\npairing of a vehicle unit and a motion sensor,\nmutual authentication between a vehicle unit and a motion sensor,\nensuring confidentiality of data exchanged between a vehicle unit and a motion sensor.\nCSM_43\nVehicle units and control cards shall use an AES-based symmetric cryptographic system to provide the following security services on the remote communication interface:\nensuring confidentiality, authenticity and integrity of data transmitted from a vehicle unit to a control card.\nNotes:\n—\nProperly speaking, data is transmitted from a vehicle unit to a remote interrogator under the control of a control officer, using a remote communication facility that may be internal or external to the VU, see Appendix 14. However, the remote interrogator sends the received data to a control card for decryption and validation of authenticity. From a security point of view, the remote communication facility and the remote interrogator are fully transparent.\n—\nA workshop card offers the same security services for the DSRC interface as a control card does. This allows a workshop to validate the proper functioning of the remote communication interface of a VU, including security. Please refer to section 9.2.2 for more information.\n8.2.\nCryptographic Algorithms\n8.2.1\nSymmetric Algorithms\nCSM_44\nVehicle units, tachograph cards, motion sensors and external GNSS facilities shall support the AES algorithm as defined in [AES], with key lengths of 128, 192 and 256 bits.\n8.2.2\nAsymmetric Algorithms and Standardized Domain Parameters\nCSM_45\nVehicle units, tachograph cards and external GNSS facilities shall support elliptic curve cryptography with a key size of 256, 384 and 512/521 bits.\nCSM_46\nVehicle units, tachograph cards and external GNSS facilities shall support the ECDSA signing algorithm, as specified in [DSS].\nCSM_47\nVehicle units, tachograph cards and external GNSS facilities shall support the ECKA-EG key agreement algorithm, as specified in [TR 03111].\nCSM_48\nVehicle units, tachograph cards and external GNSS facilities shall support all standardized domain parameters specified in Table 1 below for elliptic curve cryptography.\nTable 1\nStandardized domain parameters\nName\nSize (bits)\nReference\nObject identifier\nNIST P-256\n256\n[DSS], [RFC 5480]\nBrainpoolP256r1\n256\n[RFC 5639]\nNIST P-384\n384\n[DSS], [RFC 5480]\nBrainpoolP384r1\n384\n[RFC 5639]\nBrainpoolP512r1\n512\n[RFC 5639]\nNIST P-521\n521\n[DSS], [RFC 5480]\nNote: the object identifiers mentioned in the last column of Table 1 are specified in [RFC 5639] for the Brainpool curves and in [RFC 5480] for the NIST curves.\n8.2.3\nHashing algorithms\nCSM_49\nVehicle units, tachograph cards and external GNSS facilities shall support the SHA-256, SHA-384 and SHA-512 algorithms specified in [SHS].\n8.2.4\nCipher Suites\nCSM_50\nIn case a symmetric algorithm, an asymmetric algorithm and/or a hashing algorithm are used together to form a security protocol, their respective key lengths and hash sizes shall be of (roughly) equal strength. Table 2 shows the allowed cipher suites:\nTable 2\nAllowed cipher suites\nCipher suite Id\nECC key size (bits)\nAES key length (bits)\nHashing algorithm\nMAC length (bytes)\nCS#1\n256\n128\nSHA-256\n8\nCS#2\n384\n192\nSHA-384\n12\nCS#3\n512/521\n256\nSHA-512\n16\nNote: ECC keys sizes of 512 bits and 521 bits are considered to be equal in strength for all purposes within this Appendix.\n9.\nKEYS AND CERTIFICATES\n9.1.\nAsymmetric Key Pairs and Public Key Certificates\n9.1.1\nGeneral\nNote: the keys described in this section are used for mutual authentication and secure messaging between vehicle units and tachograph cards and between vehicle units and external GNSS facilities. These processes are described in detail in chapters 10 and 11 of this Appendix.\nCSM_51\nWithin the European Smart Tachograph system, ECC key pairs and corresponding certificates shall be generated and managed through three functional hierarchical levels:\nEuropean level,\nMember State level,\nEquipment level.\nCSM_52\nWithin the entire European Smart Tachograph system, public and private keys and certificates shall be generated, managed and communicated using standardized and secure methods.\n9.1.2\nEuropean Level\nCSM_53\nAt European level, a single unique ECC key pair designated as EUR shall be generated. It shall consist of a private key (EUR.SK) and a public key (EUR.PK). This key pair shall form the root key pair of the entire European Smart Tachograph PKI. This task shall be handled by a European Root Certificate Authority (ERCA), under the authority and responsibility of the European Commission.\nCSM_54\nThe ERCA shall use the European private key to sign a (self-signed) root certificate of the European public key, and shall communicate this European root certificate to all Member States.\nCSM_55\nThe ERCA shall use the European private key to sign the certificates of the Member States public keys upon request. The ERCA shall keep records of all signed Member State public key certificates.\nCSM_56\nAs shown in Figure 1 in section 9.1.7, the ERCA shall generate a new European root key pair every 17 years. Whenever the ERCA generates a new European root key pair, it shall create a new self-signed root certificate for the new European public key. The validity period of a European root certificate shall be 34 years plus 3 months.\nNote: The introduction of a new root key pair also implies that ERCA will generate a new motion sensor master key and a new DSRC master key, see sections 9.2.1.2 and 9.2.2.2.\nCSM_57\nBefore generating a new European root key pair, the ERCA shall conduct an analysis of the cryptographic strength that is needed for the new key pair, given it should stay secure for the next 34 years. If found necessary, the ERCA shall switch to a cipher suite that is stronger than the current one, as specified in CSM_50.\nCSM_58\nWhenever 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.\nNote: Since a link certificate contains the ERCA generation X public key and is signed with the ERCA generation X-1 private key, a link certificate offers equipment issued under generation X-1 a method to trust equipment issued under generation X.\nCSM_59\nThe ERCA shall not use the private key of a root key pair for any purpose after the moment a new root key certificate becomes valid.\nCSM_60\nAt any moment in time, the ERCA shall dispose of the following cryptographic keys and certificates:\nThe current EUR key pair and corresponding certificate\nAll previous EUR certificates to be used for the verification of MSCA certificates that are still valid\nLink certificates for all generations of EUR certificates except the first one\n9.1.3\nMember State Level\nCSM_61\nAt Member State level, all Member States required to sign tachograph card certificates shall generate one or more unique ECC key pairs designated as MSCA_Card. All Member States required to sign certificates for vehicle units or external GNSS facilities shall additionally generate one or more unique ECC key pairs designated as MSCA_VU-EGF.\nCSM_62\nThe task of generating Member State key pairs shall be handled by a Member State Certificate Authority (MSCA). Whenever a MSCA generates a Member State key pair, it shall send the public key to the ERCA in order to obtain a corresponding Member State certificate signed by the ERCA.\nCSM_63\nAn MSCA shall choose the strength of a Member State key pair equal to the strength of the European root key pair used to sign the corresponding Member State certificate.\nCSM_64\nAn MSCA_VU-EGF key pair, if present, shall consist of private key MSCA_VU-EGF.SK and public key MSCA_VU-EGF.PK. An MSCA shall use the MSCA_VU-EGF.SK private key exclusively to sign the public key certificates of vehicle units and external GNSS facilities.\nCSM_65\nAn MSCA_Card key pair shall consist of private key MSCA_Card.SK and public key MSCA_Card.PK. An MSCA shall use the MSCA_Card.SK private key exclusively to sign the public key certificates of tachograph cards.\nCSM_66\nAn MSCA shall keep records of all signed VU certificates, external GNSS facility certificates and card certificates, together with the identification of the equipment for which each certificate is intended.\nCSM_67\nThe validity period of an MSCA_VU-EGF certificate shall be 17 years plus 3 months. The validity period of an MSCA_Card certificate shall be 7 years plus 1 month.\nCSM_68\nAs shown in Figure 1 in section 9.1.7, the private key of a MSCA_VU-EGF key pair and the private key of a MSCA_Card key pair shall have a key usage period of two years.\nCSM_69\nAn MSCA shall not use the private key of an MSCA_VU-EGF key pair for any purpose after the moment its usage period has ended. Neither shall an MSCA use the private key of an MSCA_Card key pair for any purpose after the moment its usage period has ended.\nCSM_70\nAt any moment in time, an MSCA shall dispose of the following cryptographic keys and certificates:\nThe current MSCA_Card key pair and corresponding certificate\nAll previous MSCA_Card certificates to be used for the verification of the certificates of tachograph cards that are still valid\nThe current EUR certificate necessary for the verification of the current MSCA certificate\nAll previous EUR certificates necessary for the verification of all MSCA certificates that are still valid\nCSM_71\nIf an MSCA is required to sign certificates for vehicle units or external GNSS facilities, it shall additionally dispose of the following keys and certificates:\nThe current MSCA_VU-EGF key pair and corresponding certificate\nAll previous MSCA_VU-EGF public keys to be used for the verification of the certificates of VUs or external GNSS facilities that are still valid\n9.1.4\nEquipment Level: Vehicle Units\nCSM_72\nTwo 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.\nCSM_73\nThe VU_MA and VU_Sign certificates of a given vehicle unit shall have the same Certificate Effective Date.\nCSM_74\nA VU manufacturer shall choose the strength of a VU key pair equal to the strength of the MSCA key pair used to sign the corresponding VU certificate.\nCSM_75\nA vehicle unit shall use its VU_MA key pair, consisting of private key VU_MA.SK and public key VU_MA.PK, exclusively to perform VU Authentication towards tachograph cards and external GNSS facilities, as specified in sections 10.3 and 11.4 of this Appendix.\nCSM_76\nA vehicle unit shall be capable of generating ephemeral ECC key pairs and shall use an ephemeral key pair exclusively to perform session key agreement with a tachograph card or external GNSS facility, as specified in sections 10.4 and 11.4 of this Appendix.\nCSM_77\nA vehicle unit shall use the private key VU_Sign.SK of its VU_Sign key pair exclusively to sign downloaded data files, as specified in chapter 14 of this Appendix. The corresponding public key VU_Sign.PK shall be used exclusively to verify signatures created by the vehicle unit.\nCSM_78\nAs shown in Figure 1 in section 9.1.7, the validity period of a VU_MA certificate shall be 15 years and 3 months. The validity period of a VU_Sign certificate shall also be 15 years and 3 months.\nNotes:\n—\nThe extended validity period of a VU_Sign certificate allows a Vehicle Unit to create valid signatures over downloaded data during the first three months after it has expired, as required in Regulation (EU) No 581/2010.\n—\nThe extended validity period of a VU_MA certificate is needed to allow the VU to authenticate to a control card or a company card during the first three months after it has expired, such that is it possible to perform a data download.\nCSM_79\nA vehicle unit shall not use the private key of a VU key pair for any purpose after the corresponding certificate has expired.\nCSM_80\nThe VU key pairs (except ephemeral keys pairs) and corresponding certificates of a given vehicle unit shall not be replaced or renewed in the field once the vehicle unit has been put in operation.\nNotes:\n—\nEphemeral key pairs are not included in this requirement, as a new ephemeral key pair is generated by a VU each time Chip Authentication and session key agreement is performed, see section 10.4. Note that ephemeral key pairs do not have corresponding certificates.\n—\nThis requirement does not forbid the possibility of replacing static VU key pairs during a refurbishment or repair in a secure environment controlled by the VU manufacturer.\nCSM_81\nWhen put in operation, vehicle units shall contain the following cryptographic keys and certificates:\nThe VU_MA private key and corresponding certificate\nThe VU_Sign private key and corresponding certificate\nThe MSCA_VU-EGF certificate containing the MSCA_VU-EGF.PK public key to be used for verification of the VU_MA certificate and VU_Sign certificate\nThe EUR certificate containing the EUR.PK public key to be used for verification of the MSCA_VU-EGF certificate\nThe 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\nThe link certificate linking these two EUR certificates, if existing\nCSM_82\nIn addition to the cryptographic keys and certificates listed in CSM_81, vehicle units shall also contain the keys and certificates specified in Part A of this Appendix, allowing a vehicle unit to interact with first-generation tachograph cards.\n9.1.5\nEquipment Level: Tachograph Cards\nCSM_83\nOne 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.\nCSM_84\nThe Card_MA and Card_Sign certificates of a given driver card or workshop card shall have the same Certificate Effective Date.\nCSM_85\nA card manufacturer or card personaliser shall choose the strength of a card key pair equal to the strength of the MSCA key pair used to sign the corresponding card certificate.\nCSM_86\nA tachograph card shall use its Card_MA key pair, consisting of private key Card_MA.SK and public key Card_MA.PK, exclusively to perform mutual authentication and session key agreement towards vehicle units, as specified in sections 10.3 and 10.4 of this Appendix.\nCSM_87\nA driver card or workshop card shall use the private key Card_Sign.SK of its Card_Sign key pair exclusively to sign downloaded data files, as specified in chapter 14 of this Appendix. The corresponding public key Card_Sign.PK shall be used exclusively to verify signatures created by the card.\nCSM_88\nThe validity period of a Card_MA certificate shall be as follows:\nFor driver cards: 5 years\nFor company cards: 5 years\nFor control cards: 2 years\nFor workshop cards: 1 year\nCSM_89\nThe validity period of a Card_Sign certificate shall be as follows:\n—\nFor driver cards:\n5 years and 1 month\n—\nFor workshop cards:\n1 year and 1 month\nNote: the extended validity period of a Card_Sign certificate allows a driver card to create valid signatures over downloaded data during the first month after it has expired. This is necessary in view of Regulation (EU) No 581/2010, which requires that a data download from a driver card must be possible up to 28 days after the last data has been recorded.\nCSM_90\nThe key pairs and corresponding certificates of a given tachograph card shall not be replaced or renewed once the card has been issued.\nCSM_91\nWhen issued, tachograph cards shall contain the following cryptographic keys and certificates:\nThe Card_MA private key and corresponding certificate\nFor driver cards and workshop cards additionally: the Card_Sign private key and corresponding certificate\nThe MSCA_Card certificate containing the MSCA_Card.PK public key to be used for verification of the Card_MA certificate and Card_Sign certificate\nThe EUR certificate containing the EUR.PK public key to be used for verification of the MSCA_Card certificate.\nThe EUR certificate whose validity period directly precedes the validity period of the EUR certificate to be used to verify the MSCA_Card certificate, if existing.\nThe link certificate linking these two EUR certificates, if existing.\nAdditionally, 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.\nNote 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.\nCSM_92\nIn addition to the cryptographic keys and certificates listed in CSM_91, tachograph cards shall also contain the keys and certificates specified in Part A of this Appendix, allowing these cards to interact with first-generation VUs.\n9.1.6\nEquipment Level: External GNSS Facilities\nCSM_93\nOne 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.\nCSM_94\nAn EGF manufacturer shall choose the strength of an EGF_MA key pair equal to the strength of the MSCA key pair used to sign the corresponding EGF_MA certificate.\nCSM_95\nAn 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.\nCSM_96\nThe validity period of an EGF_MA certificate shall be 15 years.\nCSM_97\nAn external GNSS facility shall not use the private key of its EGF_MA key pair for coupling to a vehicle unit after the corresponding certificate has expired.\nNote: as explained in section 11.3.3, an EGF may potentially use its private key for mutual authentication towards the VU it is already coupled to, even after the corresponding certificate has expired.\nCSM_98\nThe EGF_MA key pair and corresponding certificate of a given external GNSS facility shall not be replaced or renewed in the field once the EGF has been put in operation.\nNote: This requirement does not forbid the possibility of replacing EGF key pairs during a refurbishment or repair in a secure environment controlled by the EGF manufacturer.\nCSM_99\nWhen put in operation, an external GNSS facility shall contain the following cryptographic keys and certificates:\nThe EGF_MA private key and corresponding certificate\nThe MSCA_VU-EGF certificate containing the MSCA_VU-EGF.PK public key to be used for verification of the EGF_MA certificate\nThe EUR certificate containing the EUR.PK public key to be used for verification of the MSCA_VU-EGF certificate\nThe 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\nThe link certificate linking these two EUR certificates, if existing\n9.1.7\nOverview: Certificate Replacement\nFigure 1 below shows how different generations of ERCA root certificates, ERCA link certificates, MSCA certificates and equipment (VU and card) certificates are issued and used over time:\nFigure 1\nIssuance and usage of different generations of ERCA root certificates, ERCA link certificates, MSCA certificates and equipment certificates\nNotes to Figure 1:\n1.\nDifferent generations of the root certificate are indicated by a number in brackets. E.g. ERCA (1) is the first generation of ERCA root certificate; ERCA (2) is the second generation, etc.\n2.\nOther certificates are indicated by two numbers in brackets, the first one indicating the root certificate generation under which they are issued, the second one the generation of the certificate itself. E.g. MSCA_Card (1-1) is the first MSCA_Card certificate issued under ERCA (1); MSCA_Card (2-1) is the first MSCA_Card certificate issued under ERCA (2); MSCA_Card (2-last) is the last MSCA_Card certificate issued under ERCA (2); Card_MA(2-1) is the first Card certificate for mutual authentication that is issued under ERCA (2), etc.\n3.\nThe MSCA_Card (2-1) and MSCA_Card (1-last) certificates are issued at almost but not exactly the same date. MSCA_Card (2-1) is the first MSCA_Card certificate issued under ERCA (2) and will be issued slightly later than MSCA_Card (1-last), the last MSCA_Card certificate under ERCA (1).\n4.\nAs shown in the figure, the first VU and Card certificates issued under ERCA (2) will appear almost two years before the last VU and Card certificates issued under ERCA (1) will appear. This is because of the fact that VU and Card certificates are issued under an MSCA certificate, not directly under the ERCA certificate. The MSCA (2-1) certificate will be issued directly after ERCA (2) becomes valid, but the MSCA (1-last) certificate will be issued only slightly before that time, at the last moment the ERCA (1) certificate is still valid. Therefore, these two MSCA certificates will have almost the same validity period, despite the fact that they are of different generations.\n5.\nThe validity period shown for cards is the one for driver cards (5 years).\n6.\nTo save space, the difference in validity period between the Card_MA and Card_Sign certificates is shown only for the first generation.\n9.2.\nSymmetric Keys\n9.2.1\nKeys for Securing VU — Motion Sensor Communication\n9.2.1.1\nGeneral\nNote: readers of this section are supposed to be familiar with the contents of [ISO 16844-3] describing the interface between a vehicle unit and a motion sensor. The pairing process between a VU and a motion sensor is described in detail in chapter 12 of this Appendix.\nCSM_100\nA number of symmetric keys is needed for pairing vehicle units and motion sensors, for mutual authentication between vehicle units and motion sensors and for encrypting communication between vehicle units and motion sensors, as shown in Table 3. All of these keys shall be AES keys, with a key length equal to the length of the motion sensor master key, which shall be linked to the length of the (foreseen) European root key pair as described in CSM_50.\nTable 3\nKeys for securing vehicle unit — motion sensor communication\nStorage of KM and KID is optional, as these keys can be derived from KM-VU, KM-WC and CV.\nKey\nSymbol\nGenerated by\nGeneration method\nStored by\nMotion Sensor Master Key — VU part\nKM-VU\nERCA\nRandom\nERCA, MSCAs involved in issuing VUs certificates, VU manufacturers, vehicle units\nMotion Sensor Master Key — Workshop part\nKM-WC\nERCA\nRandom\nERCA, MSCAs, card manufacturers, workshop cards\nMotion Sensor Master Key\nKM\nNot independently generated\nCalculated as KM = KM-VU XOR KM-WC\nERCA, MSCAs involved in issuing motion sensors keys (optionally)\nIdentification Key\nKID\nNot independently generated\nCalculated as KID = KM XOR CV, where CV is specified in CSM_106\nERCA, MSCAs involved in issuing motion sensors keys (optionally)\nPairing Key\nKP\nMotion sensor manufacturer\nRandom\nOne motion sensor\nSession Key\nKS\nVU (during pairing of VU and motion sensor)\nRandom\nOne VU and one motion sensor\nCSM_101\nThe European Root Certificate Authority shall generate KM-VU and KM-WC, two random and unique AES keys from which the motion sensor master key KM can be calculated as KM-VU XOR KM-WC. The ERCA shall communicate KM, KM-VU and KM-WC to Member State Certificate Authorities upon their request.\nCSM_102\nThe ERCA shall assign to each motion sensor master key KM a unique version number, which shall also be applicable for the constituting keys KM-VU and KM-WC and for the related identification key KID. The ERCA shall inform the MSCAs about the version number when sending KM-VU and KM-WC to them.\nNote: The version number is used to distinguish different generations of these keys, as explained in detail in section 9.2.1.2.\nCSM_103\nA Member State Certificate Authority shall forward KM-VU, together with its version number, to vehicle unit manufacturers upon their request. The VU manufacturers shall insert KM-VU and its version number in all manufactured VUs.\nCSM_104\nA Member State Certificate Authority shall ensure that KM-WC, together with its version number, is inserted in every workshop card issued under its responsibility.\nNotes:\n—\nSee the description of data type in Appendix 2.\n—\nas explained in section 9.2.1.2, in fact multiple generations of KM-WC may have to be inserted in a single workshop card.\nCSM_105\nIn addition to the AES key specified in CSM_104, a MSCA shall ensure that the TDES key KmWC, specified in requirement CSM_037 in Part A of this Appendix, is inserted in every workshop card issued under its responsibility.\nNotes:\n—\nThis allows a second-generation workshop card to be used for coupling a first-generation VU.\n—\nA second-generation workshop card will contain two different applications, one complying with Part B of this Appendix and one complying with Part A. The latter will contain the TDES key KmWC.\nCSM_106\nAn MSCA involved in issuing motion sensors shall derive the identification key from the motion sensor master key by XORing it with a constant vector CV. The value of CV shall be as follows:\nFor 128-bit motion sensor master keys: CV = ‘B6 44 2C 45 0E F8 D3 62 0B 7A 8A 97 91 E4 5D 83’\nFor 192-bit motion sensor master keys: CV = ‘72 AD EA FA 00 BB F4 EE F4 99 15 70 5B 7E EE BB 1C 54 ED 46 8B 0E F8 25’\nFor 256-bit motion sensor master keys: CV = ‘1D 74 DB F0 34 C7 37 2F 65 55 DE D5 DC D1 9A C3 23 D6 A6 25 64 CD BE 2D 42 0D 85 D2 32 63 AD 60’\nNote: the constant vectors have been generated as follows:\nPi_10 = first 10 bytes of the decimal portion of the mathematical constant π = ‘24 3F 6A 88 85 A3 08 D3 13 19’\nCV_128-bits = first 16 bytes of SHA-256(Pi_10)\nCV_192-bits = first 24 bytes of SHA-384(Pi_10)\nCV_256-bits = first 32 bytes of SHA-512(Pi_10)\nCSM_107\nEach Motion sensor manufacturer shall generate a random and unique pairing key K P 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 K M 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 K M .\nNote: as explained in section 9.2.1.2, in fact a motion sensor manufacturer may have to generate multiple unique pairing keys for a single motion sensor.\nCSM_108\nEach 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 K ID 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 K ID .\nCSM_109\nFor requirements CSM_107 and CSM_108, the MSCA shall use the AES algorithm in the Cipher Block Chaining mode of operation, as defined in [ISO 10116], with an interleave parameter m = 1 and an initialization vector SV = ‘00’ {16}, i.e. sixteen bytes with binary value 0. When necessary, the MSCA shall use padding method 2 defined in [ISO 9797-1].\nCSM_110\nThe motion sensor manufacturer shall store the encrypted pairing key and the encrypted serial number in the intended motion sensor, together with the corresponding plain text values and the version number of KM and KID used for encrypting.\nNote: as explained in section 9.2.1.2, in fact a motion sensor manufacturer may have to insert multiple encrypted pairing keys and multiple encrypted serial numbers in a single motion sensor.\nCSM_111\nIn addition to the AES-based cryptographic material specified in CSM_110, a motion sensor manufacturer may also store in each motion sensor the TDES-based cryptographic material specified in requirement CSM_037 in Part A of this Appendix.\nNote: doing so will allow a second-generation motion sensor to be coupled to a first-generation VU.\nCSM_112\nThe length of the session key KS generated by a VU during the pairing to a motion sensor shall be linked to the length of its KM-VU, as described in CSM_50.\n9.2.1.2\nMotion Sensor Master Key Replacement in Second-Generation Equipment\nCSM_113\nEach motion sensor master key and all related keys (see Table 3) is associated to a particular generation of the ERCA root key pair. These keys shall therefore be replaced every 17 years. The validity period of each motion sensor master key generation shall begin one year before the associated ERCA root key pair becomes valid and shall end when the associated ERCA root key pair expires. This is depicted in Figure 2.\nFigure 2\nIssuance and usage of different generations of the motion sensor master key in vehicle units, motions sensors and workshop cards\nCSM_114\nAt least one year before generating a new European root key pair, as described in CSM_56, the ERCA shall generate a new motion sensor master key KM by generating a new KM-VU and KM-WC. The length of the motion sensor master key shall be linked to the foreseen strength of the new European root key pair, according to CSM_50. The ERCA shall communicate the new KM, KM-VU and KM-WC to the MSCAs upon their request, together with their version number.\nCSM_115\nAn MSCA shall ensure that all valid generations of KM-WC are stored in every workshop card issued under its authority, together with their version numbers, as shown in Figure 2.\nNote: this implies that in the last year of the validity period of an ERCA certificate, workshop cards will be issued with three different generations of KM-WC, as shown in Figure 2.\nCSM_116\nIn relation to the process described in CSM_107 and CSM_108 above: An MSCA shall encrypt each pairing key KP it receives from a motion sensor manufacturer separately with each valid generation of the motion sensor master key KM. An MSCA shall also encrypt each serial number it receives from a motion sensor manufacturer separately with each valid generation of the identification key KID. A motion sensor manufacturer shall store all encryptions of the pairing key and all encryptions of the serial number in the intended motion sensor, together with the corresponding plain text values and the version number(s) of KM and KID used for encrypting.\nNote: This implies that in the last year of the validity period of an ERCA certificate, motion sensors will be issued with encrypted data based on three different generations of KM, as shown in Figure 2.\nCSM_117\nIn relation to the process described in CSM_107 above: Since the length of the pairing key KP shall be linked to the length of KM (see CSM_100), a motion sensor manufacturer may have to generate up to three different pairing keys (of different lengths) for one motion sensor, in case subsequent generations of KM have different lengths. In such a case, the manufacturer shall send each pairing key to the MSCA. The MSCA shall ensure that each pairing key is encrypted with the correct generation of the motion sensor master key, i.e. the one having the same length.\nNote: In case the motion sensor manufacturer chooses to generate a TDES-based pairing key for a second-generation motion sensor (see CSM_111), the manufacturer shall indicate to the MSCA that the TDES-based motion sensor master key must be used for encrypting this pairing key. This is because the length of a TDES key may be equal to that of an AES key, so the MSCA cannot judge from the key length alone.\nCSM_118\nVehicle unit manufacturers shall insert only one generation of KM-VU in each vehicle unit, together with its version number. This KM-VU generation shall be linked to the ERCA certificate upon which the VU's certificates are based.\nNotes:\n—\nA vehicle unit based on the generation X ERCA certificate shall only contain the generation X KM-VU, even if it is issued after the start of the validity period of the generation X+1 ERCA certificate. This is shown in Figure 2.\n—\nA VU of generation X cannot be paired to a motion sensor of generation X-1.\n—\nSince workshop cards have a validity period of one year, the result of CSM_113 — CSM_118 is that all workshop cards will contain the new KM-WC at the moment the first VU containing the new KM-VU is issued. Therefore, such a VU will always be able to calculate the new KM. Moreover, by that time most new motion sensors will contain encrypted data based on the new KM as well.\n9.2.2\nKeys for Securing DSRC Communication\n9.2.2.1\nGeneral\nCSM_119\nThe authenticity and confidentiality of data communicated from a vehicle unit to a control authority over a DSRC remote communication channel shall be ensured by means of a set of VU-specific AES keys derived from a single DSRC master key, KMDSRC.\nCSM_120\nThe DSRC master key KMDSRC shall be an AES key that is securely generated, stored and distributed by the ERCA. The key length may be 128, 192 or 256 bits and shall be linked to the length of the European root key pair, as described in CSM_50.\nCSM_121\nThe ERCA shall communicate the DSRC master key to Member State Certificate Authorities upon their request in a secure manner, to allow them to derive VU-specific DSRC keys and to ensure that the DSRC master key is inserted in all control cards and workshop cards issued under their responsibility.\nCSM_122\nThe ERCA shall assign to each DSRC master key a unique version number. The ERCA shall inform the MSCAs about the version number when sending the DSRC master key to them.\nNote: The version number is used to distinguish different generations of the DSRC master key, as explained in detail in section 9.2.2.2.\nCSM_123\nFor 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 .\nNote:\nThis 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.\nThe 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.\nCSM_124\nUpon receiving a request for VU-specific DSRC keys, the MSCA shall derive two AES keys for the vehicle unit, called K_VUDSRC_ENC and K_VUDSRC_MAC. These VU-specific keys shall have the same length as the DSRC master key. The MSCA shall use the key derivation function defined in [RFC 5869]. The hash function that is necessary to instantiate the HMAC-Hash function shall be linked to the length of the DSRC master key, as described in CSM_50. The key derivation function in [RFC 5869] shall be used as follows:\nStep 1 (Extract):\nPRK = HMAC-Hash (salt, IKM) where salt is an empty string ‘’ and IKM is KMDSRC.\nStep 2 (Expand):\nOKM = T(1), where\nT(1) = HMAC-Hash (PRK, T(0) || info || ‘01’) with\nT(0) = an empty string (‘’)\ninfo = VU serial number or certificate request ID, as specified in CSM_123\nK_VUDSRC_ENC = first L octets of OKM and\nK_VUDSRC_MAC = last L octets of OKM\nwhere L is the required length of K_VUDSRC_ENC and K_VUDSRC_MAC in octets.\nCSM_125\nThe MSCA shall distribute K_VUDSRC_ENC and K_VUDSRC_MAC to the VU manufacturer in a secure manner for insertion in the intended vehicle unit.\nCSM_126\nWhen issued, a vehicle unit shall have stored K_VUDSRC_ENC and K_VUDSRC_MAC in its secure memory, in order to be able to ensure the integrity, authenticity and confidentiality of data sent over the remote communication channel. A vehicle unit shall also store the version number of the DSRC master key used to derive these VU-specific keys.\nCSM_127\nWhen issued, control cards and workshop cards shall have stored KMDSRC in their secure memory, in order to be able to verify the integrity and authenticity of data sent by a VU over the remote communication channel and to decrypt this data. Control cards and workshop cards shall also store the version number of the DSRC master key.\nNote: as explained in section 9.2.2.2, in fact multiple generations of KMDSRC may have to be inserted in a single workshop card or control card.\nCSM_128\nThe 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.\n9.2.2.2\nDSRC Master Key Replacement\nCSM_129\nEach DSRC master key is associated to a particular generation of the ERCA root key pair. The ERCA shall therefore replace the DSRC master key every 17 years. The validity period of each DSRC master key generation shall begin two years before the associated ERCA root key pair becomes valid and shall end when the associated ERCA root key pair expires. This is depicted in Figure 3.\nFigure 3\nIssuance and usage of different generations of the DSRC master key in vehicle units, workshop cards and control cards\nCSM_130\nAt least two years before generating a new European root key pair, as described in CSM_56, the ERCA shall generate a new DSRC master key. The length of the DSRC key shall be linked to the foreseen strength of the new European root key pair, according to CSM_50. The ERCA shall communicate the new DSRC master key to the MSCAs upon their request, together with its version number.\nCSM_131\nAn MSCA shall ensure that all valid generations of KMDSRC are stored in every control card issued under its authority, together with their version numbers, as shown in Figure 3.\nNote: this implies that in the last two years of the validity period of an ERCA certificate, control cards will be issued with three different generations of KMDSRC, as shown in Figure 3.\nCSM_132\nAn MSCA shall ensure that all generations of KMDSRC that have been valid for at least a year and are still valid, are stored in every workshop card issued under its authority, together with their version numbers, as shown in Figure 3.\nNote: this implies that in the last year of the validity period of an ERCA certificate, workshop cards will be issued with three different generations of KMDSRC, as shown in Figure 3.\nCSM_133\nVehicle unit manufacturers shall insert only one set of VU-specific DSRC keys into each vehicle unit, together with its version number. This set of keys shall be derived from the KMDSRC generation linked to the ERCA certificate upon which the VU's certificates are based.\nNotes:\n—\nThis implies that a vehicle unit based on the generation X ERCA certificate shall only contain the generation X K_VUDSRC_ENC and K_VUDSRC_MAC, even if the VU is issued after the start of the validity period of the generation X+1 ERCA certificate. This is shown in Figure 3.\n—\nSince workshop cards have a validity period of one year and control cards of two years, the result of CSM_131 — CSM_133 is that all workshop cards and control cards will contain the new DSRC master key at the moment the first VU containing VU-specific keys based on that master key will be issued.\n9.3.\nCertificates\n9.3.1\nGeneral\nCSM_134\nAll certificates in the European Smart Tachograph system shall be self-descriptive, card-verifiable (CV) certificates according to [ISO 7816-4] and [ISO 7816-8].\nCSM_135\nThe 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.\nNote: this encoding results in a Tag-Length-Value (TLV) structure as follows:\nTagThe tag is encoded in one or two octets and indicates the content.\nLengthThe 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.\nValueThe value is encoded in zero or more octets\n9.3.2\nCertificate Content\nCSM_136\nAll certificates shall have the structure shown in the certificate profile in Table 4.\nTable 4\nCertificate Profile version 1\nField\nField ID\nTag\nLength (bytes)\nASN.1 data type(see Appendix 1)\nECC Certificate\nC\n‘7F 21’\nvar\nECC Certificate Body\nB\n‘7F 4E’\nvar\nCertificate Profile Identifier\nCPI\n‘5F 29’\n‘01’\nCertificate Authority Reference\nCAR\n‘42’\n‘08’\nCertificate Holder Authorisation\nCHA\n‘5F 4C’\n‘07’\nPublic Key\nPK\n‘7F 49’\nvar\nDomain Parameters\nDP\n‘06’\nvar\nPublic Point\nPP\n‘86’\nvar\nCertificate Holder Reference\nCHR\n‘5F 20’\n‘08’\nCertificate Effective Date\nCEfD\n‘5F 25’\n‘04’\nCertificate Expiration Date\nCExD\n‘5F 24’\n‘04’\nECC Certificate Signature\nS\n‘5F 37’\nvar\nNote: the Field ID will be used in later sections of this Appendix to indicate individual fields of a certificate, e.g. X.CAR is the Certificate Authority Reference mentioned in the certificate of user X.\n9.3.2.1\nCertificate Profile Identifier\nCSM_137\nCertificates shall use a Certificate Profile Identifier to indicate the certificate profile used. Version 1, as specified in Table 4, shall be identified by a value of ‘00’.\n9.3.2.2\nCertificate Authority Reference\nCSM_138\nThe Certificate Authority Reference shall be used to identify the public key to be used to verify the certificate signature. The Certificate Authority Reference shall therefore be equal to the Certificate Holder Reference in the certificate of the corresponding certificate authority.\nCSM_139\nAn ERCA root certificate shall be self-signed, i.e., the Certificate Authority Reference and the Certificate Holder Reference in the certificate shall be equal.\nCSM_140\nFor an ERCA link certificate, the Certificate Holder Reference shall be equal to the CHR of the new ERCA root certificate. The Certificate Authority Reference for a link certificate shall be equal to the CHR of the previous ERCA root certificate.\n9.3.2.3\nCertificate Holder Authorisation\nCSM_141\nThe 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).\n9.3.2.4\nPublic Key\nThe Public Key nests two data elements: the standardized domain parameters to be used with the public key in the certificate and the value of the public point.\nCSM_142\nThe data element Domain Parameters shall contain one of the object identifiers specified in Table 1 to reference a set of standardized domain parameters.\nCSM_143\nThe data element Public Point shall contain the public point. Elliptic curve public points shall be converted to octet strings as specified in [TR-03111]. The uncompressed encoding format shall be used. When recovering an elliptic curve point from its encoded format, the validations described in [TR-03111] shall always be carried out.\n9.3.2.5\nCertificate Holder Reference\nCSM_144\nThe Certificate Holder Reference is an identifier for the public key provided in the certificate. It shall be used to reference this public key in other certificates.\nCSM_145\nFor card certificates and external GNSS facility certificates, the Certificate Holder Reference shall have the data type specified in Appendix 1.\nCSM_146\nFor vehicle units, the manufacturer, when requesting a certificate, may or may not know the manufacturer-specific serial number of the VU for which that certificate and the associated private key is intended. In the first case, the Certificate Holder Reference shall have the data type specified in Appendix 1. In the latter case, the Certificate Holder Reference shall have the data type specified in Appendix 1.\nNote: 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.\nCSM_147\nFor ERCA and MSCA certificates, the Certificate Holder Reference shall have the data type specified in Appendix 1.\n9.3.2.6\nCertificate Effective Date\nCSM_148\nThe Certificate Effective Date shall indicate the starting date and time of the validity period of the certificate.\n9.3.2.7\nCertificate Expiration Date\nCSM_149\nThe Certificate Expiration Date shall indicate the end date and time of the validity period of the certificate.\n9.3.2.8\nCertificate Signature\nCSM_150\nThe signature on the certificate shall be created over the encoded certificate body, including the certificate body tag and length. The signature algorithm shall be ECDSA, as specified in [DSS], using the hashing algorithm linked to the key size of the signing authority, as specified in CSM_50. The signature format shall be plain, as specified in [TR-03111].\n9.3.3\nRequesting Certificates\nCSM_151\nWhen requesting a certificate, an MSCA shall send the following data to the ERCA:\nThe Certificate Profile Identifier of the requested certificate\nThe Certificate Authority Reference expected to be used for signing the certificate.\nThe Public Key to be signed\nCSM_152\nIn addition to the data in CSM_151, an MSCA shall send the following data in a certificate request to the ERCA, allowing the ERCA to create the Certificate Holder Reference of the new MSCA certificate:\nThe numerical nation code of the Certification Authority (data type defined in Appendix 1)\nThe alphanumerical nation code of the Certification Authority (data type defined in Appendix 1)\nThe 1-byte serial number to distinguish the different keys of the Certification Authority in the case keys are changed\nThe two-byte field containing Certification Authority specific additional info\nCSM_153\nAn 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:\nIf 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.\nThe month and the year of equipment manufacturing or of the certificate request.\nThe manufacturer shall ensure that this data is correct and that the certificate returned by the MSCA is inserted in the intended equipment.\nCSM_154\nIn the case of a VU, the manufacturer, when requesting a certificate, may or may not know the manufacturer-specific serial number of the VU for which that certificate and the associated private key is intended. If known, the VU manufacturer shall send the serial number to the MSCA. If not known, the manufacturer shall uniquely identify each certificate request and send this certificate request serial number to the MSCA. The resulting certificate will then contain the certificate request serial number. After inserting the certificate in a specific VU, the manufacturer shall communicate the connection between the certificate request serial number and the VU identification to the MSCA.\n10.\nVU- CARD MUTUAL AUTHENTICATION AND SECURE MESSAGING\n10.1.\nGeneral\nCSM_155\nOn a high level, secure communication between a vehicle unit and a tachograph card shall be based on the following steps:\nFirst, 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\nSecond, 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.\nThird, 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.\nFourth, 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.\nCSM_156\nThe mechanism described in CSM_155 shall be triggered by the vehicle unit whenever a card is inserted into one of its card slots.\n10.2.\nMutual Certificate Chain Verification\n10.2.1\nCard Certificate Chain Verification by VU\nCSM_157\nVehicle 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:\nThe CHA field of the Card certificate shall indicate a card certificate for mutual authentication (see Appendix 1, data type EquipmentType).\nThe CHA of the Card.CA certificate shall indicate an MSCA.\nThe CHA of the Card.Link certificate shall indicate the ERCA.\nNotes to Figure 4:\n—\nThe Card certificates and public keys mentioned in the figure are those for mutual authentication. Section 9.1.5 denotes these as Card_MA.\n—\nThe Card.CA certificates and public keys mentioned in the figure are those for signing card certificates and it is indicated in the CAR of the Card certificate. Section 9.1.3 denotes these as MSCA_Card.\n—\nThe Card.CA.EUR certificate mentioned in the figure is the European root certificate that is indicated in the CAR of the Card.CA certificate.\n—\nThe Card.Link certificate mentioned in the figure is the card's link certificate, if present. As specified in section 9.1.2, this is a link certificate for a new European root key pair created by the ERCA and signed by the previous European private key.\n—\nThe Card.Link.EUR certificate is the European root certificate that is indicated in the CAR of the Card.Link certificate.\nCSM_158\nAs depicted in Figure 4, verification of the card's certificate chain shall begin upon card insertion. The vehicle unit shall read the card holder reference () from EF ICC. The VU shall check if it knows the card, i.e., if it has successfully verified the card's certificate chain in the past and stored it for future reference. If it does, and the card certificate is still valid, the process continues with the verification of the VU certificate chain. Otherwise, the VU shall successively read from the card the MSCA_Card certificate to be used for verifying the card certificate, the Card.CA. EUR certificate to be used for verifying the MSCA_Card certificate, and possibly the link certificate, until it finds a certificate it knows or it can verify. If such a certificate is found, the VU shall use that certificate to verify the underlying card certificates it has read from the card. If successful, the process continues with the verification of the VU certificate chain. If not successful, the VU shall ignore the card.\nNote: There are three ways in which the VU may know the Card.CA.EUR certificate:\nthe Card.CA.EUR certificate is the same certificate as the VU's own EUR certificate;\nthe Card.CA.EUR certificate precedes the VU's own EUR certificate and the VU contained this certificate already at issuance (see CSM_81);\nthe 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.\nCSM_159\nAs indicated in Figure 4, once the VU has verified the authenticity and validity of a previously unknown certificate, it may store this certificate for future reference, such that it does not need to verify that certificate's authenticity again if it is presented to the VU again. Instead of storing the entire certificate, a VU may choose to store only the contents of the Certificate Body, as specified in section 9.3.2. 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.\nCSM_160\nThe VU shall verify the temporal validity of any certificate read from the card or stored in its memory, and shall reject expired certificates. For verifying the temporal validity of a certificate presented by the card a VU shall use its internal clock.\nFigure 4\nProtocol for Card Certificate Chain Verification by VU\n10.2.2\nVU Certificate Chain Verification by Card\nCSM_161\nTachograph 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:\nThe CHA of the VU.Link certificate shall indicate the ERCA.\nThe CHA of the VU.CA certificate shall indicate an MSCA.\nThe CHA field of the VU certificate shall indicate a VU certificate for mutual authentication (see Appendix 1, data type EquipmentType).\nFigure 5\nProtocol for VU Certificate Chain Verification by Card\nNotes to Figure 5:\n—\nThe VU certificates and public keys mentioned in the figure are those for mutual authentication. Section 9.1.4 denotes these as VU_MA.\n—\nThe 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.\n—\nThe VU.CA.EUR certificate mentioned in the figure is the European root certificate that is indicated in the CAR of the VU.CA certificate.\n—\nThe 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.\n—\nThe VU.Link.EUR certificate is the European root certificate that is indicated in the CAR of the VU.Link certificate.\nCSM_162\nAs depicted in Figure 5, verification of the certificate chain of the vehicle unit shall begin with the vehicle unit attempting to set its own public key for use in the tachograph card. If this succeeds, it means that the card successfully verified the VU's certificate chain in the past, and has stored the VU certificate for future reference. In this case, the VU certificate is set for use and the process continues with VU Authentication. If the card does not know the VU certificate, the VU shall successively present the VU.CA certificate to be used for verifying its VU certificate, the VU.CA.EUR certificate to be used for verifying the VU.CA certificate, and possibly the link certificate, in order to find a certificate known or verifiable by the card. If such a certificate is found, the card shall use that certificate to verify the underlying VU certificates presented to it. If successful, the VU shall finally set its public key for use in the tachograph card. If not successful, the VU shall ignore the card.\nNote: There are three ways in which the card may know the VU.CA.EUR certificate:\n—\nthe VU.CA.EUR certificate is the same certificate as the card's own EUR certificate;\n—\nthe VU.CA.EUR certificate precedes the card's own EUR certificate and the card contained this certificate already at issuance (see CSM_91);\n—\nthe VU.CA.EUR certificate succeeds the card's own EUR certificate and the card received a link certificate in the past from another vehicle unit, verified it and stored it for future reference.\nCSM_163\nThe VU shall use the MSE: Set AT command to set its public key for use in the tachograph card. As specified in Appendix 2, this command contains an indication of the cryptographic mechanism that will be used with the key that is set. This mechanism shall be ‘VU Authentication using the ECDSA algorithm, in combination with the hashing algorithm linked to the key size of the VU's VU_MA key pair, as specified in CSM_50’.\nCSM_164\nThe MSE: Set AT command also contains an indication of the ephemeral key pair which the VU will use during session key agreement (see section 10.4). Therefore, before sending the MSE: Set AT command, the VU shall generate an ephemeral ECC key pair. For generating the ephemeral key pair, the VU shall use the standardized domain parameters indicated in the card certificate. The ephemeral key pair is denoted as (VU.SKeph, VU.PKeph, Card.DP). The VU shall take the x-coordinate of the ECDH ephemeral public point as the key identification; this is called the compressed representation of the public key and denoted as Comp(VU.PKeph).\nCSM_165\nIf 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.\nCSM_166\nThe card shall verify the temporal validity of any certificate presented by the VU or referenced by the VU while stored in the card's memory, and shall reject expired certificates.\nCSM_167\nFor verifying the temporal validity of a certificate presented by the VU, each tachograph card shall internally store some data representing the current time. This data shall not be directly updatable by a VU. At issuance, the current time of a card shall be set equal to the Effective Date of the card's Card_MA certificate. A card shall update its current time if the Effective Date of an authentic ‘valid source of time’ certificate presented by a VU is more recent than the card's current time. In that case, the card shall set its current time to the Effective Date of that certificate. The card shall accept only the following certificates as a valid source of time:\nSecond-generation ERCA link certificates\nSecond-generation MSCA certificates\nSecond-generation VU certificates issued by the same country as the card's own card certificate(s).\nNote: 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.\nCSM_168\nAs indicated in Figure 5, once the card has verified the authenticity and validity of a previously unknown certificate, it may store this certificate for future reference, such that it does not need to verify that certificate's authenticity again if it is presented to the card again. Instead xof storing the entire certificate, a card may choose to store only the contents of the Certificate Body, as specified in section 9.3.2.\n10.3.\nVU Authentication\nCSM_169\nVehicle units and cards shall use the VU Authentication protocol depicted in Figure 6 to authenticate the VU towards the card. VU Authentication enables the tachograph card to explicitly verify that the VU is authentic. To do so, the VU shall use its private key to sign a challenge generated by the card.\nCSM_170\nNext to the card challenge, the VU shall include in the signature the certificate holder reference taken from the card certificate.\nNote: This ensures that the card to which the VU authenticates itself is the same card whose certificate chain the VU has verified previously.\nCSM_171\nThe VU shall also include in the signature the identifier of the ephemeral public key Comp(VU.PKeph) which the VU will use to set up Secure Messaging during the Chip Authentication process specified in section 10.4.\nNote: 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.\nFigure 6\nVU Authentication protocol\nCSM_172\nIf multiple GET CHALLENGE commands are sent by the VU during VU Authentication, the card shall return a new 8-byte random challenge each time, but shall store only the last challenge.\nCSM_173\nThe signing algorithm used by the VU for VU Authentication shall be ECDSA as specified in [DSS], using the hashing algorithm linked to the key size of the VU's VU_MA key pair, as specified in CSM_50. The signature format shall be plain, as specified in [TR-03111]. The VU shall send the resulting signature to the card.\nCSM_174\nUpon receiving the VU’s signature in an EXTERNAL AUTHENTICATE command, the card shall\nCalculate the authentication token by concatenating Card.CHR, the card challenge rcard and the identifier of the VU ephemeral public key Comp(VU.PKeph),\nVerify 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.\n10.4.\nChip Authentication and Session Key Agreement\nCSM_175\nVehicle units and cards shall use the Chip Authentication protocol depicted in Figure 7 to authenticate the card towards the VU. Chip Authentication enables the vehicle unit to explicitly verify that the card is authentic.\nFigure 7\nChip Authentication and session key agreement\nCSM_176\nThe VU and the card shall take the following steps:\n1..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.\n2..The 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.\n3..The card computes Comp(VU.PKeph) from VU.PKeph and compares this to the stored value of Comp(VU.PKeph).\n4..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.\n5..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.\n6..Using 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.\n7..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.\n8..The VU derives session keys KMAC and KENC from K and NPICC; see CSM_179.\n9..The VU verifies the authentication token TPICC.\nCSM_177\nIn step 3 above, the card shall compute Comp(VU.PKeph) as the x-coordinate of the public point in VU.PKeph.\nCSM_178\nIn steps 4 and 7 above, the card and the vehicle unit shall use the ECKA-EG algorithm as defined in [TR-03111].\nCSM_179\nIn 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:\nThe value of the counter shall be ‘00 00 00 01’ for KENC and ‘00 00 00 02’ for KMAC.\nThe optional nonce r shall be used and shall be equal to NPICC.\nFor deriving 128-bits AES keys, the hashing algorithm to be used shall be SHA-256.\nFor deriving 192-bits AES keys, the hashing algorithm to be used shall be SHA-384.\nFor deriving 256-bits AES keys, the hashing algorithm to be used shall be SHA-512.\nThe 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.\nCSM_180\nIn 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.\n10.5.\nSecure Messaging\n10.5.1\nGeneral\nCSM_181\nAll 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.\nCSM_182\nExcept 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.\nCSM_183\nWhen 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.\nCSM_184\nSecure Messaging shall use AES as defined in [AES] with the session keys KMAC and KENC that were agreed during Chip Authentication.\nCSM_185\nAn 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.\nCSM_186\nFor 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.\nCSM_187\nFor 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.\n10.5.2\nSecure Message Structure\nCSM_188\nSecure 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.\nTable 5\nSecure Messaging Data Objects\nData Object Name\nTag\nPresence (M)andatory, (C)onditional or (F)orbidden in\nCommands\nResponses\nPlain value not encoded in BER-TLV\n‘81’\nC\nC\nPlain value encoded in BER-TLV, but not including SM DOs\n‘B3’\nC\nC\nPadding-content indicator followed by cryptogram, plain value not encoded in BER-TLV\n‘87’\nC\nC\nProtected Le\n‘97’\nC\nF\nProcessing Status\n‘99’\nF\nM\nCryptographic Checksum\n‘8E’\nM\nM\nNote: 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.\nCSM_189\nAll 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:\nTagThe tag is encoded in one or two octets and indicates the content.\nLengthThe 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.\nValueThe value is encoded in zero or more octets\nCSM_190\nAPDUs protected by Secure Messaging shall be created as follows:\nThe command header shall be included in the MAC calculation, therefore value ‘0C’shall be used for the class byte CLA.\nAs 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.\nThe actual value of Lc will be modified to Lc' after application of secure messaging.\nThe Data field shall consist of SM data objects.\nIn 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.\nCSM_191\nAny 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].\nNote: Padding for Secure Messaging is always performed by the secure messaging layer, not by the CMAC or CBC algorithms.\nSummary and Examples\nA command APDU with applied Secure Messaging will have the following structure, depending on the case of the respective unsecured command (DO is data object):\nCase 1 CLA INS P1 P2 || Lc' || DO ‘8E’ || Le\nCase 2 CLA INS P1 P2 || Lc' || DO ‘97’ || DO‘8E’ || Le\nCase 3 (even INS byte) CLA INS P1 P2 || Lc' || DO ‘81’ || DO‘8E’ || Le\nCase 3 (odd INS byte) CLA INS P1 P2 || Lc' || DO ‘B3’ || DO‘8E’ || Le\nCase 4 (even INS byte) CLA INS P1 P2 || Lc' || DO ‘81’ || DO‘97’ || DO‘8E’ || Le\nCase 4 (odd INS byte) CLA INS P1 P2 || Lc' || DO ‘B3’ || DO‘97’ || DO‘8E’ || Le\nwhere Le = ‘00’ or ‘00 00’ depending on whether short length fields or extended length fields are used; see [ISO 7816-4].\nA response APDU with applied Secure Messaging will have the following structure, depending on the case of the respective unsecured response:\nCase 1 or 3 DO ‘99’ || DO ‘8E’ || SW1SW2\nCase 2 or 4 (even INS byte) without encryption DO ‘81’ || DO ‘99’ || DO ‘8E’ || SW1SW2\nCase 2 or 4 (even INS byte) with encryption DO ‘87’ || DO ‘99’ || DO ‘8E’ || SW1SW2\nCase 2 or 4 (odd INS byte) without encryption DO ‘B3’ || DO ‘99’ || DO ‘8E’ || SW1SW2\nNote: Case 2 or 4 (odd INS byte) with encryption is never used in the communication between a VU and a card.\nBelow 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.\nFigure 8\nTransformation of an authenticated Case 4 Command APDU\nFigure 9\nTransformation of an authenticated Case 1 / Case 3 Response APDU\nFigure 10\nTransformation of an encrypted and authenticated Case 2/Case 4 Response APDU\n10.5.3\nSecure Messaging Session Abortion\nCSM_192\nA vehicle unit shall abort an ongoing Secure Messaging session if and only if one of the following conditions occur:\nit receives a plain response APDU,\nit detects a Secure Messaging error in a response APDU:\nAn expected Secure Messaging data object is missing, the order of data objects is incorrect, or an unknown data object is included.\nA 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’.\nthe card sends a status byte indicating it detected an SM error (see CSM_194),\nthe 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.\nCSM_193\nA tachograph card shall abort an ongoing Secure Messaging session if and only if one of the following conditions occur:\nit receives a plain command APDU,\nit detects a Secure Messaging error in a command APDU:\nAn expected Secure Messaging data object is missing, the order of data objects is incorrect, or an unknown data object is included.\nA Secure Messaging data object is incorrect, e.g. the MAC value is incorrect or the TLV structure is incorrect.\nit is depowered or reset,\nthe VU starts the VU Authentication process,\nthe 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.\nCSM_194\nRegarding SM error handling by a tachograph card:\nIf 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’.\nIf a Secure Messaging data object in a command APDU is incorrect, a tachograph card shall respond with status bytes ‘69 88’.\nIn such a case, the status bytes shall be returned without using SM.\nCSM_195\nIf a Secure Messaging session between a VU and a tachograph card is aborted, the VU and the tachograph card shall\nsecurely destroy the stored session keys\nimmediately establish a new Secure Messaging session, as described in sections 10.2 — 10.5.\nCSM_196\nIf 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.\n11.\nVU — EXTERNAL GNSS FACILITY COUPLING, MUTUAL AUTHENTICATION AND SECURE MESSAGING\n11.1.\nGeneral\nCSM_197\nThe 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.\nCSM_198\nSecure 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.\nCSM_199\nCommunication 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.\nCSM_200\nFor 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.\n11.2.\nVU and External GNSS Facility Coupling\nCSM_201\nA 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.\nCSM_202\nCoupling 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.\nCSM_203\nA 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.\nCSM_204\nA 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.\n11.3.\nMutual Certificate Chain Verification\n11.3.1\nGeneral\nCSM_205\nMutual 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.\n11.3.2\nDuring VU — EGF Coupling\nCSM_206\nDuring 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.\nNotes to Figure 4 within this context:\n—\nCommunication 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.\n—\nThe 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.\n—\nThe 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.\n—\nThe 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.\n—\nThe 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.\n—\nThe Card.Link.EUR certificate is the European root certificate that is indicated in the CAR of the Card.Link certificate.\n—\nInstead of the , the VU shall read the from EF ICC.\n—\nInstead of selecting the Tachograph AID, the VU shall select the EGF AID.\n—\n‘Ignore Card’ shall be interpreted as ‘Ignore EGF’.\nCSM_207\nOnce it has verified the EGF_MA certificate, the vehicle unit shall store this certificate for use during normal operation; see section 11.3.3.\nCSM_208\nDuring 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.\nNotes to Figure 5 within this context:\n—\nThe VU shall generate a fresh ephemeral key pair using the domain parameters in the EGF certificate.\n—\nThe VU certificates and public keys mentioned in the figure are those for mutual authentication. Section 9.1.4 denotes these as VU_MA.\n—\nThe 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.\n—\nThe VU.CA.EUR certificate mentioned in the figure is the European root certificate that is indicated in the CAR of the VU.CA certificate.\n—\nThe 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.\n—\nThe VU.Link.EUR certificate is the European root certificate that is indicated in the CAR of the VU.Link certificate.\nCSM_209\nIn deviation from requirement CSM_167, an EGF shall use the GNSS time to verify the temporal validity of any certificate presented.\nCSM_210\nOnce 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.\n11.3.3\nDuring Normal Operation\nCSM_211\nDuring 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.\nNote 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.\nFigure 11\nMutual verification of certificate temporal validity during normal VU — EGF operation\nCSM_212\nAs 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.\n11.4.\nVU Authentication, Chip Authentication and Session Key Agreement\nCSM_213\nVU 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.\n11.5.\nSecure Messaging\nCSM_214\nAll 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.\nCSM_215\nIf 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.\n12.\nVU — MOTION SENSOR PAIRING AND COMMUNICATION\n12.1.\nGeneral\nCSM_216\nA 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.\nNote: readers of this chapter are supposed to be familiar with the contents of [ISO 16844-3].\n12.2.\nVU — Motion Sensor Pairing Using Different Key Generations\nAs 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.\nCSM_217\nA second-generation VU and a second-generation motion sensor shall be paired as follows (compare Table 6 in [ISO 16844-3]):\n1..A second-generation workshop card is inserted into the VU and the VU is connected to the motion sensor.\n2..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.\n3..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.\n4..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.\n5..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.\n6..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.\n7..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.\n8..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.\nNote that steps 2 and 5 are different from the standard process in [ISO 16844-3]; the other steps are standard.\nExample: 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\nSuppose 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:\nNs[1]: its serial number encrypted with generation 1 of KID,\nNs[2]: its serial number encrypted with generation 2 of KID,\nNs[3]: its serial number encrypted with generation 3 of KID,\nKP[1]: its generation-1 pairing key, encrypted with generation 1 of KM,\nKP[2]: its generation-2 pairing key, encrypted with generation 2 of KM,\nKP[3]: its generation-3 pairing key, encrypted with generation 3 of KM,\nSuppose 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.\nSuppose the VU is a generation-2 VU, containing the generation 2 of KM-VU.\nIn this case, the following will happen in steps 2 — 5:\nStep 2: The VU reads generation 2 and generation 3 of KM-WC from the workshop card and inspects their version numbers.\nStep 3: The VU combines the generation-2 KM-WC with its KM-VU to compute KM and KID.\nStep 4: The VU encrypts the serial number it receives from the motion sensor with KID.\nStep 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].\n12.3.\nVU — Motion Sensor Pairing and Communication using AES\nCSM_218\nAs 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:\nTable 6\nNumber of plaintext and encrypted data bytes per instruction defined in [ISO 16844-3]\nInstruction\nRequest / reply\nDescription of data\n# of plaintext data bytes according to [ISO 16844-3]\n# of plaintext data bytes using AES keys\n# of encrypted data bytes when using AES keys of bitlength\n128\n192\n256\n10\nrequest\nAuthentication data + file number\n8\n8\n16\n16\n16\n11\nreply\nAuthentication data + file contents\n16 or 32, depend on file\n16 or32, depend on file\n32 / 48\n32 / 48\n32 / 48\n41\nrequest\nMoS serial number\n8\n8\n16\n16\n16\n41\nreply\nPairing key\n16\n16 / 24 / 32\n16\n32\n32\n42\nrequest\nSession key\n16\n16 / 24 / 32\n16\n32\n32\n43\nrequest\nPairing information\n24\n24\n32\n32\n32\n50\nreply\nPairing information\n24\n24\n32\n32\n32\n70\nrequest\nAuthentication data\n8\n8\n16\n16\n16\n80\nreply\nMoS counter value + auth. data\n8\n8\n16\n16\n16\nCSM_219\nThe 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:\nIn case the pairing key KP is 16 bytes long: K'p = KP XOR (Ns||Ns)\nIn case the pairing key KP is 24 bytes long: K'p = KP XOR (Ns||Ns||Ns)\nIn case the pairing key KP is 32 bytes long: K'p = KP XOR (Ns||Ns||Ns||Ns)\nwhere Ns is the 8-byte serial number of the motion sensor.\nCSM_220\nIn 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.\nNote: 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.\nCSM_221\nFor 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\nFor 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].\nFor 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.\nNote: 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\nUsed as the initialization vector for the CBC-mode encryption of the data files\nEncrypted and included as the first block in the data that is sent to the VU.\n12.4.\nVU — Motion Sensor Pairing For Different Equipment Generations\nCSM_222\nAs 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.\nNotes:\n—\nIt is not possible to pair a second-generation VU to a first-generation motion sensor.\n—\nIt is not possible to use a first-generation workshop card for coupling a second-generation VU to a motion sensor.\n13.\nSECURITY FOR REMOTE COMMUNICATION OVER DSRC\n13.1.\nGeneral\nAs 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:\nEncrypted tachograph payloadthe encryption of the plaintext tachograph payload\nDSRC security datadescribed below\nThe 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.\nCSM_223\nThe plaintext 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.\nCSM_224\nThe DSRC security data shall consist of the concatenation of the following data elements in the following order; see also Figure 12:\nCurrent date timethe current date and time of the VU (data type )\nCountera 3-byte counter, see CSM_225\nVU serial number the VU’s serial number or certificate request ID (data type VuSerialNumber or CertificateRequestID) – see CSM_123\nDSRC master key version numberthe 1-byte version number of the DSRC master key from which the VU-specific DSRC keys were derived, see section 9.2.2.\nMACthe MAC calculated over all previous bytes in the RTM data.\nCSM_225\nThe 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.\n13.2.\nTachograph Payload Encryption and MAC Generation\nCSM_226\nGiven a plaintext data element with data type 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].\nCSM_227\nA 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.\nFigure 12\nTachograph payload encryption and MAC generation\n13.3.\nVerification and Decryption of Tachograph Payload\nCSM_228\nWhen 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:\n1..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.\n2..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_VU DSRC _ENC and K_VU DSRC _MAC, as specified in CSM_124.\n3..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.\n4..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.\nCSM_229\nIn 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.\nNotes:\n—\nThis requires the remote interrogator to have an accurate and reliable source of time.\n—\nSince 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.\nCSM_230\nWhen 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.\n14.\nSIGNING DATA DOWNLOADS AND VERIFYING SIGNATURES\n14.1.\nGeneral\nCSM_231\nThe 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):\nIn case of a VU download:\nThe VU_Sign certificate\nThe MSCA_VU-EGF certificate containing the public key to be used for verification of the VU_Sign certificate\nIn case of a Card download:\nThe Card_Sign certificate\nThe MSCA_Card certificate containing the public key to be used for verification of the Card_Sign certificate\nCSM_232\nThe IDE shall also dispose of.\nIn 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.\nIn case it verifies the signature itself: all valid European root certificates.\nNote: the method the IDE uses to retrieve these certificates is not specified in this Appendix.\n14.2.\nSignature generation\nCSM_233\nThe 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].\n14.3.\nSignature verification\nCSM_234\nAn 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:\nSecond-generation ERCA link certificates\nSecond-generation MSCA certificates\nSecond-generation VU_Sign or Card_Sign certificates issued by the same country as the control card’s own card certificate.\nIn 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:\nThe CHA field of the EQT certificate shall indicate a VU or Card (as applicable) certificate for signing (see Appendix 1, data type EquipmentType).\nThe CHA of the EQT.CA certificate shall indicate an MSCA.\nThe CHA of the EQT.Link certificate shall indicate the ERCA.\nNotes to Figure 13:\n—\nThe equipment that signed the data to be analysed is denoted EQT.\n—\nThe EQT certificates and public keys mentioned in the figure are those for signing, i.e. VU_Sign or Card_Sign.\n—\nThe EQT.CA certificates and public keys mentioned in the figure are those for signing VU or Card certificates, as applicable.\n—\nThe EQT.CA.EUR certificate mentioned in the figure is the European root certificate that is indicated in the CAR of the EQT.CA certificate.\n—\nThe 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.\n—\nThe EQT.Link.EUR certificate is the European root certificate that is indicated in the CAR of the EQT.Link certificate.\nCSM_235\nFor 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.\nCSM_236\nFor verifying the EQT's signature, the control card shall follow the signature scheme defined in [DSS].\nNote: 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.\nFigure 13\nProtocol for verification of the signature over a downloaded data file",
  "extent": "E+W+S+N.I.",
  "status": null,
  "version": "current",
  "annotations": [
    {
      "type": "F",
      "label": "F1",
      "text": "Substituted by Commission Implementing Regulation (EU) 2018/502 of 28 February 2018 amending Implementing Regulation (EU) 2016/799 laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)."
    },
    {
      "type": "F",
      "label": "F2",
      "text": "Inserted by Commission Implementing Regulation (EU) 2018/502 of 28 February 2018 amending Implementing Regulation (EU) 2016/799 laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)."
    },
    {
      "type": "footnote",
      "label": "f1",
      "text": "Storage of KM and KID is optional, as these keys can be derived from KM-VU, KM-WC and CV."
    },
    {
      "type": "footnote",
      "label": "f2",
      "text": "Note that the generation-1, generation-2 and generation-3 pairing keys may actually be the same key, or may be three different keys having different lengths, as explained in CSM_117."
    }
  ],
  "outstanding_effects": [],
  "provenance": {
    "source": "legislation.gov.uk",
    "source_url": "https://www.legislation.gov.uk/eur/2016/799/annex/1/appendix/11",
    "retrieved_at": "2026-11-01T14:45:49.686558+00:00"
  },
  "licence": "Open Government Licence v3.0",
  "licence_url": "https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/",
  "attribution": "Contains public sector information licensed under the Open Government Licence v3.0. Source: legislation.gov.uk, The National Archives."
}