{
  "url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-11",
  "json_url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-11.json",
  "legislation": "eur/1985/3821",
  "legislation_title": "Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport",
  "legislation_url": "https://openlegislation.uk/eu-regulation-1985-3821",
  "path": "annex/2/appendix/11",
  "kind": "appendix",
  "number": "11",
  "heading": "COMMON SECURITY MECHANISMS",
  "text": "1.\nGENERALITIES\nThis appendix specifies the security mechanisms ensuring:\nthe mutual authentication between VUs and tachograph cards, including session key agreement,\nthe confidentiality, integrity and authentication of data transferred between VUs and tachograph cards,\nthe integrity and authentication of data downloaded from VUs to external storage media,\nthe integrity and authentication of data downloaded from tachograph cards to external storage media.\n1.1.\nReferences\nThe following references are used in this Appendix:\nSHA-1 National Institute of Standards and Technology (NIST). FIPS Publication 180-1: Secure Hash Standard. April 1995\nPKCS1 RSA Laboratories. PKCS # 1: RSA Encryption Standard. Version 2.0. October 1998\nTDES National Institute of Standards and Technology (NIST). FIPS Publication 46-3: Data Encryption Standard. Draft 1999\nTDES-OP ANSI X9.52, Triple Data Encryption Algorithm Modes of Operation. 1998\nISO/IEC 7816-4 Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 4: Interindustry commands for interexchange. First edition: 1995 + Amendment 1: 1997\nISO/IEC 7816-6 Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 6: Interindustry data elements. First edition: 1996 + Cor 1: 1998\nISO/IEC 7816-8 Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 8: Security related interindustry commands. First edition 1999\nISO/IEC 9796-2 Information Technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Mechanisms using a hash function. First edition: 1997\nISO/IEC 9798-3 Information Technology — Security techniques — Entity authentication mechanisms — Part 3: Entity authentication using a public key algorithm. Second edition 1998\nISO 16844-3 Road 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(K a , K b , K c ) a key bundle for use by the triple data encryption algorithm\nCA Certification authority\nCAR Certification authority reference\nCC Cryptographic checksum\nCG Cryptogram\nCH Command header\nCHA Certificate holder authorisation\nCHR Certificate holder reference\nD() Decryption with DES\nDE Data element\nDO Data object\nd RSA private key, private exponent\ne RSA public key, public exponent\nE() Encryption with DES\nEQT Equipment\nHash() hash value, an output of hash\nHash hash function\nKID Key identifier\nKm TDES key. Master Key defined in ISO 16844-3\nKm vu TDES key inserted in vehicle units\nKm wc TDES key inserted in workshop cards\nm message representative an integer between 0 and n -1\nn RSA keys, modulus\nPB Padding bytes\nPI Padding indicator byte (for use in cryptogram for confidentiality DO)\nPV Plain value\ns signature representative, an integer between 0 and n -1\nSSC Send sequence counter\nSM Secure messaging\nTCBC TDEA cipher block chaining mode of operation\nTDEA Triple data encryption algorithm\nTLV Tag length value\nVU Vehicle unit\nX.C the certificate of user X issued by a certification authority\nX.CA a certification authority of user X\nX.CA.PK o X.C the 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.PK public key of a user X\nX.PK[I] RSA encipherment of some information I, using the public key of user X\nX.SK RSA private key of a user X\nX.SK[I] RSA encipherment of some information I, using the private key of user X\n′xx′ a Hexadecimal value\n|| concatenation operator.\n2.\nCRYPTOGRAPHIC SYSTEMS AND ALGORITHMS\n2.1.\nCryptographic systems\nCSM_001 Vehicle 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 Vehicle 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 The RSA algorithm is fully defined by the following relations:\nA more comprehensive description of the RSA function can be found in reference (PKCS1).\nPublic 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 The digital signature mechanisms shall use the SHA-1 hash algorithm as defined in reference (SHA-1).\n2.2.3.\nData encryption algorithm\nCSM_005 DES 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 RSA keys shall be generated through three functional hierarchical levels:\nEuropean level,\nMember State level,\nEquipment level.\nCSM_007 At 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 At 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 At 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 Private 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 For 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 TDES keys described below shall be appropriately maintained during generation, transport (if any) and storage.\nIn order to support recording equipment compliant with ISO 16844, the European certification authority and the Member State certification authorities shall, in addition, ensure the following:\nCSM_036 The European certification authority shall generate Km VU and Km WC , two independent and unique Triple DES keys, and generate Km as:\nThe European certification authority shall forward these keys, under appropriately secured procedures, to Member States certification authorities at their request.\nCSM_037 Member 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 Km VU to vehicle unit manufacturers, under appropriately secured procedures, for insertion in vehicle units,\nensure that Km WC will be inserted in all workshop cards ( SensorInstallationSecData in Sensor_Installation_Data elementary file) during card personalisation.\n3.1.4.\nT-DES session keys generation and distribution\nCSM_012 Vehicle 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 This 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 RSA keys shall have (whatever the level) the following lengths: modulus n 1024 bits, public exponent e 64 bits maximum, private exponent d 1024 bits.\nCSM_015 Triple DES keys shall have the form (K a , K b , K a ) where K a and K b are independent 64 bits long keys. No parity error detecting bits shall be set.\n3.3.\nCertificates\nCSM_016 RSA Public key certificates shall be ‘ non self-descriptive ’‘ Card Verifiable ’ certificates (Ref.: ISO/IEC 7816-8)\n3.3.1.\nCertificates content\nCSM_017 RSA 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:\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 EquipmentType data element, ‘ 00 ’ for a Member State).\n4.\n‘ 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.1. Equipment (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.2. Certification 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\nInteger\nadditional coding (CA specific)\n′01′\n3 Bytes nation alphanumerical code\n′FF FF′ if not used\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 The certificate issued is a digital signature with partial recovery of the certificate content in accordance with ISO/IEC 9796-2 except for its Annex A.4 , with the ‘ Certification Authority Reference ’ appended.\nWith certificate content\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:\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 It involves the following steps:\nverify signature and retrieve content:\nfrom X.C retrieve Sign, C n ′ and CAR′:\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′\ncompute Cr′ and H′ from:\nRecover certificate content C′ = C r ′ || C n ′,\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 The 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 VU-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 When 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 The 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 The response status-information bytes shall be protected by a cryptographic checksum when the response contains no data field.\nCSM_025 Cryptographic checksums shall be four 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′\nT PV\nPlain Value not BER-TLV coded data (to be protected by CC)\n′97′\nT LE\nValue of Le in the unsecured command (to be protected by CC)\n′99′\nT SW\nStatus-Info (to be protected by CC)\n′8E′\nT CC\nCryptographic Checksum\n′87′\nT PI CG\nPadding Indicator Byte || Cryptogram (Plain Value not coded in BER-TLV)\nGiven an unsecured command response pair:\nCommand header\nCommand body\nCLA INS P1 P2\n(L c -field) (Data field) (L e -field)\nfour bytes\nL bytes, denoted as B 1 to B L\nResponse body\nResponse trailer\n(Data field)\nSW1\nSW2\nL r data bytes\ntwo bytes\nThe corresponding secured command response pair is:\nSecured command:\nCommand header (CH)\nCommand body\nCLA INS P1 P2\n(New L c field)\n(New Data field)\n(New L e field)\n′OC′\nLength of new data field\nT PV\nL PV\nPV\nT LE\nL LE\nL e\nT CC\nL CC\nCC\n′00′\n′81′\nL c\nData field\n′97′\n′01′\nL e\n′8E′\n′04′\nCC\nData to be integrated in checksum = CH || PB || T PV || L PV || PV || T LE || L LE L e || 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\nT PV\nL PV\nPV\nT CC\nL CC\nCC\n′81′\nL r\nData field\n′8E′\n′04′\nCC\nData to be integrated in checksum = T PV || L PV || 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\nT PI CG\nL PI CG\nPI CG\nT CC\nL CC\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 = T PI CG || L PI CG || PI CG PB\n3.. Case where response data field is empty:\nResponse body\nResponse trailer\n(New data field)\nnew SW1 SW2\nT SW\nL SW\nSW\nT CC\nL CC\nCC\n′99′\n′02′\nNew SW1 SW2\n′8E′\n′04′\nCC\nData to be integrated in checksum = T SW || L SW || SW || PB\n5.2.\nTreatment of secure messaging errors\nCSM_026 When 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 When 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 Cryptographic 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 The 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 The 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 Cryptograms 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 The 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 MS i .C and EQT.C. The file contains digital signatures of data blocks as specified in Appendix 7 Data Downloading Protocols.\nCSM_033 Digital 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 Data 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 Data 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.",
  "extent": "E+W+S+N.I.",
  "status": null,
  "version": "current",
  "annotations": [
    {
      "type": "F",
      "label": "F1",
      "text": "Inserted by Council Regulation (EC) No 2135/98 of 24 September 1998 amending Regulation (EEC) No 3821/85 on recording equipment in road transport and Directive 88/599/EEC concerning the application of Regulations (EEC) No 3820/85 and (EEC) No 3821/85."
    },
    {
      "type": "F",
      "label": "F2",
      "text": "Substituted by Commission Regulation (EC) No 1360/2002 of 13 June 2002 adapting for the seventh time to technical progress Council Regulation (EEC) No 3821/85 on recording equipment in road transport (Text with EEA relevance)."
    },
    {
      "type": "F",
      "label": "F3",
      "text": "Substituted by Commission Regulation (EC) No 432/2004 of 5 March 2004 adapting for the eighth time to technical progress Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport (Text with EEA relevance)."
    },
    {
      "type": "F",
      "label": "F4",
      "text": "Inserted by Commission Regulation (EC) No 432/2004 of 5 March 2004 adapting for the eighth time to technical progress Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport (Text with EEA relevance)."
    },
    {
      "type": "X",
      "label": "X1",
      "text": "Substituted by Corrigendum to Commission Regulation (EC) No 1360/2002 of 13 June 2002 adapting for the seventh time to technical progress Council Regulation (EEC) No 3821/85 on recording equipment in road transport (Official Journal of the European Communities L 207 of 5 August 2002)."
    }
  ],
  "outstanding_effects": [],
  "provenance": {
    "source": "legislation.gov.uk",
    "source_url": "https://www.legislation.gov.uk/eur/1985/3821/annex/2/appendix/11",
    "retrieved_at": "2026-11-01T15:05:16.849228+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."
}