{
  "url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-10",
  "json_url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-10.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/10",
  "kind": "appendix",
  "number": "10",
  "heading": "GENERIC SECURITY TARGETS",
  "text": "This appendix specifies the minimum required content of motion sensor, vehicle unit and tachograph card security targets.\nIn order to form the security targets against which they may seek security certification, manufacturers shall refine and complete the documents as necessary, without amending nor deleting existing threats, objectives, procedural means and security enforcing functions specifications.\nMOTION SENSOR GENERIC SECURITY TARGET\n1.\nIntroduction\nThis document contains a description of the motion sensor, of the threats it must be able to counteract and of the security objectives it must achieve. It specifies the required security enforcing functions. It states the claimed minimum strength of security mechanisms and the required level of assurance for the development and the evaluation.\nRequirements referred to in the document, are those of the body of Annex I B. For clarity of reading, duplication sometimes arises between Annex I B body requirements and security target requirements. In case of ambiguity between a security target requirement and the Annex I B body requirement referred by this security target requirement, the Annex I B body requirement shall prevail.\nAnnex I B body requirements not referred by security targets are not the subject of security enforcing functions.\nUnique labels have been assigned to threats, objectives, procedural means and SEF specifications for the purpose of traceability to development and evaluation documentation.\n2.\nAbbreviations, definitions and references\n2.1.\nAbbreviations\nROM Read only Memory\nSEF Security enforcing function\nTBD To be defined\nTOE Target of evaluation\nVU Vehicle unit.\n2.2.\nDefinitions\nDigital Tachograph Recording equipment\nEntity A device connected to the motion sensor\nMotion data The data exchanged with the VU, representative of speed and distance travelled\nPhysically separated parts Physical components of the motion sensor that are distributed in the vehicle as opposed to physical components gathered into the motion sensor casing\nSecurity data The specific data needed to support security enforcing functions (e.g. crypto keys)\nSystem Equipment, people or organisations, involved in any way with the recording equipment\nUser A human user of the motion sensor (when not used in the expression ‘ user data ’ )\nUser data Any data, other than motion or security data, recorded or stored by the motion sensor.\n2.3.\nReferences\nITSEC ITSEC Information Technology Security Evaluation Criteria 1991.\n3.\nProduct rationale\n3.1.\nMotion sensor description and method of use\nThe motion sensor is intended to be installed in road transport vehicles. Its purpose is to provide a VU with secured motion data representative of vehicle's speed and distance travelled.\nThe motion sensor is mechanically interfaced to a moving part of the vehicle, which movement can be representative of vehicle's speed or distance travelled. It may be located in the vehicle's gear box or in any other part of the vehicle.\nIn its operational mode, the motion sensor is connected to a VU.\nIt may also be connected to specific equipment for management purposes (TBD by manufacturer).\nThe typical motion sensor is described in the following figure:\n3.2.\nMotion sensor life cycle\nThe typical life cycle of the motion sensor is described in the following figure:\n3.3.\nThreats\nThis paragraph describes the threats the motion sensor may face.\n3.3.1.\nThreats to access control policies\nT.Access Users could try to access functions not allowed to them.\n3.3.2.\nDesign related threats\nT.Faults Faults in hardware, software, communication procedures could place the motion sensor in unforeseen conditions compromising its security\nT.Tests The use of non invalidated test modes or of existing back doors could compromise the motion sensor security\nT.Design Users could try to gain illicit knowledge of design either from manufacturer's material (through theft, bribery, …) or from reverse engineering.\n3.3.3.\nOperation oriented threats\nT.Environment Users could compromise the motion sensor security through environmental attacks (thermal, electromagnetic, optical, chemical, mechanical, …)\nT.Hardware Users could try to modify motion sensor hardware\nT.Mechanical_Origin Users could try to manipulate the motion sensor input (e.g. unscrewing from gearbox, …)\nT.Motion_Data Users could try to modify the vehicle's motion data (addition, modification, deletion, replay of signal)\nT.Power_Supply Users could try to defeat the motion sensor security objectives by modifying (cutting, reducing, increasing) its power supply\nT.Security_Data Users could try to gain illicit knowledge of security data during security data generation or transport or storage in the equipment\nT.Software Users could try to modify motion sensor software\nT.Stored_Data Users could try to modify stored data (security or user data).\n3.4.\nSecurity objectives\nThe main security objective of the digital tachograph system is the following:\nO.Main The data to be checked by control authorities must be available and reflect fully and accurately the activities of controlled drivers and vehicles in terms of driving, work, availability and rest periods and in terms of vehicle speed\nTherefore the security objective of the motion sensor, contributing to the global security objective, is:\nO.Sensor_Main The data transmitted by the motion sensor must be available to the VU so as to allow the VU to determine fully and accurately the movement of the vehicle in terms of speed and distance travelled.\n3.5.\nInformation technology security objectives\nThe specific IT security objectives of the motion sensor contributing to its main security objective, are the following:\nO.Access The motion sensor must control connected entities' access to functions and data\nO.Audit The motion sensor must audit attempts to undermine its security and should trace them to associated entities\nO.Authentication The motion sensor must authenticate connected entities\nO.Processing The motion sensor must ensure that processing of input to derive motion data is accurate\nO.Reliability The motion sensor must provide a reliable service\nO.Secured_Data_Exchange The motion sensor must secure data exchanges with the VU.\n3.6.\nPhysical, personnel or procedural means\nThis paragraph describes physical, personnel or procedural requirements that contribute to the security of the motion sensor.\n3.6.1.\nEquipment design\nM.Development Motion sensor developers must ensure that the assignment of responsibilities during development is done in a manner which maintains IT security\nM.Manufacturing Motion sensor manufacturers must ensure that the assignment of responsibilities during manufacturing is done in a manner which maintains IT security, and that during the manufacturing process the motion sensor is protected from physical attacks which might compromise IT security.\n3.6.2.\nEquipment delivery\nM.Delivery Motion sensor manufacturers, vehicle manufacturers and fitters or workshops must ensure that handling of the motion sensor is done in a manner which maintains IT security.\n3.6.3.\nSecurity data generation and delivery\nM.Sec_Data_Generation Security data generation algorithms must be accessible to authorised and trusted persons only\nM.Sec_Data_Transport Security data must be generated, transported, and inserted into the motion sensor, in such a way to preserve its appropriate confidentiality and integrity.\n3.6.4.\nRecording equipment installation, calibration, and inspection\nM.Approved_Workshops Installation, calibration and repair of recording equipment must be carried by trusted and approved fitters or workshops\nM.Mechanical_Interface Means of detecting physical tampering with the mechanical interface must be provided (e.g. seals)\nM.Regular_Inpections Recording equipment must be periodically inspected and calibrated.\n3.6.5.\nLaw enforcement control\nM.Controls Law enforcement controls must be performed regularly and randomly, and must include security audits.\n3.6.6.\nSoftware upgrades\nM.Software_Upgrade Software revisions must be granted security certification before they can be implemented in a motion sensor.\n4.\nSecurity enforcing functions\n4.1.\nIdentification and authentication\nUIA_101 The motion sensor shall be able to establish, for every interaction, the identity of any entity it is connected to.\nUIA_102 The identity of a connected entity shall consist of:\nan entity group:\nVU,\nManagement device,\nOther,\nan entity ID (VU only).\nUIA_103 The entity ID of a connected VU shall consist of the VU approval number and the VU serial number.\nUIA_104 The motion sensor shall be able to authenticate any VU or management device it is connected to:\nat entity connection,\nat power supply recovery.\nUIA_105 The motion sensor shall be able to periodically re-authenticate the VU it is connected to.\nUIA_106 The motion sensor shall detect and prevent use of authentication data that has been copied and replayed.\nUIA_107 After (TBD by manufacturer and not more than 20) consecutive unsuccessful authentication attempts have been detected, the SEF shall:\ngenerate an audit record of the event,\nwarn the entity,\ncontinue to export motion data in a non secured mode.\n4.2.\nAccess control\nAccess controls ensure that information is read from, created in, or modified into the TOE only by those authorised to do so.\n4.2.1.\nAccess control policy\nACC_101 The motion sensor shall control access rights to function and data.\n4.2.2.\nData access rights\nACC_102 The motion sensor shall ensure that motion sensor identification data can be written once only (requirement 078).\nACC_103 The motion sensor shall accept and/or store user data from authenticated entities only.\nACC_104 The motion sensor shall enforce appropriate read and write access rights to security data.\n4.2.3.\nFile structure and access conditions\nACC_105 Application and data files structure and access conditions shall be created during the manufacturing process, and then locked from any future modification or deletion.\n4.3.\nAccountability\nACT_101 The motion sensor shall hold in its memory motion sensor identification data (requirement 077).\nACT_102 The motion sensor shall store in its memory installation data (requirement 099).\nACT_103 The motion sensor shall have a capability to output accountability data to authenticated entities at their request.\n4.4.\nAudit\nAUD_101 The motion sensor shall, for events impairing its security, generate audit records of the events.\nAUD_102 The events affecting the security of the motion sensor are the following:\nsecurity breach attempts,\nauthentication failure,\nstored data integrity error,\ninternal data transfer error,\nunauthorised case opening,\nhardware sabotage.\nsensor fault.\nAUD_103 Audit records shall include the following data:\ndate and time of the event,\ntype of event,\nconnected entity identity.\nwhen required data is not available, an appropriate default indication shall be given (TBD by manufacturer).\nAUD_104 The motion sensor shall send the generated audit records to the VU at the moment of their generation, and may also store them in its memory.\nAUD_105 In the case where the motion sensor stores audit records, it shall ensure that 20 audit records will be maintained independent of audit storage exhaustion, and shall have a capability to output stored audit records to authenticated entities at their request.\n4.5.\nAccuracy\n4.5.1.\nInformation flow control policy\nACR_101 The motion sensor shall ensure that motion data may only been processed and derived from sensor mechanical input.\n4.5.2.\nInternal data transfers\nThe requirements of this paragraph apply only if the motion sensor makes use of physically separated parts.\nACR_102 If data are transferred between physically separated parts of the motion sensor, the data shall be protected from modification.\nACR_103 Upon detection of a data transfer error during an internal transfer, transmission shall be repeated and the SEF shall generate an audit record of the event.\n4.5.3.\nStored data integrity\nACR_104 The motion sensor shall check user data stored in its memory for integrity errors.\nACR_105 Upon detection of a stored user data integrity error, the SEF shall generate an audit record.\n4.6.\nReliability of service\n4.6.1\nTests\nRLB_101 All commands, actions, or test points, specific to the testing needs of the manufacturing phase shall be disabled or removed before the end of the manufacturing phase. It shall not be possible to restore them for later use.\nRLB_102 The motion sensor shall run self-tests, during initial start-up, and during normal operation to verify its correct operation. The motion sensor self-tests shall include a verification of the integrity of security data and a verification of the integrity of stored executable code (if not in ROM).\nRLB_103 Upon detection of an internal fault during self-test, the SEF shall generate an audit record (sensor fault).\n4.6.2.\nSoftware\nRLB_104 There shall be no way to analyse or debug the motion sensor software in the field.\nRLB_105 Inputs from external sources shall not be accepted as executable code.\n4.6.3.\nPhysical protection\nRLB_106 If the motion sensor is designed so that it can be opened, the motion sensor shall detect any case opening, even without external power supply for a minimum of 6 months. In such a case, the SEF shall generate an audit record of the event (It is acceptable that the audit record is generated and stored after power supply reconnection).\nIf the motion sensor is designed so that it cannot be opened, it shall be designed such that physical tampering attempts can be easily detected (e.g. through visual inspection).\nRLB_107 The motion sensor shall detect specified (TBD by manufacturer) hardware sabotage.\nRLB_108 In the case described above, the SEF shall generate an audit record and the motion sensor shall: (TBD by manufacturer).\n4.6.4.\nPower supply interruptions\nRLB_109 The motion sensor shall preserve a secure state during power supply cut-off or variations.\n4.6.5.\nReset conditions\nRLB_110 In case of a power supply interruption, or if a transaction is stopped before completion, or on any other reset conditions, the motion sensor shall be reset cleanly.\n4.6.6.\nData availability\nRLB_111 The motion sensor shall ensure that access to resources is obtained when required and that resources are not requested nor retained unnecessarily.\n4.6.7.\nMultiple applications\nRLB_112 If the motion sensor provides applications other than the tachograph application, all applications shall be physically and/or logically separated from each other. These applications shall not share security data. Only one task shall be active at a time.\n4.7.\nData exchange\nDEX_101 The motion sensor shall export motion data to the VU with associated security attributes, such that the VU will be able to verify its integrity and authenticity.\n4.8.\nCryptographic support\nThe requirements of this paragraph are applicable only where needed, depending upon security mechanisms used and upon the manufacturer's solutions.\nCSP_101 Any cryptographic operation performed by the motion sensor shall be in accordance with a specified algorithm and a specified key size.\nCSP_102 If the motion sensor generates cryptographic keys, it shall be in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes.\nCSP_103 If the motion sensor distributes cryptographic keys, it shall be in accordance with specified key distribution methods.\nCSP_104 If the motion sensor accesses cryptographic keys, it shall be in accordance with specified cryptographic keys access methods.\nCSP_105 If the motion sensor destroys cryptographic keys, it shall be in accordance with specified cryptographic keys destruction methods.\n5.\nDefinition of security mechanisms\nThe security mechanisms, fulfilling the motion sensor security enforcing functions, are defined by the motion sensor manufacturers.\n6.\nMinimum strength of security mechanisms\nThe minimum strength of the motion sensor security mechanisms is High, as defined in (ITSEC).\n7.\nLevel of assurance\nThe target level of assurance for the motion sensor is ITSEC level E3, as defined in (ITSEC).\n8.\nRationale\nThe following matrixes give a rationale for the SEFs by showing:\nwhich SEFs or means counteract which threats,\nwhich SEFs fulfil which IT security objectives.\nThreats\nIT Objectives\nAccess\nFaults\nTests\nDesign\nEnvironment\nHardware\nMechanical_Origin\nMotion_Data\nPower_Supply\nSecurity_Data\nSoftware\nStored_Data\nAccess\nAudit\nAuthentication\nProcessing\nReliability\nSecured_Data_Exchange\nPhysical Personnel Procedural means\nDevelopment\nx\nx\nx\nManufacturing\nx\nx\nDelivery\nx\nx\nx\nSecurity Data Generation\nx\nSecurity Data Transport\nx\nApproved Workshops\nx\nMechanical interface\nx\nRegular Inspection\nx\nx\nx\nx\nLaw enforcement controls\nx\nx\nx\nx\nx\nx\nSoftware Upgrades\nx\nSecurity Enforcing Functions\nIdentification and authentication\nUIA_101 Entities identification\nx\nx\nx\nx\nx\nUIA_102 Entities identity\nx\nx\nx\nUIA_103 VU identity\nx\nUIA_104 Entities authentication\nx\nx\nx\nx\nx\nUIA_105 re-authentication\nx\nx\nx\nx\nx\nUIA_106 Unforgeable authentication\nx\nx\nx\nx\nUIA_107 Authentication failure\nx\nx\nx\nAccess control\nACC_101 Access control policy\nx\nx\nx\nx\nACC_102 Motion sensor ID\nx\nx\nACC_103 User data\nx\nx\nACC_104 Security Data\nx\nx\nx\nACC_105 File structure and access conditions\nx\nx\nx\nx\nAccountability\nACT_101 Motion sensor ID data\nx\nACT_102 Pairing data\nx\nACT_103 Accountability data\nx\nAudit\nAUD_101 Audit records\nx\nAUD_102 Audit events list\nx\nx\nx\nx\nx\nAUD_103 Audit data\nx\nAUD_104 Audit tools\nx\nAUD_105 Audit records storage\nx\nAccuracy\nACR_101 Information flow control policy\nx\nx\nx\nACR_102 Internal transfers\nx\nx\nACR_103 Internal transfers\nx\nACR_104 Stored data integrity\nx\nx\nACR_105 Stored data integrity\nx\nx\nReliability\nRLB_101 Manufacturing tests\nx\nx\nx\nRLB_102 Self tests\nx\nx\nx\nx\nx\nRLB_103 Self tests\nx\nx\nx\nx\nRLB_104 Software analysis\nx\nx\nx\nRLB_105 Software input\nx\nx\nx\nRLB_106 Case opening\nx\nx\nx\nx\nx\nx\nx\nRLB_107 Hardware sabotage\nx\nx\nRLB_108 Hardware sabotage\nx\nx\nRLB_109 Power supply interruptions\nx\nx\nRLB_110 Reset\nx\nx\nRLB_111 Data Availability\nx\nx\nRLB_112 Multiple Applications\nx\nData exchange\nDEX_101 Secured motion data export\nx\nx\nCryptographic support\nCSP_101 Algorithms\nx\nx\nCSP_102 key generation\nx\nx\nCSP_103 key distribution\nx\nx\nCSP_104 key access\nx\nx\nCSP_105 key destruction\nx\nx\nVEHICLE UNIT GENERIC SECURITY TARGET\n1.\nIntroduction\nThis document contains a description of the vehicle unit, of the threats it must be able to counteract and of the security objectives it must achieve. It specifies the required security enforcing functions. It states the claimed minimum strength of security mechanisms and the required level of assurance for the development and the evaluation.\nRequirements referred to in the document, are those of the body of Annex I B. For clarity of reading, duplication sometimes arises between Annex I B body requirements and security target requirements. In case of ambiguity between a security target requirement and the Annex I B body requirement referred by this security target requirement, the Annex I B body requirement shall prevail.\nAnnex I B body requirements not referred by security targets are not the subject of security enforcing functions.\nUnique labels have been assigned to threats, objectives, procedural means and SEF specifications for the purpose of traceability to development and evaluation documentation.\n2.\nAbbreviations, definitions and references\n2.1.\nAbbreviations\nPIN Personal identification number\nROM Read only memory\nSEF Security enforcing function\nTBD To be defined\nTOE Target of evaluation\nVU Vehicle Unit.\n2.2.\nDefinitions\nDigital tachograph Recording equipment\nMotion data The data exchanged with the motion sensor, representative of speed and distance travelled\nPhysically separated parts Physical components of the VU that are distributed in the vehicle as opposed to physical components gathered into the VU casing\nSecurity data The specific data needed to support security enforcing functions (e.g. crypto keys)\nSystem Equipment, people or organisations, involved in any way with the recording equipment\nUser Users are to be understood as human user of the equipment. Normal users of the VU comprise drivers, controllers, workshops and companies\nUser data Any data, other than security data, recorded or stored by the VU, required by Chapter III.12.\n2.3.\nReferences\nITSEC ITSEC Information Technology Security Evaluation Criteria 1991.\n3.\nProduct rationale\n3.1.\nVehicle unit description and method of use\nThe VU is intended to be installed in road transport vehicles. Its purpose is to record, store, display, print and output data related to driver activities.\nIt is connected to a motion sensor with which it exchanges vehicle's motion data.\nUsers identify themselves to the VU using tachograph cards.\nThe VU records and stores user activities data in its data memory, it also records user activities data in tachograph cards.\nThe VU outputs data to display, printer and external devices.\nThe vehicle unit's operational environment while installed in a vehicle is described in the following figure:\nThe VU general characteristics, functions and mode of operations are described in Chapter II of Annex I B.\nThe VU functional requirements are specified in Chapter III of Annex I B.\nThe typical VU is described in the following figure:\nIt must be noted that although the printer mechanism is part of the TOE, the paper document once produced is not.\n3.2.\nVehicle unit life cycle\nThe typical life cycle of the VU is described in the following figure:\n3.3.\nThreats\nThis paragraph describes the threats the VU may face.\n3.3.1.\nThreats to identification and access control policies\nT.Access Users could try to access functions not allowed to them (e.g. drivers gaining access to calibration function)\nT.Identification Users could try to use several identifications or no identification.\n3.3.2.\nDesign related threats\nT.Faults Faults in hardware, software, communication procedures could place the VU in unforeseen conditions compromising its security\nT.Tests The use of non invalidated test modes or of existing back doors could compromise the VU security\nT.Design Users could try to gain illicit knowledge of design either from manufacturer's material (through theft, bribery, …) or from reverse engineering\n3.3.3.\nOperation oriented threats\nT.Calibration_Parameters Users could try to use mis-calibrated equipment (through calibration data modification, or through organisational weaknesses)\nT.Card_Data_Exchange Users could try to modify data while exchanged between VU and tachograph cards (addition, modification, deletion, replay of signal)\nT.Clock Users could try to modify internal clock\nT.Environment Users could compromise the VU security through environmental attacks (thermal, electromagnetic, optical, chemical, mechanical, …)\nT.Fake_Devices Users could try to connect fake devices (motion sensor, smart cards) to the VU\nT.Hardware Users could try to modify VU hardware\nT.Motion_Data Users could try to modify the vehicle's motion data (addition, modification, deletion, replay of signal)\nT.Non_Activated Users could use non activated equipment\nT.Output_Data Users could try to modify data output (print, display or download)\nT.Power_Supply Users could try to defeat the VU security objectives by modifying (cutting, reducing, increasing) its power supply\nT.Security_Data Users could try to gain illicit knowledge of security data during security data generation or transport or storage in the equipment\nT.Software Users could try to modify VU software\nT.Stored_Data Users could try to modify stored data (security or user data).\n3.4.\nSecurity objectives\nThe main security objective of the digital tachograph system is the following:\nO.Main The data to be checked by control authorities must be available and reflect fully and accurately the activities of controlled drivers and vehicles in terms of driving, work, availability and rest periods and in terms of vehicle speed\nTherefore the security objectives of the VU, contributing to the global security objective, are the following:\nO.VU_Main The data to be measured and recorded and then to be checked by control authorities must be available and reflect accurately the activities of controlled drivers and vehicles in terms of driving, work, availability and rest periods and in terms of vehicle speed\nO.VU_Export The VU must be able to export data to external storage media in such a way as to allow for verification of their integrity and authenticity.\n3.5.\nInformation technology security objectives\nThe specific IT security objectives of the VU contributing to its main security objectives, are the following:\nO.Access The VU must control user access to functions and data\nO.Accountability The VU must collect accurate accountability data\nO.Audit The VU must audit attempts to undermine system security and should trace them to associated users\nO.Authentication The VU should authenticate users and connected entities (when a trusted path needs to be established between entities)\nO.Integrity The VU must maintain stored data integrity\nO.Output The VU must ensure that data output reflects accurately data measured or stored\nO.Processing The VU must ensure that processing of inputs to derive user data is accurate\nO.Reliability The VU must provide a reliable service\nO.Secured_Data_Exchange The VU must secure data exchanges with the motion sensor and with tachograph cards.\n3.6.\nPhysical, personnel or procedural means\nThis paragraph describes physical, personnel or procedural requirements that contribute to the security of the VU.\n3.6.1.\nEquipment design\nM.Development VU developers must ensure that the assignment of responsibilities during development is done in a manner which maintains IT security\nM.Manufacturing VU manufacturers must ensure that the assignment of responsibilities during manufacturing is done in a manner which maintains IT security, and that during the manufacturing process the VU is protected from physical attacks which might compromise IT security.\n3.6.2.\nEquipment delivery and activation\nM.Delivery VU manufacturers, vehicle manufacturers and fitters or workshops must ensure that handling of non activated VUs is done in a manner which maintains VU security\nM.Activation Vehicle manufacturers and fitters or workshops must activate the VU after its installation before the vehicle leaves the premises where installation took place.\n3.6.3.\nSecurity data generation and delivery\nM.Sec_Data_Generation Security data generation algorithms must be accessible to authorised and trusted persons only\nM.Sec_Data_Transport Security data must be generated, transported, and inserted into the VU, in such a way to preserve its appropriate confidentiality and integrity.\n3.6.4.\nCards delivery\nM.Card_Availability Tachograph cards must be available and delivered to authorised persons only\nM.Driver_Card_Uniqueness Drivers must possess, at one time, one valid driver card only\nM.Card_Traceability Card delivery must be traceable (white lists, black lists), and black lists must be used during security audits.\n3.6.5.\nRecording equipment installation, calibration, and inspection\nM.Approved_Workshops Installation, calibration and repair of recording equipment must be carried by trusted and approved fitters or workshops\nM.Regular_Inpections Recording equipment must be periodically inspected and calibrated\nM.Faithful_Calibration Approved fitters and workshops must enter proper vehicle parameters in recording equipment during calibration.\n3.6.6.\nEquipment operation\nM.Faithful_Drivers Drivers must play by the rules and act responsibly (e.g. use their driver cards, properly select their activity for those that are manually selected, …).\n3.6.7.\nLaw enforcement control\nM.Controls Law enforcement controls must be performed regularly and randomly, and must include security audits.\n3.6.8.\nSoftware upgrades\nM.Software_Upgrade Software revisions must be granted security certification before they can be implemented in a VU.\n4.\nSecurity enforcing functions\n4.1.\nIdentification and authentication\n4.1.1.\nMotion sensor identification and authentication\nUIA_201 The VU shall be able to establish, for every interaction, the identity of the motion sensor it is connected to.\nUIA_202 The identity of the motion sensor shall consist of the sensor approval number and the sensor serial number.\nUIA_203 The VU shall authenticate the motion sensor it is connected to:\nat motion sensor connection,\nat each calibration of the recording equipment,\nat power supply recovery.\nAuthentication shall be mutual and triggered by the VU.\nUIA_204 The VU shall periodically (period TBD by manufacturer and more frequently than once per hour) re-identify and re-authenticate the motion sensor it is connected to, and ensure that the motion sensor identified during the last calibration of the recording equipment has not been changed.\nUIA_205 The VU shall detect and prevent use of authentication data that has been copied and replayed.\nUIA_206 After (TBD by manufacturer and not more than 20) consecutive unsuccessful authentication attempts have been detected, and/or after detecting that the identity of the motion sensor has changed while not authorised (i.e. while not during a calibration of the recording equipment), the SEF shall:\ngenerate an audit record of the event,\nwarn the user,\ncontinue to accept and use non secured motion data sent by the motion sensor.\n4.1.2.\nUser identification and authentication\nUIA_207 The VU shall permanently and selectively track the identity of two users, by monitoring the tachograph cards inserted in respectively the driver slot and the co-driver slot of the equipment.\nUIA_208 The user identity shall consist of:\na user group:\nDRIVER (driver card),\nCONTROLLER (control card),\nWORKSHOP (workshop card),\nCOMPANY (company card),\nUNKNOWN (no card inserted),\na user ID, composed of:\nthe card issuing Member State code and of the card number,\nUNKNOWN if user group is UNKNOWN.\nUNKNOWN identities may be implicitly or explicitly known.\nUIA_209 The VU shall authenticate its users at card insertion.\nUIA_210 The VU shall re-authenticate its users:\nat power supply recovery,\nperiodically or after occurrence of specific events (TBD by manufacturers and more frequently than once per day).\nUIA_211 Authentication shall be performed by means of proving that the card inserted is a valid tachograph card, possessing security data that only the system could distribute. Authentication shall be mutual and triggered by the VU.\nUIA_212 In addition to the above, workshops shall be required to be successfully authenticated through a PIN check. PINs shall be at least 4 characters long.\nNote: In the case the PIN is transferred to the VU from an outside equipment located in the vicinity of the VU, PIN confidentiality need not be protected during the transfer.\nUIA_213 The VU shall detect and prevent use of authentication data that has been copied and replayed.\nUIA_214 After 5 consecutive unsuccessful authentication attempts have been detected, the SEF shall:\ngenerate an audit record of the event,\nwarn the user,\nassume the user as UNKNOWN, and the card as non valid (definition z) and requirement 007).\n4.1.3.\nRemotely connected company identification and authentication\nCompany remote connection capability is optional. This paragraph therefore applies only if this feature is implemented.\nUIA_215 For every interaction with a remotely connected company, the VU shall be able to establish the company's identity.\nUIA_216 The remotely connected company's identity shall consist of its company card issuing Member State code and of its company card number.\nUIA_217 The VU shall successfully authenticate the remotely connected company before allowing any data export to it.\nUIA_218 Authentication shall be performed by means of proving that the company owns a valid company card, possessing security data that only the system could distribute.\nUIA_219 The VU shall detect and prevent use of authentication data that has been copied and replayed.\nUIA_220 After 5 consecutive unsuccessful authentication attempts have been detected, the VU shall:\nwarn the remotely connected company.\n4.1.4.\nManagement device identification and authentication\nVU manufacturers may foresee dedicated devices for additional VU management functions (e.g. Software upgrading, security data reloading, …). This paragraph therefore applies only if this feature is implemented.\nUIA_221 For every interaction with a management device, the VU shall be able to establish the device identity.\nUIA_222 Before allowing any further interaction, the VU shall successfully authenticate the management device.\nUIA_223 The VU shall detect and prevent use of authentication data that has been copied and replayed.\n4.2.\nAccess control\nAccess controls ensure that information is read from, created in, or modified into the TOE only by those authorised to do so.\nIt must be noted that the user data recorded by the VU, although presenting privacy or commercial sensitivity aspects, are not of a confidential nature. Therefore, the functional requirement related to data read access rights (requirement 011) is not the subject of a security enforcing function.\n4.2.1.\nAccess control policy\nACC_201 The VU shall manage and check access control rights to functions and to data.\n4.2.2.\nAccess rights to functions\nACC_202 The VU shall enforce the mode of operation selection rules (requirements 006 to 009).\nACC_203 The VU shall use the mode of operation to enforce the functions access control rules (requirement 010).\n4.2.3.\nAccess rights to data\nACC_204 The VU shall enforce the VU identification data write access rules (requirement 076)\nACC_205 The VU shall enforce the paired motion sensor identification data write access rules (requirements 079 and 155)\nACC_206 After the VU activation, the VU shall ensure that only in calibration mode, may calibration data be input into the VU and stored into its data memory (requirements 154 and 156).\nACC_207 After the VU activation, the VU shall enforce calibration data write and delete access rules (requirement 097).\nACC_208 After the VU activation, the VU shall ensure that only in calibration mode, may time adjustment data be input into the VU and stored into its data memory (This requirement does not apply to small time adjustments allowed by requirements 157 and 158).\nACC_209 After the VU activation, the VU shall enforce time adjustment data write and delete access rules (requirement 100).\nACC_210 The VU shall enforce appropriate read and write access rights to security data (requirement 080).\n4.2.4.\nFile structure and access conditions\nACC_211 Application and data files structure and access conditions shall be created during the manufacturing process, and then locked from any future modification or deletion.\n4.3.\nAccountability\nACT_201 The VU shall ensure that drivers are accountable for their activities (requirements 081, 084, 087, 105a, 105b, 109 and 109a).\nACT_202 The VU shall hold permanent identification data (requirement 075).\nACT_203 The VU shall ensure that workshops are accountable for their activities (requirements 098, 101 and 109).\nACT_204 The VU shall ensure that controllers are accountable for their activities (requirements 102, 103 and 109).\nACT_205 The VU shall record odometer data (requirement 090) and detailed speed data (requirement 093).\nACT_206 The VU shall ensure that user data related to requirements 081 to 093 and 102 to 105b inclusive are not modified once recorded, except when becoming oldest stored data to be replaced by new data.\nACT_207 The VU shall ensure that it does not modify data already stored in a tachograph card (requirements 109 and 109a) except for replacing oldest data by new data (requirement 110) or in the case described in Appendix 1 Paragraph 2.1 Note.\n4.4.\nAudit\nAudit capabilities are required only for events that may indicate a manipulation or a security breach attempt. It is not required for the normal exercising of rights even if relevant to security.\nAUD_201 The VU shall, for events impairing the security of the VU, record those events with associated data (requirements 094, 096 and 109).\nAUD_202 The events affecting the security of the VU are the following:\nSecurity breach attempts,\nmotion sensor authentication failure,\ntachograph card authentication failure,\nunauthorised change of motion sensor,\ncard data input integrity error,\nstored user data integrity error,\ninternal data transfer error,\nunauthorised case opening,\nhardware sabotage,\nlast card session not correctly closed,\nmotion data error event,\npower supply interruption event,\nVU internal fault.\nAUD_203 The VU shall enforce audit records storage rules (requirement 094 and 096).\nAUD_204 The VU shall store audit records generated by the motion sensor in its data memory.\nAUD_205 It shall be possible to print, display and download audit records.\n4.5.\nObject re-use\nREU_201 The VU shall ensure that temporary storage objects can be re-used without this involving inadmissible information flow.\n4.6.\nAccuracy\n4.6.1.\nInformation flow control policy\nACR_201 The VU shall ensure that user data related to requirements 081, 084, 087, 090, 093, 102, 104, 105, 105a and 109 may only be processed from the right input sources:\nvehicle motion data,\nVU's real time clock,\nrecording equipment calibration parameters,\ntachograph cards,\nuser's inputs.\nACR_201a The VU shall ensure that user data related to requirement 109a may only be entered for the period last card withdrawal — current insertion (requirement 050a).\n4.6.2.\nInternal data transfers\nThe requirements of this paragraph apply only if the VU makes use of physically separated parts.\nACR_202 If data are transferred between physically separated parts of the VU, the data shall be protected from modification.\nACR_203 Upon detection of a data transfer error during an internal transfer, transmission shall be repeated and the SEF shall generate an audit record of the event.\n4.6.3.\nStored data integrity\nACR_204 The VU shall check user data stored in the data memory for integrity errors.\nACR_205 Upon detection of a stored user data integrity error, the SEF shall generate an audit record.\n4.7.\nReliability of service\n4.7.1.\nTests\nRLB_201 All commands, actions or test points, specific to the testing needs of the manufacturing phase of the VU shall be disabled or removed before the VU activation. It shall not be possible to restore them for later use.\nRLB_202 The VU shall run self tests, during initial start-up, and during normal operation to verify its correct operation. The VU self tests shall include a verification of the integrity of security data and a verification of the integrity of stored executable code (if not in ROM).\nRLB_203 Upon detection of an internal fault during self test, the SEF shall:\ngenerate an audit record (except in calibration mode) (VU internal fault),\nPreserve the stored data integrity.\n4.7.2.\nSoftware\nRLB_204 There shall be no way to analyse or debug software in the field after the VU activation.\nRLB_205 Inputs from external sources shall not be accepted as executable code.\n4.7.3.\nPhysical protection\nRLB_206 If the VU is designed so that it can be opened, the VU shall detect any case opening, except in calibration mode, even without external power supply for a minimum of six months. In such a case, the SEF shall generate an audit record (It is acceptable that the audit record is generated and stored after power supply reconnection).\nIf the VU is designed so that it cannot be opened, it shall be designed such that physical tampering attempts can be easily detected (e.g. through visual inspection).\nRLB_207 After its activation, the VU shall detect specified (TBD by manufacturer) hardware sabotage.\nRLB_208 In the case described above, the SEF shall generate an audit record and the VU shall: (TBD by manufacturer).\n4.7.4.\nPower supply interruptions\nRLB_209 The VU shall detect deviations from the specified values of the power supply, including cut-off.\nRLB_210 In the case described above, the SEF shall:\ngenerate an audit record (except in calibration mode),\npreserve the secure state of the VU,\nmaintain the security functions, related to components or processes still operational,\npreserve the stored data integrity.\n4.7.5.\nReset conditions\nRLB_211 In case of a power supply interruption, or if a transaction is stopped before completion, or on any other reset conditions, the VU shall be reset cleanly.\n4.7.6.\nData availability\nRLB_212 The VU shall ensure that access to resources is obtained when required and that resources are not requested nor retained unnecessarily.\nRLB_213 The VU must ensure that cards cannot be released before relevant data have been stored to them (requirements 015 and 016)\nRLB_214 In the case described above, the SEF shall generate an audit record of the event.\n4.7.7.\nMultiple applications\nRLB_215 If the VU provides applications other than the tachograph application, all applications shall be physically and/or logically separated from each other. These applications shall not share security data. Only one task shall be active at a time.\n4.8.\nData exchange\nThis paragraph addresses data exchange between the VU and connected devices.\n4.8.1.\nData exchange with motion sensor\nDEX_201 The VU shall verify the integrity and authenticity of motion data imported from the motion sensor\nDEX_202 Upon detection of a motion data integrity or authenticity error, the SEF shall:\ngenerate an audit record,\ncontinue to use imported data.\n4.8.2.\nData exchange with tachograph cards\nDEX_203 The VU shall verify the integrity and authenticity of data imported from tachograph cards.\nDEX_204 Upon detection of card data integrity or authenticity error, the VU shall:\ngenerate an audit record,\nnot use the data.\nDEX_205 The VU shall export data to tachograph smart cards with associated security attributes such that the card will be able to verify its integrity and authenticity.\n4.8.3.\nData exchange with external storage media (downloading function)\nDEX_206 The VU shall generate an evidence of origin for data downloaded to external media.\nDEX_207 The VU shall provide a capability to verify the evidence of origin of downloaded data to the recipient.\nDEX_208 The VU shall download data to external storage media with associated security attributes such that downloaded data integrity and authenticity can be verified.\n4.9.\nCryptographic support\nThe requirements of this paragraph are applicable only where needed, depending upon security mechanisms used and upon the manufacturer's solutions.\nCSP_201 Any cryptographic operation performed by the VU shall be in accordance with a specified algorithm and a specified key size.\nCSP_202 If the VU generates cryptographic keys, it shall be in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes.\nCSP_203 If the VU distributes cryptographic keys, it shall be in accordance with specified key distribution methods.\nCSP_204 If the VU accesses cryptographic keys, it shall be in accordance with specified cryptographic keys access methods.\nCSP_205 If the VU destroys cryptographic keys, it shall be in accordance with specified cryptographic keys destruction methods.\n5.\nDefinition of security mechanisms\nRequired security mechanisms are specified in Appendix 11.\nAll other security mechanisms are to be defined by manufacturers.\n6.\nMinimum strength of security mechanisms\nThe minimum strength of the Vehicle Unit security mechanisms is High , as defined in (ITSEC).\n7.\nLevel of assurance\nThe target level of assurance for the Vehicle Unit is ITSEC level E3, as defined in (ITSEC).\n8.\nRationale\nThe following matrixes give a rationale for the SEFs by showing:\nwhich SEFs or means counteract which threats,\nwhich SEFs fulfil which IT security objectives.\nTACHOGRAPH CARD GENERIC SECURITY TARGET\n1.\nIntroduction\nThis document contains a description of the tachograph card, of the threats it must be able to counteract and of the security objectives it must achieve. It specifies the required security enforcing functions. It states the claimed minimum strength of security mechanisms, and the required level of assurance for the development and the evaluation.\nRequirements referred to in the document, are those of the body of Annex I B. For clarity of reading, duplication sometimes arises between Annex I B body requirements and security target requirements. In case of ambiguity between a security target requirement and the Annex I B requirement referred by this security target requirement, the Annex I B body requirement shall prevail.\nAnnex I B body requirements not referred by security targets are not the subject of security enforcing functions.\nA tachograph card is a standard smart card carrying a dedicated tachograph application, and shall comply with up-to-date functional and assurance security requirements applicable to smart cards. This security target therefore incorporates only the extra security requirements needed by the tachograph application.\nUnique labels have been assigned to threats, objectives, procedural means and SEF specifications for the purpose of traceability to development and evaluation documentation.\n2.\nAbbreviations, definitions and references\n2.1.\nAbbreviations\nIC Integrated Circuit (electronic component designed to perform processing and/or memory functions)\nOS Operating system\nPIN Personal identification number\nROM Read only memory\nSFP Security functions policy\nTBD To be defined\nTOE Target of evaluation\nTSF TOE security function\nVU Vehicle unit.\n2.2.\nDefinitions\nDigital tachograph Recording equipment.\nSensitive data Data stored by the tachograph card that need to be protected for integrity, unauthorised modification and confidentiality (where applicable for security data). Sensitive data includes security data and user data.\nSecurity data The specific data needed to support security enforcing functions (e.g. crypto keys).\nSystem Equipment, people or organisations involved in any way with the recording equipment.\nUser Any entity (human user or external IT entity) outside the TOE that interacts with the TOE (when not used in the expression ‘ user data ’ ).\nUser data Sensitive data stored in the tachograph card, other than security data. User data include identification data and activity data.\nIdentification data Identification data include card identification data and cardholder identification data.\nCard identification data User data related to card identification as defined by requirements 190, 191, 192, 194, 215, 231 and 235.\nCardholder identification data User data related to cardholder identification as defined by requirements 195, 196, 216, 232 and 236.\nActivity data Activity data include cardholder activities data, events and faults data and control activity data.\nCardholder activities data User data related to the activities carried by the cardholder as defined by requirements 197, 199, 202, 212, 212a, 217, 219, 221, 226, 227, 229, 230a, 233 and 237.\nEvents and faults data User data related to events or faults as defined by requirements 204, 205, 207, 208 and 223.\nControl activity data User data related to law enforcement controls as defined by requirements 210 and 225.\n2.3.\nReferences\nITSEC ITSEC Information Technology Security Evaluation Criteria 1991\nIC PP Smartcard Integrated Circuit Protection Profile — version 2.0 — issue September 1998. Registered at French certification body under the number PP/9806\nES PP Smart Card Integrated Circuit With Embedded Software Protection Profile — version 2.0 — issue June 99. Registered at French certification body under the number PP/9911\n3.\nProduct Rationale\n3.1.\nTachograph card description and method of use\nA tachograph card is a smart card, as described in (IC PP) and (ES PP), carrying an application intended for its use with the recording equipment.\nThe basic functions of the tachograph card are:\nto store card identification and card holder identification data. These data are used by the vehicle unit to identify the cardholder, provide accordingly functions and data access rights, and ensure cardholder accountability for his activities,\nto store cardholder activities data, events and faults data and control activities data, related to the cardholder.\nA tachograph card is therefore intended to be used by a card interface device of a vehicle unit. It may also be used by any card reader (e.g. of a personal computer) which shall have full read access right on any user data.\nDuring the end-usage phase of a tachograph card life cycle (phase 7 of life-cycle as described in (ES PP)), vehicle units only may write user data to the card.\nThe functional requirements for a tachograph card are specified in Annex I B body text and Appendix 2.\n3.2.\nTachograph card life cycle\nThe tachograph card life cycle conforms to smart card life cycle described in (ES PP).\n3.3.\nThreats\nIn addition to the smart card general threats listed in (ES PP) and (IC PP), the tachograph card may face the following threats:\n3.3.1.\nFinal aims\nThe final aim of attackers will be to modify user data stored within the TOE.\nT.Ident_Data A successful modification of identification data held by the TOE (e.g. the type of card, or the card expiry date or the cardholder identification data) would allow a fraudulent use of the TOE and would be a major threat to the global security objective of the system.\nT.Activity_Data A successful modification of activity data stored in the TOE would be a threat to the security of the TOE.\nT.Data_Exchange A successful modification of activity data (addition, deletion, modification) during import or export would be a threat to the security of the TOE.\n3.3.2.\nAttack paths\nTOE's assets may be attacked by:\ntrying to gain illicit knowledge of TOE's hardware and software design and especially of its security functions or security data. Illicit knowledge may be gained though attacks to designer or manufacturer material (theft, bribery, …) or through direct examination of the TOE (physical probing, inference analysis, …),\ntaking advantage of weaknesses in TOE design or realisation (exploit errors in hardware, errors in software, transmission faults, errors induced in TOE by environmental stress, exploit weaknesses of security functions such as authentication procedures, data access control, cryptographic operations, …),\nmodifying the TOE or its security functions through physical, electrical or logical attacks or combination of these.\n3.4.\nSecurity Objectives\nThe main security objective of the entire digital tachograph system is the following:\nO.Main The data to be checked by control authorities must be available and reflect fully and accurately the activity of controlled drivers and vehicles in terms of driving, work, availability and rest period and in terms of vehicle speed.\nTherefore the main security objectives of the TOE, contributing to this global security objective are the following:\nO.Card_Identification_Data The TOE must preserve card identification data and cardholder identification data stored during card personalisation process,\nO.Card_Activity_Storage The TOE must preserve user data stored in the card by vehicle units.\n3.5.\nInformation technology security objectives\nIn addition to the smart card general security objectives listed in (ES PP) and (IC PP), the specific IT security objectives of the TOE that contributes to its main security objectives during its end-usage life-cycle phase are the following:\nO.Data_Access The TOE must limit user data write access rights to authenticated vehicle units,\nO.Secure_Communications The TOE must be able to support secure communication protocols and procedures between the card and the card interface device when required by the application.\n3.6.\nPhysical, personnel or procedural means\nThe physical, personnel or procedural requirements that contribute to the security of the TOE are listed in (ES PP) and (IC PP) (chapters security objectives for the environment).\n4.\nSecurity enforcing functions\nThis paragraph refines some of the permitted operations such as assignment or selection of (ES PP) and provides additional SEF functional requirements.\n4.1.\nCompliance to protection profiles\nCPP_301 The TOE shall comply with (IC PP).\nCPP_302 The TOE shall comply with (ES PP) as refined further.\n4.2.\nUser identification and authentication\nThe card must identify the entity in which it is inserted and know whether it is an authenticated vehicle unit or not. The card may export any user data whatever the entity it is connected to, except the control and the company card which may export card holder identification data to authenticated vehicle units only (such that a controller is ensured that the vehicle unit is not a fake one by seeing his name on display or printouts).\n4.2.1.\nUser identification\nAssignment (FIA_UID.1.1) List of TSF mediated actions : none.\nAssignment (FIA_ATD.1.1) List of security attributes :\nUSER_GROUP VEHICLE_UNIT, NON_VEHICLE_UNIT,\nUSER_ID Vehicle Registration Number (VRN) and registering Member State code (USER_ID is known for USER_GROUP = VEHICLE_UNIT only).\n4.2.2.\nUser authentication\nAssignment (FIA_UAU.1.1) List of TSF mediated actions :\nDriver and Workshop cards: export user data with security attributes (card data download function),\nControl card: export user data without security attributes except cardholder identification data.\nUIA_301 Authentication of a vehicle unit shall be performed by means of proving that it possesses security data that only the system could distribute.\nSelection (FIA_UAU.3.1 and FIA_UAU.3.2): prevent.\nAssignment (FIA_UAU.4.1) Identified authentication mechanism(s) : any authentication mechanism.\nUIA_302 The Workshop card shall provide an additional authentication mechanism by checking a PIN code (This mechanism is intended for the vehicle unit to ensure the identity of the card holder, it is not intended to protect workshop card content).\n4.2.3.\nAuthentication failures\nAdditionally the following assignments describe the card reaction for each single user authentication failure.\nAssignment (FIA_AFL.1.1) Number : 1, list of authentication events : authentication of a card interface device.\nAssignment (FIA_AFL.1.2) List of actions :\nwarn the entity connected,\nassume the user as NON_VEHICLE_UNIT.\nAdditionally the following assignments describe the card reaction in the case of failure of the additional authentication mechanism required in UIA_302.\nAssignment (FIA_AFL.1.1) Number : 5, list of authentication events : PIN checks (workshop card).\nAssignment (FIA_AFL.1.2) List of actions :\nwarn the entity connected,\nblock the PIN check procedure such that any subsequent PIN check attempt will fail,\nbe able to indicate to subsequent users the reason of the blocking.\n4.3.\nAccess control\n4.3.1.\nAccess control policy\nDuring end-usage phase of its life cycle, the tachograph card is the subject of one single access control security function policy (SFP) named AC_SFP.\nAssignment (FDP_ACC.2.1) Access control SFP : AC_SFP.\n4.3.2.\nAccess control functions\nAssignment (FDP_ACF.1.1) Access control SFP : AC_SFP.\nAssignment (FDP_ACF.1.1) Named group of security attributes : USER_GROUP.\nAssignment (FDP_ACF.1.2) Rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects :\nGENERAL_READ User data may be read from the TOE by any user, except cardholder identification data which may be read from control cards and company cards by VEHICLE_UNIT only.\nIDENTIF_WRITE Identification data may only be written once and before the end of phase 6 of card's life-cycle. No user may write or modify identification data during end-usage phase of card's life-cycle.\nACTIVITY_WRITE Activity data may be written to the TOE by VEHICLE_UNIT only.\nSOFT_UPGRADE No user may upgrade TOE's software.\nFILE_STRUCTURE Files structure and access conditions shall be created before end of phase 6 of TOE's life-cycle and then locked from any future modification or deletion by any user.\n4.4.\nAccountability\nACT_301 The TOE shall hold permanent identification data.\nACT_302 There shall be an indication of the time and date of the TOE's personalisation. This indication shall remain unalterable.\n4.5.\nAudit\nThe TOE must monitor events that indicate a potential violation of its security.\nAssignment (FAU_SAA.1.2) Subset of defined auditable events:\ncardholder authentication failure (5 consecutive unsuccessful PIN checks),\nself test error,\nstored data integrity error,\nactivity data input integrity error.\n4.6.\nAccuracy\n4.6.1.\nStored data integrity\nAssignment (FDP_SDI.2.2) Actions to be taken : warn the entity connected,\n4.6.2.\nBasic data authentication\nAssignment (FDP_DAU.1.1) List of objects or information types : activity data.\nAssignment (FDP_DAU.1.2) List of subjects : any.\n4.7.\nReliability of service\n4.7.1.\nTests\nSelection (FPT_TST.1.1): during initial start-up, periodically during normal operation.\nNote: during initial start-up means before code is executed (and not necessarily during Answer To Reset procedure).\nRLB_301 The TOE's self tests shall include the verification of the integrity of any software code not stored in ROM.\nRLB_302 Upon detection of a self test error the TSF shall warn the entity connected.\nRLB_303 After OS testing is completed, all testing-specific commands and actions shall be disabled or removed. It shall not be possible to override these controls and restore them for use. Command associated exclusively with one life cycle state shall never be accessed during another state.\n4.7.2.\nSoftware\nRLB_304 There shall be no way to analyse, debug or modify TOE's software in the field.\nRLB_305 Inputs from external sources shall not be accepted as executable code.\n4.7.3.\nPower supply\nRLB_306 The TOE shall preserve a secure state during power supply cut-off or variations.\n4.7.4.\nReset conditions\nRLB_307 If power is cut (or if power variations occur) from the TOE, or if a transaction is stopped before completion, or on any other reset conditions, the TOE shall be reset cleanly.\n4.8.\nData exchange\n4.8.1.\nData exchange with a vehicle unit\nDEX_301 The TOE shall verify the integrity and authenticity of data imported from a vehicle unit.\nDEX_302 Upon detection of an imported data integrity error, the TOE shall:\nwarn the entity sending the data,\nnot use the data.\nDEX_303 The TOE shall export user data to the vehicle unit with associated security attributes, such that the vehicle unit will be able to verify the integrity and authenticity of data received.\n4.8.2.\nExport of data to a non-vehicle unit (download function)\nDEX_304 The TOE shall be able to generate an evidence of origin for data downloaded to external media.\nDEX_305 The TOE shall be able to provide a capability to verify the evidence of origin of downloaded data to the recipient.\nDEX_306 The TOE shall be able to download data to external storage media with associated security attributes such that downloaded data integrity can be verified.\n4.9.\nCryptographic support\nCSP_301 If the TSF generates cryptographic keys, it shall be in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes. Generated cryptographic session keys shall have a limited (TBD by manufacturer and not more than 240) number of possible use.\nCSP_302 If the TSF distributes cryptographic keys, it shall be in accordance with specified cryptographic key distribution methods.\n5.\nDefinition of security mechanisms\nRequired security mechanisms are specified in Appendix 11.\nAll other security mechanisms are to be defined by the TOE manufacturer.\n6.\nClaimed minimum strength of mechanisms\nThe minimum strength of mechanisms for the Tachograph Card is High as defined in (ITSEC).\n7.\nLevel of Assurance\nThe target level of assurance for the Tachograph Card is ITSEC level E3 , as defined in (ITSEC).\n8.\nRationale\nThe following matrixes give a rationale for the additional SEFs by showing:\nwhich SEFs counteract which threats,\nwhich SEFs fulfil which IT security objectives.\nThreats\nIT Objectives\nT.CLON*\nT.DIS_ES2\nT.T_ES\nT.T_CMD\nT.MOD_SOFT*\nT.MOD_LOAD\nT.MOD_EXE\nT.MOD_SHARE\nIdent_Data\nActivity_Data\nData_Exchange\nO.TAMPER_ES\nO.CLON*\nO.OPERATE*\nO.FLAW*\nO.DIS_MECHANISM2\nO.DIS_MEMORY*\nO.MOD_MEMORY*\nData_Access\nSecured_Communications\nUIA_301 Authentication means\nx\nUIA_302 PIN checks\nx\nACT_301 Identification data\nACT_302 Personalisation date\nRLB_301 Software integrity\nx\nx\nRLB_302 Self tests\nx\nx\nRLB_303 Manufacturing tests\nx\nx\nx\nx\nRLB_304 Software analysis\nx\nx\nx\nx\nx\nRLB_305 Software input\nx\nx\nx\nx\nx\nRLB_306 Power supply\nx\nx\nx\nx\nRLB_307 Reset\nx\nx\nDEX_301 Secured data import\nx\nx\nDEX_302 Secured data import\nx\nx\nDEX_303 Secured data export to VU\nx\nx\nDEX_304 Evidence of origin\nx\nx\nDEX_305 Evidence of origin\nx\nx\nDEX_306 Secured export to external media\nx\nx\nCSP_301 key generation\nx\nx\nCSP_302 key distribution\nx\nx",
  "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": "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": "F",
      "label": "F4",
      "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/10",
    "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."
}