{
  "url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-2",
  "json_url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-2.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/2",
  "kind": "appendix",
  "number": "2",
  "heading": "TACHOGRAPH CARDS SPECIFICATION",
  "text": "1.\nINTRODUCTION\n1.1.\nAbbreviations\nFor the purpose of this appendix, the following abbreviations apply:\nAC access conditions\nAID application identifier\nALW always\nAPDU application protocol data unit (structure of a command)\nATR answer to reset\nAUT authenticated\nC6, C7 contacts No 6 and 7 of the card as described in ISO/IEC 7816-2\ncc clock cycles\nCHV card holder verification information\nCLA class byte of an APDU command\nDF dedicated file. A DF can contain other files (EF or DF)\nEF elementary file\nENC encrypted: access is possible only by encoding data\netu elementary time unit\nIC integrated circuit\nICC integrated circuit card\nID identifier\nIFD interface device\nIFS information field size\nIFSC information field size for the card\nIFSD information field size device (for the terminal)\nINS instruction byte of an APDU command\nLc length of the input data for a APDU command\nLe length of the expected data (output data for a command)\nMF master file (root DF)\nP1-P2 parameter bytes\nNAD node address used in T=1 protocol\nNEV never\nPIN personal identification number\nPRO SM protected with secure messaging\nPTS protocol transmission selection\nRFU reserved for future use\nRST reset (of the card)\nSM secure messaging\nSW1-SW2 status bytes\nTS initial ATR character\nVPP programming voltage\nXXh value XX in hexadecimal notation\n|| concatenation symbol 03||04=0304.\n1.2.\nReferences\nThe following references are used in this Appendix:\nEN 726-3\nIdentification cards systems — Telecommunications integrated circuit(s) cards and terminals — Part 3: Application independent card requirements. December 1994.\nISO/IEC 7816-2\nInformation technology — Identification cards — Integrated circuit(s) cards with contacts — Part 2: Dimensions and location of the contacts. First edition: 1999.\nISO/IEC 7816-3\nInformation technology — Identification cards — Integrated circuit(s) cards with contacts — Part 3: Electronic signals and transmission protocol. Edition 2: 1997.\nISO/IEC 7816-4\nInformation 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\nInformation technology — Identification cards — Integrated circuit(s) cards with contacts — Part 6: Interindustry data elements. First Edition: 1996 + Cor 1: 1998.\nISO/IEC 7816-8\nInformation technology — Identification cards — Integrated circuit(s) cards with contacts — Part 8: Security related interindustry commands. First Edition: 1999.\nISO/IEC 9797\nInformation technology — Security techniques — Data integrity mechanism using a cryptographic check function employing a block cipher algorithm. Edition 2: 1994.\n2.\nELECTRICAL AND PHYSICAL CHARACTERISTICS\nTCS_200 All electronic signals shall be in accordance with ISO/IEC 7816-3 unless specified otherwise.\nTCS_201 The location and dimensions of the card contacts shall comply with the ISO/IEC 7816-2.\n2.1.\nSupply voltage and current consumption\nTCS_202 The card shall work according to specifications within the consumption limits specified in ISO/IEC 7816-3.\nTCS_203 The card shall work with V CC = 3 V (± 0,3 V) or with V CC = 5 V (± 0,5 V).\nVoltage selection shall be performed according to ISO/IEC 7816-3.\n2.2.\nProgramming voltage V pp\nTCS_204 The card shall not require a programming voltage at pin C6. It is expected that pin C6 is not connected in an IFD. Contact C6 may be connected to V cc in the card but shall not be connected to ground. This voltage should not be interpreted in any case.\n2.3.\nClock generation and frequency\nTCS_205 The card shall operate within a frequency range of 1 to 5 MHz. Within one card session the clock frequency may vary ± 2 %. The clock frequency is generated by the Vehicle Unit and not the card itself. The duty cycle may vary between 40 and 60 %.\nTCS_206 Under conditions contained into the card file EF ICC , the external clock can be stopped. The first byte of the EF ICC file body codes the Clockstop mode conditions (see EN 726-3 for further details):\nLow\nHigh\nBit 3\nBit 2\nBit 1\n0\n0\n1\nClockstop allowed, no preferred level\n0\n1\n1\nClockstop allowed, high level preferred\n1\n0\n1\nClockstop allowed, low level preferred\n0\n0\n0\nClockstop not allowed\n0\n1\n0\nClockstop only allowed on high level\n1\n0\n0\nClockstop only allowed on low level\nBits 4 to 8 are not used.\n2.4.\nI/O contact\nTCS_207 The I/O contact C7 is used to receive data from and to transmit data to the IFD. During operation only either the card or the IFD shall be in transmit mode. Should both units be in transmit mode no damage shall occur to the card. Unless transmitting, the card shall enter the reception mode.\n2.5.\nStates of the card\nTCS_208 The card works in two states while the supply voltage is applied:\noperation state while executing commands or interfacing with Digital Unit,\nidle state at all other times; in this state all data shall be retained by the card.\n3.\nHARDWARE AND COMMUNICATION\n3.1.\nIntroduction\nThis paragraph describes the minimum functionality required by Tachograph cards and VUs to ensure correct operation and interoperability.\nTachograph cards are as compliant as possible with the available ISO/IEC applicable norms (especially ISO/IEC 7816). However, commands and protocols are fully described in order to specify some restricted usage or some differences if they exist. The commands specified are fully compliant with the referred norms except where indicated.\n3.2.\nTransmission protocol\nTCS_300 The Transmission protocol shall be compliant with ISO/IEC 7816-3. In particular, the VU shall recognise waiting time extensions sent by the card.\n3.2.1.\nProtocols\nTCS_301 The card shall provide both protocol T=0 and protocol T=1.\nTCS_302 T=0 is the default protocol, a PTS command is therefore necessary to change the protocol to T=1.\nTCS_303 Devices shall support direct convention in both protocols: the direct convention is hence mandatory for the card.\nTCS_304 The Information Field Size Card byte shall be presented at the ATR in character TA3. This value shall be at least ′F0h′ (= 240 bytes).\nThe following restrictions apply to the protocols:\nTCS_305 T=0\nThe interface device shall support an answer on I/O after the rising edge of the signal on RST from 400 cc.\nThe interface device shall be able to read characters separated with 12 etu.\nThe interface device shall read an erroneous character and its repetition if separated with 13 etu. If an erroneous character is detected, the Error signal on I/O can occur between 1 etu and 2 etu. The device shall support a 1 etu delay.\nThe interface device shall accept a 33 bytes ATR (TS+32)\nIf TC1 is present in the ATR, the Extra Guard Time shall be present for characters sent by the interface device although characters sent by the card can still be separated with 12 etu. This is also true for the ACK character sent by the card after a P3 character emitted by the interface device.\nThe interface device shall take into account a NUL character emitted by the card.\nThe interface device shall accept the complementary mode for ACK.\nThe get-response command cannot be used in chaining mode to get a data which length could exceed 255 bytes.\nTCS_306 T=1\nNAD byte: not used (NAD shall be set to ′00′).\nS-block ABORT: not used.\nS-block VPP state error: not used.\nThe total chaining length for a data field will not exceed 255 bytes (to be ensured by the IFD).\nThe Information Field Size Device (IFSD) shall be indicated by the IFD immediately after the ATR: the IFD shall transmit the S-Block IFS request after the ATR and the card shall send back S-Block IFS. The recommended value for IFSD is 254 bytes.\nThe card will not ask for an IFS readjustment.\n3.2.2.\nATR\nTCS_307 The device checks ATR bytes, according to ISO/IEC 7816-3. No verification shall be done on ATR Historical Characters.\nExample of Basic Biprotocol ATR according to ISO/IEC 7816-3\nCharacter\nValue\nRemarks\nTS\n′3Bh′\nIndicates direct convention\nT0\n′85h′\nTD1 present; 5 historical bytes are presents\nTD1\n′80h′\nTD2 present; T=0 to be used\nTD2\n′11h′\nTA3 present; T=1 to be used\nTA3\n′XXh′ ( at least ′F0h′)\nInformation Field Size Card (IFSC)\nTH1 bis TH5\n′XXh′\nHistorical characters\nTCK\n′XXh′\nCheck character (exclusive OR)\nTCS_308 After the Answer To Reset (ATR), the Master File (MF) is implicitly selected and becomes the Current Directory.\n3.2.3.\nPTS\nTCS_309 The default Protocol is T=0. To set the T=1 protocol, a PTS (also known as PPS) must be sent to the card by the device.\nTCS_310 As both T=0 and T=1 protocols are mandatory for the card, the basic PTS for protocol switching is mandatory for the card.\nThe PTS can be used, as indicated in ISO/IEC 7816-3, to switch to higher baud rates than the default one proposed by the card in the ATR if any (TA(1) byte).\nHigher baud rates are optional for the card.\nTCS_311 If no other baud rate than the default one are supported (or if the selected baud rate is not supported), the card shall respond to the PTS correctly according to ISO/IEC 7816-3 by omitting the PPS1 byte.\nExamples of basic PTS for protocol selection are the following:\nCharacter\nValue\nRemarks\nPPSS\n′FFh′\nThe initiate character\nPPS0\n′00h′ or ′01h′\nPPS1 to PPS3 are not present; ′00h′ to select T0, ′01h′ to select T1\nPK\n′XXh′\nCheck character: ′XXh′ = ′FFh′ if PPS0 = ′00h′\n′XXh′ = ′FEh′ if PPS0 = ′01h′\n3.3.\nAccess conditions (AC)\nAccess Conditions (AC) for the UPDATE_BINARY and READ_BINARY commands are defined for each Elementary File.\nTCS_312 The AC of the current file must be met before accessing the file via these commands.\nThe definitions of the available access conditions are the following:\n— ALW: The action is always possible and can be executed without any restriction.\n— NEV: The action is never possible.\n— AUT: The right corresponding a successful external authentication must be opened up (done by the EXTERNAL_AUTHENTICATE command).\n— PRO SM: Command must be transmitted with a cryptographic checksum using secure messaging (See Appendix 11).\n— AUT and PRO SM (combined)\nOn the processing commands (UPDATE_BINARY and READ_BINARY), the following access conditions can be set in the card:\nUPDATE_ BINARY\nREAD_ BINARY\nALW\nYes\nYes\nNEV\nYes\nYes\nAUT\nYes\nYes\nPRO SM\nYes\nNo\nAUT and PRO SM\nYes\nNo\nThe PRO SM access condition is not available for the READ_BINARY command. It means that the presence of a cryptographic checksum for a READ command is never mandatory. However, using the value ′OC′ for the class, it is possible to use the READ_BINARY command with secure messaging, as described in paragraph 3.6.2.\n3.4.\nData encryption\nWhen confidentiality of data to be read from a file needs to be protected, the file is marked as ‘ Encrypted ’ . Encryption is performed using secure messaging (See Appendix 11).\n3.5.\nCommands and error codes overview\nCommands and file organisation are deduced from and complies with ISO/IEC 7816-4.\nTCS_313 This section describes the following APDU command-response pairs:\nCommand\nINS\nSELECT FILE\nA4\nREAD BINARY\nB0\nUPDATE BINARY\nD6\nGET CHALLENGE\n84\nVERIFY\n20\nGET RESPONSE\nC0\nPERFORM SECURITY OPERATION:\nVERIFY CERTIFICATE\nCOMPUTE DIGITAL SIGNATURE\nVERIFY DIGITAL SIGNATURE\nHASH\n2A\nINTERNAL AUTHENTICATE\n88\nEXTERNAL AUTHENTICATE\n82\nMANAGE SECURITY ENVIRONMENT:\nSETTING A KEY\n22\nPERFORM HASH OF FILE\n2A\nTCS_314 The status word SW1 SW2 are returned in any response message and denote the processing state of the command.\nSW1\nSW2\nMeaning\n90\n00\nNormal processing\n61\nXX\nNormal processing. XX = number of response bytes available\n62\n81\nWarning processing. Part of returned data may be corrupted\n63\nCX\nWrong CHV (PIN). Remaining attempts counter provided by ′X′\n64\n00\nExecution error — State of non-volatile memory unchanged. Integrity error\n65\n00\nExecution error — State of non-volatile memory changed\n65\n81\nExecution error — State of non-volatile memory changed — Memory failure\n66\n88\nSecurity error wrong Cryptographic checksum (during secure messaging) or\nwrong certificate (during certificate verification) or\nwrong cryptogram (during external authentication) or\nwrong signature (during signature verification)\n67\n00\nWrong length (wrong Lc or Le)\n69\n00\nForbidden command (no response available in T=0)\n69\n82\nSecurity status not satisfied\n69\n83\nAuthentication method blocked\n69\n85\nConditions of use not satisfied\n69\n86\nCommand not allowed (no current EF)\n69\n87\nExpected secure messaging data objects missing\n69\n88\nIncorrect secure messaging data objects\n6A\n82\nFile not found\n6A\n86\nWrong parameters P1-P2\n6A\n88\nReferenced data not found\n6B\n00\nWrong parameters (offset outside the EF)\n6C\nXX\nWrong length, SW2 indicates the exact length. No data field is returned\n6D\n00\nInstruction code not supported or invalid\n6E\n00\nClass not supported\n6F\n00\nOther checking errors\n3.6.\nCommands description\nThe mandatory commands for the Tachograph cards are described in this chapter.\nAdditional relevant details, related to cryptographic operations involved, are given in Appendix 11 Common security mechanisms.\nAll commands are described independently of the used protocol (T=0 or T=1). The APDU bytes CLA, INS, P1, P2, Lc and Le are always indicated. If Lc or Le is not needed for the described command, the associated length, value and description are empty.\nTCS_315 If both length bytes (Lc and Le) are requested, the described command has to be split in two parts if the IFD is using protocol T=0: the IFD sends the command as described with P3=Lc + data and then sends a GET_RESPONSE (see point 3.6.6) command with P3=Le.\nTCS_316 If both length bytes are requested, and Le=0 (secure messaging):\nWhen using protocol T=1, the card shall answer to Le=0 by sending all available output data.\nWhen using protocol T=0, the IFD shall send the first command with P3=Lc + data, the card shall answer (to this implicit Le=0) by the Status bytes ′61La′, where La is the number of response bytes available. The IFD shall then generate a GET RESPONSE command with P3=La to read the data.\n3.6.1.\nSelect file\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe SELECT FILE command is used:\nto select an application DF (selection by name must be used)\nto select an elementary file corresponding to the submitted file ID\n3.6.1.1.\nSelection by name (AID)\nThis command allows to select an application DF in the card.\nTCS_317 This command can be performed from anywhere in the file structure (after the ATR or at anytime).\nTCS_318 The selection of an application resets the current security environment. After performing the application selection, no current public key is selected anymore and the former session key is no longer available for secure messaging. The AUT access condition is also lost.\nTCS_319 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nINS\n1\n′A4h′\nP1\n1\n′04h′\nSelection by name (AID)\nP2\n1\n′0Ch′\nNo response expected\nLc\n1\n′NNh′\nNumber of bytes sent to the card (length of the AID): ′06h′ for the Tachograph application\n#6-#(5+NN)\nNN\n′XX..XXh′\nAID: ′FF 54 41 43 48 4F′ for the Tachograph application\nNo response to the SELECT FILE command is needed (Le absent in T=1, or no response asked in T=0).\nTCS_320 Response Message (no response asked)\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus Words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the application corresponding with the AID is not found, the processing state returned is ′6A82′,\nin T=1, if the byte Le is present, the state returned is ′6700′,\nin T=0, if a response is asked after the SELECT FILE command, the state returned is ′6900′,\nif the selected application is considered corrupted (integrity error is detected within the file attributes), the processing state returned is ′6400′ or ′6581′.\n3.6.1.2.\nSelection of an elementary file using its file identifier\nTCS_321 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nINS\n1\n′A4h′\nP1\n1\n′02h′\nSelection of an EF under the current DF\nP2\n1\n′0Ch′\nNo response expected\nLc\n1\n′02h′\nNumber of bytes sent to the card\n#6-#7\n2\n′XXXXh′\nFile Identifier\nNo response to the SELECT FILE command is needed (Le absent in T=1, or no response asked in T=0).\nTCS_322 Response Message (no response asked)\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus Words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the file corresponding with the file identifier is not found, the processing state returned is ′6A82′,\nin T=1, if the byte Le is present, the state returned is ′6700′,\nin T=0, if a response is asked after the SELECT FILE command, the state returned is ′6900′,\nif the selected file is considered corrupted (integrity error is detected within the file attributes), the processing state returned is ′6400′ or ′6581′.\n3.6.2.\nRead Binary\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe Read Binary command is used to read data from a transparent file.\nThe response of the card consists of returning the data read, optionally encapsulated in a secure messaging structure.\nTCS_323 The command can be performed only if the security status satisfies the security attributes defined for the EF for the READ function.\n3.6.2.1.\nCommand without secure messaging\nThis command enables the IFD to read data from the EF currently selected, without secure messaging.\nTCS_324 Reading data from a file marked as ‘ Encrypted ’ shall not be possible through this command.\nTCS_325 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nNo secure messaging asked\nINS\n1\n′B0h′\nP1\n1\n′XXh′\nOffset in bytes from the beginning of the file: most significant byte\nP2\n1\n′XXh′\nOffset in bytes from the beginning of the file: least significant byte\nLe\n1\n′XXh′\nLength of data expected. number of bytes to be read\nNote: bit 8 of P1 must be set to 0.\nTCS_326 Response Message\nByte\nLength\nValue\nDescription\n#1-#X\nX\n′XX..XXh′\nData read\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif no EF is selected, the processing state returned is ′6986′,\nif the Access Control of the selected file are not satisfied, the command is interrupted with ′6982′,\nif the Offset is not compatible with the size of the EF (Offset > EF size), the processing state returned is ′6B00′,\nif the size of the data to be read is not compatible with the size of the EF (Offset + Le > EF size) the processing state returned is ′6700′ or ′6Cxx′, where ′xx′ indicates the exact length,\nif an integrity error is detected within the file attributes, the card shall consider the file as corrupted and unrecoverable, the processing state returned is ′6400′ or ′6581′,\nif an integrity error is detected within the stored data, the card shall return the demanded data, and the processing state returned is ′6281′.\n3.6.2.2.\nCommand with secure messaging\nThis command enables the IDF to read data from the EF currently selected with secure messaging, in order to verify the integrity of the data received and to protect the confidentiality of the data in the case the EF is marked as ‘ Encrypted ’ .\nTCS_327 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′0Ch′\nSecure Messaging asked\nINS\n1\n′B0h′\nINS\nP1\n1\n′XXh′\nP1 (offset in bytes from the beginning of the file): Most Significant Byte\nP2\n1\n′XXh′\nP2 (offset in bytes from the beginning of the file): Least Significant Byte\nLc\n1\n′09h′\nLength of input data for secure messaging\n#6\n1\n′97h′\nT LE : Tag for expected length specification\n#7\n1\n′01h′\nL LE : Length of expected length\n#8\n1\n′NNh′\nExpected length specification (original Le): Number of Bytes to be read\n#9\n1\n′8Eh′\nT CC : Tag for cryptographic checksum\n#10\n1\n′04h′\nL CC : Length of following cryptographic checksum\n#11-#14\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nLe\n1\n′00h′\nAs specified in ISO/IEC 7816-4\nTCS_328 Response Message if EF is not marked as ‘ Encrypted ’ and if Secure Messaging input format is correct:\nByte\nLength\nValue\nDescription\n#1\n1\n′81h′\nT PV : Tag for plain value data\n#2\nL\n′NNh′ or ′81 NNh′\nL PV : length of returned data (= original Le)\nL is 2 bytes if L PV >127 bytes\n#(2+L)-#(1+L+NN)\nNN\n′XX..XXh′\nPlain Data value\n#(2+L+NN)\n1\n′8Eh′\nT CC : Tag for cryptographic checksum\n#(3+L+NN)\n1\n′04h′\nL CC : Length of following cryptographic checksum\n#(4+L+NN)-#(7+L+NN)\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nSW\n2\n′XXXXh′\nStatus Words (SW1, SW2)\nTCS_329 Response Message if EF is marked as ‘ Encrypted ’ and if Secure Messaging input format is correct:\nByte\nLength\nValue\nDescription\n#1\n1\n′87h′\nT PI CG : Tag for encrypted data (cryptogram)\n#2\nL\n′MMh′ or ′81 MMh′\nL PI CG : length of returned encrypted data (different of original Le of the command due to padding)\nL is 2 byte if L PI CG > 127 bytes\n#(2+L)-#(1+L+MM)\nMM\n′01XX..XXh′\nEncrypted data: padding indicator and cryptogram\n#(2+L+MM)\n1\n′8Eh′\nT CC : tag for cryptographic checksum\n#(3+L+MM)\n1\n′04h′\nL CC : length of following cryptographic checksum\n#(4+L+MM)-#(7+L+MM)\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nThe encrypted data returned contain a first byte indicating the used padding mode. For the tachograph application, the padding indicator always takes the value '01h', indicating that the used padding mode is the one specified in ISO/IEC 7816-4 (one byte with value ′80h′ followed by some null bytes: ISO/IEC 9797 method 2).\nThe ‘ regular ’ processing states, described for the READ BINARY command with no secure messaging (see point 3.6.2.1), can be returned using the response message structures described above, under a ′99h′ Tag (as described in TCS 335).\nAdditionally, some errors specifically related to secure messaging can happen. In that case, the processing state is simply returned, with no secure messaging structure involved:\nTCS_330 Response Message if incorrect Secure Messaging input format\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf no current session key is available, the processing state ′6A88′ is returned. It happens either if the session key has not already been generated or if the session key validity has expired (in this case the IFD must re-run a mutual authentication process to set a new session key).\nIf some expected data objects (as specified above) are missing in the secure messaging format, the processing state ′6987′ is returned: this error happens if an expected tag is missing or if the command body is not properly constructed.\nIf some data objects are incorrect, the processing state returned is ′6988′: this error happens if all the required tags are present but some lengths are different from the ones expected.\nIf the verification of the cryptographic checksum fails, the processing state returned is ′6688′.\n3.6.3.\nUpdate Binary\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe UPDATE BINARY command message initiates the update (erase + write) of the bits already present in an EF binary with the bits given in the command APDU.\nTCS_331 The command can be performed only if the security status satisfies the security attributes defined for the EF for the UPDATE function (If the access control of the UPDATE function includes PRO SM, a secure messaging must be added in the command).\n3.6.3.1.\nCommand without secure messaging\nThis command enables the IFD to write data into the EF currently selected, without the card verifying the integrity of data received. This plain mode is allowed only if the related file is not marked as ‘ Encrypted ’ .\nTCS_332 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nNo secure messaging asked\nINS\n1\n′D6h′\nP1\n1\n′XXh′\nOffset in bytes from the beginning of the file: most significant byte\nP2\n1\n′XXh′\nOffset in bytes from the beginning of the file: least significant byte\nLc\n1\n′NNh′\nLc length of data to Update. Number of bytes to be written\n#6-#(5+NN)\nNN\n′XX..XXh′\nData to be written\nNote: bit 8 of P1 must be set to 0.\nTCS_333 Response Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif no EF is selected, the processing state returned is ′6986′,\nif the Access Control of the selected file are not satisfied, the command is interrupted with ′6982′,\nif the Offset is not compatible with the size of the EF (Offset > EF size), the processing state returned is ′6B00′,\nif the size of the data to be written is not compatible with the size of the EF (Offset + Lc > EF size) the processing state returned is ′6700′,\nif an integrity error is detected within the file attributes, the card shall consider the file as corrupted and unrecoverable, the processing state returned is ′6400′ or ′6500′,\nif writing is unsuccessful, the processing state returned is ′6581′.\n3.6.3.2.\nCommand with secure messaging\nThis command enables the IFD to write data into the EF currently selected, with the card verifying the integrity of data received. As no confidentiality is required, the data are not encrypted.\nTCS_334 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′0Ch′\nSecure messaging. Asked\nINS\n1\n′D6h′\nINS\nP1\n1\n′XXh′\nOffset in bytes from the beginning of the file: most significant byte\nP2\n1\n′XXh′\nOffset in bytes from the beginning of the file: least significant byte\nLc\n1\n′XXh′\nLength of the secured data field\n#6\n1\n′81h′\nT PV : tag for plain value data\n#7\nL\n′NNh′ or ′81 NNh′\nL PV : length of transmitted data\nL is 2 bytes if L PV > 127 bytes\n#(7+L)-#(6+L+NN)\nNN\n′XX..XXh′\nPlain data value (data to be written)\n#(7+L+NN)\n1\n′8Eh′\nT CC : tag for cryptographic checksum\n#(8+L+NN)\n1\n′04h′\nL CC : Length of following cryptographic checksum\n#(9+L+NN)-#(12+L+NN)\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nLe\n1\n′00h′\nAs specified in ISO/IEC 7816-4\nTCS_335 Response message if correct Secure Messaging input format\nByte\nLength\nValue\nDescription\n#1\n1\n′99h′\nT SW : tag for status words (to be protected by CC)\n#2\n1\n′02h′\nL SW : length of returned status words\n#3-#4\n2\n′XXXXh′\nStatus words (SW1, SW2)\n#5\n1\n′8Eh′\nT CC : tag for cryptographic checksum\n#6\n1\n′04h′\nL CC : Length of following cryptographic checksum\n#7-#10\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nThe ‘ regular ’ processing states, described for the UPDATE BINARY command with no secure messaging (see point 3.6.3.1), can be returned using the response message structure described above.\nAdditionally, some errors specifically related to secure messaging can happen. In that case, the processing state is simply returned, with no secure messaging structure involved:\nTCS_336 Response Message if error in secure messaging\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus Words (SW1, SW2)\nIf no current session key is available, the processing state ′6A88′ is returned,\nif some expected data objects (as specified above) are missing in the secure messaging format, the processing state ′6987′ is returned: this error happens if an expected tag is missing or if the command body is not properly constructed,\nif some data objects are incorrect, the processing state returned is ′6988′: this error happens if all the required tags are present but some lengths are different from the ones expected,\nif the verification of the cryptographic checksum fails, the processing state returned is ′6688′.\n3.6.4.\nGet challenge\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe GET CHALLENGE command asks the card to issue a challenge in order to use it in a security related procedure in which a cryptogram or some ciphered data are sent to the card.\nTCS_337 The Challenge issued by the card is only valid for the next command, which uses a challenge, sent to the card.\nTCS_338 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′84h′\nINS\nP1\n1\n′00h′\nP1\nP2\n1\n′00h′\nP2\nLe\n1\n′08h′\nLe (Length of challenge expected)\nTCS_339 Response Message\nByte\nLength\nValue\nDescription\n#1-#8\n8\n′XX..XXh′\nChallenge\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif Le is different from ′08h′, the processing state is ′6700′,\nif parameters P1-P2 are incorrect, the processing state is ′6A86′.\n3.6.5.\nVerify\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe Verify command initiates the comparison in the card of the CHV (PIN) data sent from the command with the reference CHV stored in the card.\nNote: The PIN entered by the user must be right padded with FFh' bytes up to a length of 8 bytes by the IFD.\nTCS_340 If the command is successful, the rights corresponding to CHV presentation are opened and the remaining CHV attempt counter is reinitialised.\nTCS_341 An unsuccessful comparison is recorded in the card in order to limit the number of further attempts of the use of the reference CHV.\nTCS_342 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′20h′\nINS\nP1\n1\n′00h′\nP1\nP2\n1\n′00h′\nP2 (the verified CHV is implicitly known)\nLc\n1\n′08h′\nLength of CHV code transmitted\n#6-#13\n8\n′XX..XXh′\nCHV\nTCS_343 Response Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the reference CHV is not found, the processing state returned is ′6A88′,\nif the CHV is blocked, (the remaining attempt counter of the CHV is null), the processing state returned is ′6983′. Once in that state, the CHV can never be successfully presented anymore,\nif the comparison is unsuccessful, the remaining attempt Counter is decreased and the status ′63CX′ is returned (X > 0, and X equals the remaining CHV attempts counter. X = ′F′, the CHV attempts counter is greater than ′F′),\nif the reference CHV is considered corrupted, the processing state returned is ′6400′ or ′6581′.\n3.6.6.\nGet response\nThis command is compliant with ISO/IEC 7816-4.\nThis command (only necessary and available for T=0 Protocol) is used to transmit prepared data from the card to the interface device (case where a command had included both Lc and Le).\nThe GET_RESPONSE command has to be issued immediately after the command preparing the data, otherwise, the data are lost. After the execution of the GET_RESPONSE command (except if the error ′61xx′ or ′6Cxx′ occur, see below), the previously prepared data are no longer available.\nTCS_344 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nINS\n1\n′C0h′\nP1\n1\n′00h′\nP2\n1\n′00h′\nLe\n1\n′XXh′\nNumber of bytes expected\nTCS_345 Response Message\nByte\nLength\nValue\nDescription\n#1-#X\nX\n′XX..XXh′\nData\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′.\nIf no data have been prepared by the card, the processing state returned is ′6900′ or ′6F00′.\nIf Le exceeds the number of available bytes or if Le is null, the processing state returned is ′6Cxx′, where ′xx′ denotes the exact number of available bytes. In that case, the prepared data are still available for a subsequent GET_RESPONSE command.\nIf Le is not null and is smaller than the number of available bytes, the required data are sent normally by the card, and the processing state returned is ′61xx′, where ′xx′ indicates a number of extra bytes still available by a subsequent GET_RESPONSE command.\nIf the command is not supported (protocol T=1), the card returns ′6D00′.\n3.6.7.\nPSO: verify certificate\nThis command is compliant with ISO/IEC 7816-8, but has a restricted usage compared to the command defined in the norm.\nThe VERIFY CERTIFICATE command is used by the card to obtain a Public Key from the outside and to check its validity.\nTCS_346 When a VERIFY CERTIFICATE command is successful, the Public Key is stored for a future use in the Security environment. This key shall be explicitly set for the use in security related commands (INTERNAL AUTHENTICATE, EXTERNAL AUTHENTICATE or VERIFY CERTIFICATE) by the MSE command (see point 3.6.10) using its key identifier.\nTCS_347 In any case, the VERIFY CERTIFICATE command uses the public key previously selected by the MSE command to open the certificate. This public key must be the one of a Member State or of Europe.\nTCS_348 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′2Ah′\nPerform Security Operation\nP1\n1\n′00h′\nP1\nP2\n1\n′AEh′\nP2: non BER-TLV coded data (concatenation of data elements)\nLc\n1\n′ C2h ′\nLc: Length of the certificate, 194 bytes\n#6-#199\n194\n′XX..XXh′\nCertificate: concatenation of data elements (as described in Appendix 11)\nTCS_349 Response Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the certificate verification fails, the processing state returned is ′6688′. The verification and unwrapping process of the certificate is described in Appendix 11,\nif no Public Key is present in the Security Environment, ′6A88′ is returned,\nif the selected public key (used to unwrap the certificate) is considered corrupted, the processing state returned is ′6400′ or ′6581′,\nif the selected public key (used to unwrap the certificate) has a CHA.LSB ( CertificateHolderAuthorisation.equipmentType ) different from ′00′ (i.e. is not the one of a Member State or of Europe), the processing state returned is ′6985′.\n3.6.8.\nInternal authenticate\nThis command is compliant with ISO/IEC 7816-4.\nUsing the INTERNAL AUTHENTICATE command, the IFD can authenticate the card.\nThe authentication process is described in Appendix 11. It includes the following statements:\nTCS_350 The INTERNAL AUTHENTICATE command uses the card Private Key (implicitly selected) to sign authentication data including K1 (first element for session key agreement) and RND1, and uses the Public Key currently selected (through the last MSE command) to encrypt the signature and form the authentication token (more details in Appendix 11).\nTCS_351 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′88h′\nINS\nP1\n1\n′00h′\nP1\nP2\n1\n′00h′\nP2\nLc\n1\n′10h′\nLength of data sent to the card\n#6-#13\n8\n′XX..XXh′\nChallenge used to authenticate the card\n#14-#21\n8\n′XX..XXh′\nVU.CHR (see Appendix 11)\nLe\n1\n′80h′\nLength of the data expected from the card\nTCS_352 Response Message\nByte\nLength\nValue\nDescription\n#1-#128\n128\n′XX..XXh′\nCard authentication token (see Appendix 11)\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif no Public Key is present in the Security Environment, the processing state returned is ′6A88′,\nif no Private Key is present in the Security Environment, the processing state returned is ′6A88′,\nif VU.CHR does not match the current public key identifier, the processing state returned is ′6A88′,\nif the selected private key is considered corrupted, the processing state returned is ′6400′ or ′6581′.\nTCS_353 If the INTERNAL_AUTHENTICATE command is successful, the current session key, if existing, is erased and no longer available. In order to have a new session key available, the EXTERNAL_AUTHENTICATE command must be successfully performed.\n3.6.9.\nExternal authenticate\nThis command is compliant with ISO/IEC 7816-4.\nUsing the EXTERNAL AUTHENTICATE command, the card can authenticate the IFD.\nThe authentication process is described in Appendix 11. It includes the following statements:\nTCS_354 A GET CHALLENGE command must precede the EXTERNAL_AUTHENTICATE command immediately. The card issues a challenge to the outside (RND3).\nTCS_355 The verification of the cryptogram uses RND3 (challenge issued by the card), the card private key (implicitly selected) and the public key previously selected by the MSE command.\nTCS_356 The card verifies the cryptogram, and if it is correct, the AUT access condition is opened.\nTCS_357 The input cryptogram carries the second element for session key agreement K2.\nTCS_358 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′82h′\nINS\nP1\n1\n′00h′\nP1\nP2\n1\n′00h′\nP2 (the public key to be used is implicitly known, and has been previously set by the MSE command)\nLc\n1\n′80h′\nLc (Length of the data sent to the card)\n#6-#133\n128\n′XX..XXh′\nCryptogram (see Appendix 11)\nTCS_359 Response Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (status words (SW1, SW2))\nIf the command is successful, the card returns ′9000′,\nif no Public Key is present in the Security Environment, ′6A88′ is returned,\nif the CHA of the currently set public key is not the concatenation of the Tachograph application AID and of a VU equipment Type, the processing state returned is ′6F00′ (see Appendix 11),\nif no Private Key is present in the Security Environment, the processing state returned is ′6A88′,\nif the verification of the cryptogram is wrong, the processing state returned is ′6688′,\nif the command is not immediately preceded with a GET CHALLENGE command, the processing state returned is ′6985′,\nif the selected private key is considered corrupted, the processing state returned is ′6400′ or ′6581′.\nTCS_360 If the EXTERNAL AUTHENTICATE command is successful, and if the first part of the session key is available from a successful INTERNAL AUTHENTICATE recently performed, the session key is set for future commands using secure messaging.\nTCS_361 If the first session key part is not available from a previous INTERNAL AUTHENTICATE command, the second part of the session key, sent by the IFD, is not stored in the card. This mechanism ensures that the mutual authentication process is done in the order specified in Appendix 11.\n3.6.10.\nManage security environment\nThis command is used to set a public key for authentication purpose.\nThis command is compliant with ISO/IEC 7816-8. The use of this command is restricted regarding the related standard.\nTCS_362 The key referenced in the MSE data field is valid for every file of the Tachograph DF.\nTCS_363 The key referenced in the MSE data field remains the current public key until the next correct MSE command.\nTCS_364 If the key referenced is not (already) present into the card, the security environment remains unchanged.\nTCS_365 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′22h′\nINS\nP1\n1\n′C1h′\nP1: referenced key valid for all cryptographic operations\nP2\n1\n′B6h′\nP2 (referenced data concerning digital signature)\nLc\n1\n′0Ah′\nLc: length of subsequent data field\n#6\n1\n′83h′\nTag for referencing a public key in asymmetric cases\n#7\n1\n′08h′\nLength of the key reference (key identifier)\n#8-#15\n08h\n′XX..XXh′\nKey identifier as specified in Appendix 11\nTCS_366 Response Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the referenced key is not present into the card, the processing state returned is ′6A88′,\nif some expected data objects are missing in the secure messaging format, the processing state ′6987′ is returned. This can happen if the tag ′83h′ is missing,\nif some data objects are incorrect, the processing state returned is ′6988′. This can happen if the length of the key identifier is not ′08h′,\nif the selected key is considered corrupted, the processing state returned is ′6400′ or ′6581′.\n3.6.11.\nPSO: hash\nThis command is used to transfer to the card the result of a hash calculation on some data. This command is used for the verification of digital signatures. The hash value is stored in EEPROM for the subsequent command verify digital signature.\nThis command is compliant with ISO/IEC 7816-8. The use of this command is restricted regarding the related standard.\nTCS_367 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′2Ah′\nPerform security operation\nP1\n1\n′90h′\nReturn hash code\nP2\n1\n′A0h′\nTag: data field contains DOs relevant for hashing\nLc\n1\n′16h′\nLength Lc of the subsequent data field\n#6\n1\n′90h′\nTag for the hash code\n#7\n1\n′14h′\nLength of the hash code\n#8-#27\n20\n′XX..XXh′\nHash code\nTCS_368 Response Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif some expected data objects (as specified above) are missing, the processing state ′6987′ is returned. This can happen if one of the tag ′90h′ is missing,\nif some data objects are incorrect, the processing state returned is ′6988′. This error happens if the required tag is present but with a length different from ′14h′.\n3.6.12.\nPerform hash of file\nThis command is not compliant with ISO/IEC 7816-8. Thus the CLA byte of this command indicates that there is a proprietary use of the PERFORM SECURITY OPERATION/HASH.\nTCS_369 The perform hash file command is used to hash the data area of the currently selected transparent EF.\nTCS_370 The result of the hash operation is stored in the card. It can then be used to get a digital signature of the file, using the PSO-COMPUTE_DIGITAL_SIGNATURE command. This result remains available for the COMPUTE DIGITAL SIGNATURE command until the next successful PERFORM HASH of FILE command.\nTCS_371 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′80h′\nCLA\nINS\n1\n′2Ah′\nPerform security operation\nP1\n1\n′90h′\nTag: hash\nP2\n1\n′00h′\nP2: hash the data of the currently selected transparent file\nTCS_372 Response Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif no application is selected, the processing state ′6985′ is returned,\nif the selected EF is considered corrupted (file attributes or stored data integrity errors), the processing state returned is ′6400′ or ′6581′,\nif the selected file is not a transparent file, the processing state returned is ′6986′.\n3.6.13.\nPSO: compute digital signature\nThis command is used to compute the digital signature of previously computed hash code (see PERFORM HASH of FILE, point 3.6.12).\nThis command is compliant with ISO/IEC 7816-8. The use of this command is restricted regarding the related standard.\nTCS_373 The card private key is used to compute the digital signature and is implicitly known by the card.\nTCS_374 The card performs a digital signature using a padding method compliant with PKCS1 (see Appendix 11 for details).\nTCS_375 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′2Ah′\nPerform security operation\nP1\n1\n′9Eh′\nDigital signature to be returned\nP2\n1\n′9Ah′\nTag: data field contains data to be signed. As no data field is included, the data are supposed to be already present in the card (hash of file)\nLe\n1\n′80h′\nLength of the expected signature\nTCS_376 Response Message\nByte\nLength\nValue\nDescription\n#1-#128\n128\n′XX..XXh′\nSignature of the previously computed hash\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the implicitly selected private key is considered as corrupted, the processing state returned is ′6400′ or ′6581′.\n3.6.14.\nPSO: verify digital signature\nThis command is used to verify the digital signature, provided as an input, in accordance with PKCS1 of a message, whose hash is known to the card. The signature algorithm is implicitly known by the card.\nThis command is compliant with ISO/IEC 7816-8. The use of this command is restricted regarding the related standard.\nTCS_377 The Verify Digital Signature command always uses the public key selected by the previous Manage Security Environment command, and the previous hash code entered by a PSO: hash command.\nTCS_378 Command Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′2Ah′\nPerform security operation\nP1\n1\n′00h′\nP2\n1\n′A8h′\nTag: data field contains DOs relevant for verification\nLc\n1\n′83h′\nLength Lc of the subsequent data field\n#28\n1\n′9Eh′\nTag for digital signature\n#29-#30\n2\n′8180h′\nLength of digital signature (128 bytes, coded in accordance with ISO/IEC 7816-6)\n#31-#158\n128\n′XX..XXh′\nDigital signature content\nTCS_379 Response Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the verification of the signature fails, the processing state returned is ′6688′. The verification process is described in Appendix 11,\nif no public key is selected, the processing state returned is ′6A88′,\nif some expected data objects (as specified above) are missing, the processing state ′6987′ is returned. This can happen if one of the required tag is missing,\nif no hash code is available to process the command (as a result of a previous PSO: hash command), the processing state returned is ′6985′,\nif some data objects are incorrect, the processing state returned is ′6988′. This can happen if one of the required data objects length is incorrect,\nif the selected public key is considered corrupted, the processing state returned is ′6400′ or ′6581′.\n4.\nTACHOGRAPH CARDS STRUCTURE\nThis paragraph specifies the file structures of the Tachograph cards for storage of accessible data,\nIt does not specify card manufacturer dependant internal structures, such as e.g. file headers, nor storage and handling of data elements needed for internal use only such as EuropeanPublicKey, CardPrivateKey, TDesSessionKey or WorkshopCardPin .\nThe useful storage capacity of Tachograph cards shall be of 11 Kbytes minimum. Greater capacities may be used. In such case, the structure of the card remains the same, but the number of records of some elements of the structure is increased. This paragraph specifies minimum and maximum values of these record numbers.\n4.1.\nDriver card structure\nTCS_400 After its personalisation, the driver card shall have the following permanent file structure and file access conditions:\nTCS_401 All EFs structures shall be transparent.\nTCS_402 Read with secure messaging shall be possible for all files under the DF Tachograph.\nTCS_403 The driver card shall have the following data structure:\nTCS_404 The following values, used to provide sizes in the table above, are the minimum and maximum record number values the driver card data structure must use:\nMin\nMax\nn 1\nNoOfEventsPerType\n6\n12\nn 2\nNoOfFaultsPerType\n12\n24\nn 3\nNoOfCardVehicleRecords\n84\n200\nn 4\nNoOfCardPlaceRecords\n84\n112\nn 6\nCardActivityLengthRange\n5 544\nbytes (28 days * 93 activity changes)\n13 776\nbytes (28 days * 240 activity changes)\n4.2.\nWorkshop card structure\nTCS_405 After its personalisation, the workshop card shall have the following permanent file structure and file access conditions:\nTCS_406 All EFs structures shall be transparent.\nTCS_407 Read with secure messaging shall be possible for all files under the DF Tachograph.\nTCS_408 The workshop card shall have the following data structure:\nTCS_409 The following values, used to provide sizes in the table above, are the minimum and maximum record number values the workshop card data structure must use:\n4.3.\nControl card structure\nTCS_410 After its personalisation, the control card shall have the following permanent file structure and file access conditions:\nTCS_411 All EFs structures shall be transparent.\nTCS_412 Read with secure messaging shall be possible for files under the DF Tachograph.\nTCS_413 The control card shall have the following data structure:\nTCS_414 The following values, used to provide sizes in the table above, are the minimum and maximum record number values the control card data structure must use:\nMin\nMax\nn 7\nNoOfControlActivityRecords\n230\n520\n4.4.\nCompany card structure\nTCS_415 After its personalisation, the company card shall have the following permanent file structure and file access conditions:\nTCS_416 All EFs structures shall be transparent.\nTCS_417 Read with secure messaging shall be possible for all files under the DF Tachograph.\nTCS_418 The company card shall have the following data structure:\nTCS_419 The following values, used to provide sizes in the table above, are the minimum and maximum record number values the company card data structure must use:\nMin\nMax\nn 8\nNoOfCompanyActivityRecords\n230\n520",
  "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": "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/2",
    "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."
}