ANNEX I B

REQUIREMENTS FOR CONSTRUCTION, TESTING, INSTALLATION AND INSPECTION
Appendix 10

GENERIC SECURITY TARGETS
This appendix specifies the minimum required content of motion sensor, vehicle unit and tachograph card security targets.
In 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.

MOTION SENSOR GENERIC SECURITY TARGET
1.

Introduction
This 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.
Requirements 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.
Annex I B body requirements not referred by security targets are not the subject of security enforcing functions.
Unique labels have been assigned to threats, objectives, procedural means and SEF specifications for the purpose of traceability to development and evaluation documentation.
2.

Abbreviations, definitions and references
2.1.

Abbreviations
ROM
- Read only Memory
SEF
- Security enforcing function
TBD
- To be defined
TOE
- Target of evaluation
VU
- Vehicle unit.
2.2.

Definitions
Digital Tachograph
- Recording equipment
Entity
- A device connected to the motion sensor
Motion data
- The data exchanged with the VU, representative of speed and distance travelled
Physically 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
Security data
- The specific data needed to support security enforcing functions (e.g. crypto keys)
System
- Equipment, people or organisations, involved in any way with the recording equipment
User
- A human user of the motion sensor (when not used in the expression
‘
user data
’ )
User data
- Any data, other than motion or security data, recorded or stored by the motion sensor.
2.3.

References
ITSEC
- ITSEC Information Technology Security Evaluation Criteria 1991.
3.

Product rationale
3.1.

Motion sensor description and method of use
The 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.
The 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.
In its operational mode, the motion sensor is connected to a VU.
It may also be connected to specific equipment for management purposes (TBD by manufacturer).
The typical motion sensor is described in the following figure:
3.2.

Motion sensor life cycle
The typical life cycle of the motion sensor is described in the following figure:
3.3.

Threats
This paragraph describes the threats the motion sensor may face.
3.3.1.

Threats to access control policies
T.Access
- Users could try to access functions not allowed to them.
3.3.2.

Design related threats
T.Faults
- Faults in hardware, software, communication procedures could place the motion sensor in unforeseen conditions compromising its security
T.Tests
- The use of non invalidated test modes or of existing back doors could compromise the motion sensor security
T.Design
- Users could try to gain illicit knowledge of design either from manufacturer's material (through theft, bribery, …) or from reverse engineering.
3.3.3.

Operation oriented threats
T.Environment
- Users could compromise the motion sensor security through environmental attacks (thermal, electromagnetic, optical, chemical, mechanical, …)
T.Hardware
- Users could try to modify motion sensor hardware
T.Mechanical_Origin
- Users could try to manipulate the motion sensor input (e.g. unscrewing from gearbox, …)
T.Motion_Data
- Users could try to modify the vehicle's motion data (addition, modification, deletion, replay of signal)
T.Power_Supply
- Users could try to defeat the motion sensor security objectives by modifying (cutting, reducing, increasing) its power supply
T.Security_Data
- Users could try to gain illicit knowledge of security data during security data generation or transport or storage in the equipment
T.Software
- Users could try to modify motion sensor software
T.Stored_Data
- Users could try to modify stored data (security or user data).
3.4.

Security objectives
The main security objective of the digital tachograph system is the following:
O.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
Therefore the security objective of the motion sensor, contributing to the global security objective, is:
O.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.
3.5.

Information technology security objectives
The specific IT security objectives of the motion sensor contributing to its main security objective, are the following:
O.Access
- The motion sensor must control connected entities' access to functions and data
O.Audit
- The motion sensor must audit attempts to undermine its security and should trace them to associated entities
O.Authentication
- The motion sensor must authenticate connected entities
O.Processing
- The motion sensor must ensure that processing of input to derive motion data is accurate
O.Reliability
- The motion sensor must provide a reliable service
O.Secured_Data_Exchange
- The motion sensor must secure data exchanges with the VU.
3.6.

Physical, personnel or procedural means
This paragraph describes physical, personnel or procedural requirements that contribute to the security of the motion sensor.
3.6.1.

Equipment design
M.Development
- Motion sensor developers must ensure that the assignment of responsibilities during development is done in a manner which maintains IT security
M.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.
3.6.2.

Equipment delivery
M.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.
3.6.3.

Security data generation and delivery
M.Sec_Data_Generation
- Security data generation algorithms must be accessible to authorised and trusted persons only
M.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.
3.6.4.

Recording equipment installation, calibration, and inspection
M.Approved_Workshops
- Installation, calibration and repair of recording equipment must be carried by trusted and approved fitters or workshops
M.Mechanical_Interface
- Means of detecting physical tampering with the mechanical interface must be provided (e.g. seals)
M.Regular_Inpections
- Recording equipment must be periodically inspected and calibrated.
3.6.5.

Law enforcement control
M.Controls
- Law enforcement controls must be performed regularly and randomly, and must include security audits.
3.6.6.

Software upgrades
M.Software_Upgrade
- Software revisions must be granted security certification before they can be implemented in a motion sensor.
4.

Security enforcing functions
4.1.

Identification and authentication
The motion sensor shall be able to establish, for every interaction, the identity of any entity it is connected to.
The identity of a connected entity shall consist of:
- an entity group:
  - VU,
  - Management device,
  - Other,
- an entity ID (VU only).
The entity ID of a connected VU shall consist of the VU approval number and the VU serial number.
The motion sensor shall be able to authenticate any VU or management device it is connected to:
- at entity connection,
- at power supply recovery.
The motion sensor shall be able to periodically re-authenticate the VU it is connected to.
The motion sensor shall detect and prevent use of authentication data that has been copied and replayed.
After (TBD by manufacturer and not more than 20) consecutive unsuccessful authentication attempts have been detected, the SEF shall:
- generate an audit record of the event,
- warn the entity,
- continue to export motion data in a non secured mode.
4.2.

Access control
Access controls ensure that information is read from, created in, or modified into the TOE only by those authorised to do so.
4.2.1.

Access control policy
The motion sensor shall control access rights to function and data.
4.2.2.

Data access rights
The motion sensor shall ensure that motion sensor identification data can be written once only (requirement 078).
The motion sensor shall accept and/or store user data from authenticated entities only.
The motion sensor shall enforce appropriate read and write access rights to security data.
4.2.3.

File structure and access conditions
Application and data files structure and access conditions shall be created during the manufacturing process, and then locked from any future modification or deletion.
4.3.

Accountability
The motion sensor shall hold in its memory motion sensor identification data (requirement 077).
The motion sensor shall store in its memory installation data (requirement 099).
The motion sensor shall have a capability to output accountability data to authenticated entities at their request.
4.4.

Audit
The motion sensor shall, for events impairing its security, generate audit records of the events.
The events affecting the security of the motion sensor are the following:
- security breach attempts,
  - authentication failure,
  - stored data integrity error,
  - internal data transfer error,
  - unauthorised case opening,
  - hardware sabotage.
- sensor fault.
Audit records shall include the following data:
- date and time of the event,
- type of event,
- connected entity identity.
when required data is not available, an appropriate default indication shall be given (TBD by manufacturer).
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.
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.
4.5.

Accuracy
4.5.1.

Information flow control policy
The motion sensor shall ensure that motion data may only been processed and derived from sensor mechanical input.
4.5.2.

Internal data transfers
The requirements of this paragraph apply only if the motion sensor makes use of physically separated parts.
If data are transferred between physically separated parts of the motion sensor, the data shall be protected from modification.
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.
4.5.3.

Stored data integrity
The motion sensor shall check user data stored in its memory for integrity errors.
Upon detection of a stored user data integrity error, the SEF shall generate an audit record.
4.6.

Reliability of service
4.6.1

Tests
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.
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).
Upon detection of an internal fault during self-test, the SEF shall generate an audit record (sensor fault).
4.6.2.

Software
There shall be no way to analyse or debug the motion sensor software in the field.
Inputs from external sources shall not be accepted as executable code.
4.6.3.

Physical protection
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).
If 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).
The motion sensor shall detect specified (TBD by manufacturer) hardware sabotage.
In the case described above, the SEF shall generate an audit record and the motion sensor shall: (TBD by manufacturer).
4.6.4.

Power supply interruptions
The motion sensor shall preserve a secure state during power supply cut-off or variations.
4.6.5.

Reset conditions
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.
4.6.6.

Data availability
The motion sensor shall ensure that access to resources is obtained when required and that resources are not requested nor retained unnecessarily.
4.6.7.

Multiple applications
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.
4.7.

Data exchange
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.
4.8.

Cryptographic support
The requirements of this paragraph are applicable only where needed, depending upon security mechanisms used and upon the manufacturer's solutions.
Any cryptographic operation performed by the motion sensor shall be in accordance with a specified algorithm and a specified key size.
If the motion sensor generates cryptographic keys, it shall be in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes.
If the motion sensor distributes cryptographic keys, it shall be in accordance with specified key distribution methods.
If the motion sensor accesses cryptographic keys, it shall be in accordance with specified cryptographic keys access methods.
If the motion sensor destroys cryptographic keys, it shall be in accordance with specified cryptographic keys destruction methods.
5.

Definition of security mechanisms
The security mechanisms, fulfilling the motion sensor security enforcing functions, are defined by the motion sensor manufacturers.
6.

Minimum strength of security mechanisms
The minimum strength of the motion sensor security mechanisms is High, as defined in (ITSEC).
7.

Level of assurance
The target level of assurance for the motion sensor is ITSEC level E3, as defined in (ITSEC).
8.

Rationale
The following matrixes give a rationale for the SEFs by showing:
- which SEFs or means counteract which threats,
- which SEFs fulfil which IT security objectives.
| Threats | IT Objectives
Access | Faults | Tests | Design | Environment | Hardware | Mechanical_Origin | Motion_Data | Power_Supply | Security_Data | Software | Stored_Data | Access | Audit | Authentication | Processing | Reliability | Secured_Data_Exchange
Physical Personnel Procedural means
Development | | x | x | x | | | | | | | | | | | | | |
Manufacturing | | | x | x | | | | | | | | | | | | | |
Delivery | | | | | | x | | | | | x | x | | | | | |
Security Data Generation | | | | | | | | | | x | | | | | | | |
Security Data Transport | | | | | | | | | | x | | | | | | | |
Approved Workshops | | | | | | | x | | | | | | | | | | |
Mechanical interface | | | | | | | x | | | | | | | | | | |
Regular Inspection | | | | | | x | x | | x | | x | | | | | | |
Law enforcement controls | | | | | x | x | x | | x | x | x | | | | | | |
Software Upgrades | | | | | | | | | | | x | | | | | | |
Security Enforcing Functions
Identification and authentication
UIA_101 Entities identification | x | | | | | | | x | | | | | x | | x | | | x
UIA_102 Entities identity | x | | | | | | | | | | | | x | | x | | |
UIA_103 VU identity | | | | | | | | | | | | | | x | | | |
UIA_104 Entities authentication | x | | | | | | | x | | | | | x | | x | | | x
UIA_105 re-authentication | x | | | | | | | x | | | | | x | | x | | | x
UIA_106 Unforgeable authentication | x | | | | | | | x | | | | | x | | x | | |
UIA_107 Authentication failure | | | | | | | | x | | | | | | x | | | x |
Access control
ACC_101 Access control policy | x | | | | | | | | | x | | x | x | | | | |
ACC_102 Motion sensor ID | | | | | | | | | | | | x | x | | | | |
ACC_103 User data | | | | | | | | | | | | x | x | | | | |
ACC_104 Security Data | | | | | | | | | | x | | x | x | | | | |
ACC_105 File structure and access conditions | x | | | | | | | | | x | | x | x | | | | |
Accountability
ACT_101 Motion sensor ID data | | | | | | | | | | | | | | x | | | |
ACT_102 Pairing data | | | | | | | | | | | | | | x | | | |
ACT_103 Accountability data | | | | | | | | | | | | | | x | | | |
Audit
AUD_101 Audit records | | | | | | | | | | | | | | x | | | |
AUD_102 Audit events list | x | | | | x | x | | | | | | x | | x | | | |
AUD_103 Audit data | | | | | | | | | | | | | | x | | | |
AUD_104 Audit tools | | | | | | | | | | | | | | x | | | |
AUD_105 Audit records storage | | | | | | | | | | | | | | x | | | |
Accuracy
ACR_101 Information flow control policy | | | | | | | | x | | | | | | | | x | x |
ACR_102 Internal transfers | | | | | | | | | | | | | | | | x | x |
ACR_103 Internal transfers | | | | | | | | | | | | | | x | | | |
ACR_104 Stored data integrity | | | | | | | | | | | | x | | | | | x |
ACR_105 Stored data integrity | | | | | | | | | | | | x | | x | | | |
Reliability
RLB_101 Manufacturing tests | | | x | x | | | | | | | | | | | | | x |
RLB_102 Self tests | | x | | | | x | | | x | | x | | | | | | x |
RLB_103 Self tests | | | | | | x | | | x | | x | | | x | | | |
RLB_104 Software analysis | | | | x | | | | | | | x | | | | | | x |
RLB_105 Software input | | | | | | | | | | | x | | | | | x | x |
RLB_106 Case opening | | | | x | x | x | | | | x | x | x | | | | | x |
RLB_107 Hardware sabotage | | | | | | x | | | | | | | | | | | x |
RLB_108 Hardware sabotage | | | | | | x | | | | | | | | x | | | |
RLB_109 Power supply interruptions | | | | | | | | | x | | | | | | | | x |
RLB_110 Reset | | x | | | | | | | | | | | | | | | x |
RLB_111 Data Availability | | | | | | | | | | | | | | | | x | x |
RLB_112 Multiple Applications | | | | | | | | | | | | | | | | | x |
Data exchange
DEX_101 Secured motion data export | | | | | | | | x | | | | | | | | | | x
Cryptographic support
CSP_101 Algorithms | | | | | | | | | | | | | | | | | x | x
CSP_102 key generation | | | | | | | | | | | | | | | | | x | x
CSP_103 key distribution | | | | | | | | | | | | | | | | | x | x
CSP_104 key access | | | | | | | | | | | | | | | | | x | x
CSP_105 key destruction | | | | | | | | | | | | | | | | | x | x

VEHICLE UNIT GENERIC SECURITY TARGET
1.

Introduction
This 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.
Requirements 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.
Annex I B body requirements not referred by security targets are not the subject of security enforcing functions.
Unique labels have been assigned to threats, objectives, procedural means and SEF specifications for the purpose of traceability to development and evaluation documentation.
2.

Abbreviations, definitions and references
2.1.

Abbreviations
PIN
- Personal identification number
ROM
- Read only memory
SEF
- Security enforcing function
TBD
- To be defined
TOE
- Target of evaluation
VU
- Vehicle Unit.
2.2.

Definitions
Digital tachograph
- Recording equipment
Motion data
- The data exchanged with the motion sensor, representative of speed and distance travelled
Physically separated parts
- Physical components of the VU that are distributed in the vehicle as opposed to physical components gathered into the VU casing
Security data
- The specific data needed to support security enforcing functions (e.g. crypto keys)
System
- Equipment, people or organisations, involved in any way with the recording equipment
User
- Users are to be understood as human user of the equipment. Normal users of the VU comprise drivers, controllers, workshops and companies
User data
- Any data, other than security data, recorded or stored by the VU, required by Chapter III.12.
2.3.

References
ITSEC
- ITSEC Information Technology Security Evaluation Criteria 1991.
3.

Product rationale
3.1.

Vehicle unit description and method of use
The 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.
It is connected to a motion sensor with which it exchanges vehicle's motion data.
Users identify themselves to the VU using tachograph cards.
The VU records and stores user activities data in its data memory, it also records user activities data in tachograph cards.
The VU outputs data to display, printer and external devices.
The vehicle unit's operational environment while installed in a vehicle is described in the following figure:
The VU general characteristics, functions and mode of operations are described in Chapter II of Annex I B.
The VU functional requirements are specified in Chapter III of Annex I B.
The typical VU is described in the following figure:
It must be noted that although the printer mechanism is part of the TOE, the paper document once produced is not.
3.2.

Vehicle unit life cycle
The typical life cycle of the VU is described in the following figure:
3.3.

Threats
This paragraph describes the threats the VU may face.
3.3.1.

Threats to identification and access control policies
T.Access
- Users could try to access functions not allowed to them (e.g. drivers gaining access to calibration function)
T.Identification
- Users could try to use several identifications or no identification.
3.3.2.

Design related threats
T.Faults
- Faults in hardware, software, communication procedures could place the VU in unforeseen conditions compromising its security
T.Tests
- The use of non invalidated test modes or of existing back doors could compromise the VU security
T.Design
- Users could try to gain illicit knowledge of design either from manufacturer's material (through theft, bribery, …) or from reverse engineering
3.3.3.

Operation oriented threats
T.Calibration_Parameters
- Users could try to use mis-calibrated equipment (through calibration data modification, or through organisational weaknesses)
T.Card_Data_Exchange
- Users could try to modify data while exchanged between VU and tachograph cards (addition, modification, deletion, replay of signal)
T.Clock
- Users could try to modify internal clock
T.Environment
- Users could compromise the VU security through environmental attacks (thermal, electromagnetic, optical, chemical, mechanical, …)
T.Fake_Devices
- Users could try to connect fake devices (motion sensor, smart cards) to the VU
T.Hardware
- Users could try to modify VU hardware
T.Motion_Data
- Users could try to modify the vehicle's motion data (addition, modification, deletion, replay of signal)
T.Non_Activated
- Users could use non activated equipment
T.Output_Data
- Users could try to modify data output (print, display or download)
T.Power_Supply
- Users could try to defeat the VU security objectives by modifying (cutting, reducing, increasing) its power supply
T.Security_Data
- Users could try to gain illicit knowledge of security data during security data generation or transport or storage in the equipment
T.Software
- Users could try to modify VU software
T.Stored_Data
- Users could try to modify stored data (security or user data).
3.4.

Security objectives
The main security objective of the digital tachograph system is the following:
O.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
Therefore the security objectives of the VU, contributing to the global security objective, are the following:
O.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
O.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.
3.5.

Information technology security objectives
The specific IT security objectives of the VU contributing to its main security objectives, are the following:
O.Access
- The VU must control user access to functions and data
O.Accountability
- The VU must collect accurate accountability data
O.Audit
- The VU must audit attempts to undermine system security and should trace them to associated users
O.Authentication
- The VU should authenticate users and connected entities (when a trusted path needs to be established between entities)
O.Integrity
- The VU must maintain stored data integrity
O.Output
- The VU must ensure that data output reflects accurately data measured or stored
O.Processing
- The VU must ensure that processing of inputs to derive user data is accurate
O.Reliability
- The VU must provide a reliable service
O.Secured_Data_Exchange
- The VU must secure data exchanges with the motion sensor and with tachograph cards.
3.6.

Physical, personnel or procedural means
This paragraph describes physical, personnel or procedural requirements that contribute to the security of the VU.
3.6.1.

Equipment design
M.Development
- VU developers must ensure that the assignment of responsibilities during development is done in a manner which maintains IT security
M.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.
3.6.2.

Equipment delivery and activation
M.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
M.Activation
- Vehicle manufacturers and fitters or workshops must activate the VU after its installation before the vehicle leaves the premises where installation took place.
3.6.3.

Security data generation and delivery
M.Sec_Data_Generation
- Security data generation algorithms must be accessible to authorised and trusted persons only
M.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.
3.6.4.

Cards delivery
M.Card_Availability
- Tachograph cards must be available and delivered to authorised persons only
M.Driver_Card_Uniqueness
- Drivers must possess, at one time,
one
valid driver card only
M.Card_Traceability
- Card delivery must be traceable (white lists, black lists), and black lists must be used during security audits.
3.6.5.

Recording equipment installation, calibration, and inspection
M.Approved_Workshops
- Installation, calibration and repair of recording equipment must be carried by trusted and approved fitters or workshops
M.Regular_Inpections
- Recording equipment must be periodically inspected and calibrated
M.Faithful_Calibration
- Approved fitters and workshops must enter proper vehicle parameters in recording equipment during calibration.
3.6.6.

Equipment operation
M.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, …).
3.6.7.

Law enforcement control
M.Controls
- Law enforcement controls must be performed regularly and randomly, and must include security audits.
3.6.8.

Software upgrades
M.Software_Upgrade
- Software revisions must be granted security certification before they can be implemented in a VU.
4.

Security enforcing functions
4.1.

Identification and authentication
4.1.1.

Motion sensor identification and authentication
The VU shall be able to establish, for every interaction, the identity of the motion sensor it is connected to.
The identity of the motion sensor shall consist of the sensor approval number and the sensor serial number.
The VU shall authenticate the motion sensor it is connected to:
- at motion sensor connection,
- at each calibration of the recording equipment,
- at power supply recovery.
Authentication shall be mutual and triggered by the VU.
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.
The VU shall detect and prevent use of authentication data that has been copied and replayed.
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:
- generate an audit record of the event,
- warn the user,
- continue to accept and use non secured motion data sent by the motion sensor.
4.1.2.

User identification and authentication
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.
The user identity shall consist of:
- a user group:
  - DRIVER (driver card),
  - CONTROLLER (control card),
  - WORKSHOP (workshop card),
  - COMPANY (company card),
  - UNKNOWN (no card inserted),
- a user ID, composed of:
  - the card issuing Member State code and of the card number,
  - UNKNOWN if user group is UNKNOWN.
UNKNOWN identities may be implicitly or explicitly known.
The VU shall authenticate its users at card insertion.
The VU shall re-authenticate its users:
- at power supply recovery,
- periodically or after occurrence of specific events (TBD by manufacturers and more frequently than once per day).
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.
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.
Note: 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.
The VU shall detect and prevent use of authentication data that has been copied and replayed.
After 5 consecutive unsuccessful authentication attempts have been detected, the SEF shall:
- generate an audit record of the event,
- warn the user,
- assume the user as UNKNOWN, and the card as non valid (definition z) and requirement 007).
4.1.3.

Remotely connected company identification and authentication
Company remote connection capability is optional. This paragraph therefore applies only if this feature is implemented.
For every interaction with a remotely connected company, the VU shall be able to establish the company's identity.
The remotely connected company's identity shall consist of its company card issuing Member State code and of its company card number.
The VU shall successfully authenticate the remotely connected company before allowing any data export to it.
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.
The VU shall detect and prevent use of authentication data that has been copied and replayed.
After 5 consecutive unsuccessful authentication attempts have been detected, the VU shall:
- warn the remotely connected company.
4.1.4.

Management device identification and authentication
VU 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.
For every interaction with a management device, the VU shall be able to establish the device identity.
Before allowing any further interaction, the VU shall successfully authenticate the management device.
The VU shall detect and prevent use of authentication data that has been copied and replayed.
4.2.

Access control
Access controls ensure that information is read from, created in, or modified into the TOE only by those authorised to do so.
It 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.
4.2.1.

Access control policy
The VU shall manage and check access control rights to functions and to data.
4.2.2.

Access rights to functions
The VU shall enforce the mode of operation selection rules (requirements 006 to 009).
The VU shall use the mode of operation to enforce the functions access control rules (requirement 010).
4.2.3.

Access rights to data
The VU shall enforce the VU identification data write access rules (requirement 076)
The VU shall enforce the paired motion sensor identification data write access rules (requirements 079 and 155)
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).
After the VU activation, the VU shall enforce calibration data write and delete access rules (requirement 097).
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).
After the VU activation, the VU shall enforce time adjustment data write and delete access rules (requirement 100).
The VU shall enforce appropriate read and write access rights to security data (requirement 080).
4.2.4.

File structure and access conditions
Application and data files structure and access conditions shall be created during the manufacturing process, and then locked from any future modification or deletion.
4.3.

Accountability
The VU shall ensure that drivers are accountable for their activities (requirements 081, 084, 087, 105a, 105b, 109 and 109a).
The VU shall hold permanent identification data (requirement 075).
The VU shall ensure that workshops are accountable for their activities (requirements 098, 101 and 109).
The VU shall ensure that controllers are accountable for their activities (requirements 102, 103 and 109).
The VU shall record odometer data (requirement 090) and detailed speed data (requirement 093).
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.
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.
4.4.

Audit
Audit 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.
The VU shall, for events impairing the security of the VU, record those events with associated data (requirements 094, 096 and 109).
The events affecting the security of the VU are the following:
- Security breach attempts,
  - motion sensor authentication failure,
  - tachograph card authentication failure,
  - unauthorised change of motion sensor,
  - card data input integrity error,
  - stored user data integrity error,
  - internal data transfer error,
  - unauthorised case opening,
  - hardware sabotage,
- last card session not correctly closed,
- motion data error event,
- power supply interruption event,
- VU internal fault.
The VU shall enforce audit records storage rules (requirement 094 and 096).
The VU shall store audit records generated by the motion sensor in its data memory.
It shall be possible to print, display and download audit records.
4.5.

Object re-use
The VU shall ensure that temporary storage objects can be re-used without this involving inadmissible information flow.
4.6.

Accuracy
4.6.1.

Information flow control policy
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:
- vehicle motion data,
- VU's real time clock,
- recording equipment calibration parameters,
- tachograph cards,
- user's inputs.
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).
4.6.2.

Internal data transfers
The requirements of this paragraph apply only if the VU makes use of physically separated parts.
If data are transferred between physically separated parts of the VU, the data shall be protected from modification.
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.
4.6.3.

Stored data integrity
The VU shall check user data stored in the data memory for integrity errors.
Upon detection of a stored user data integrity error, the SEF shall generate an audit record.
4.7.

Reliability of service
4.7.1.

Tests
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.
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).
Upon detection of an internal fault during self test, the SEF shall:
- generate an audit record (except in calibration mode) (VU internal fault),
- Preserve the stored data integrity.
4.7.2.

Software
There shall be no way to analyse or debug software in the field after the VU activation.
Inputs from external sources shall not be accepted as executable code.
4.7.3.

Physical protection
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).
If 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).
After its activation, the VU shall detect specified (TBD by manufacturer) hardware sabotage.
In the case described above, the SEF shall generate an audit record and the VU shall: (TBD by manufacturer).
4.7.4.

Power supply interruptions
The VU shall detect deviations from the specified values of the power supply, including cut-off.
In the case described above, the SEF shall:
- generate an audit record (except in calibration mode),
- preserve the secure state of the VU,
- maintain the security functions, related to components or processes still operational,
- preserve the stored data integrity.
4.7.5.

Reset conditions
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.
4.7.6.

Data availability
The VU shall ensure that access to resources is obtained when required and that resources are not requested nor retained unnecessarily.
The VU must ensure that cards cannot be released before relevant data have been stored to them (requirements 015 and 016)
In the case described above, the SEF shall generate an audit record of the event.
4.7.7.

Multiple applications
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.
4.8.

Data exchange
This paragraph addresses data exchange between the VU and connected devices.
4.8.1.

Data exchange with motion sensor
The VU shall verify the integrity and authenticity of motion data imported from the motion sensor
Upon detection of a motion data integrity or authenticity error, the SEF shall:
- generate an audit record,
- continue to use imported data.
4.8.2.

Data exchange with tachograph cards
The VU shall verify the integrity and authenticity of data imported from tachograph cards.
Upon detection of card data integrity or authenticity error, the VU shall:
- generate an audit record,
- not use the data.
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.
4.8.3.

Data exchange with external storage media (downloading function)
The VU shall generate an evidence of origin for data downloaded to external media.
The VU shall provide a capability to verify the evidence of origin of downloaded data to the recipient.
The VU shall download data to external storage media with associated security attributes such that downloaded data integrity and authenticity can be verified.
4.9.

Cryptographic support
The requirements of this paragraph are applicable only where needed, depending upon security mechanisms used and upon the manufacturer's solutions.
Any cryptographic operation performed by the VU shall be in accordance with a specified algorithm and a specified key size.
If the VU generates cryptographic keys, it shall be in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes.
If the VU distributes cryptographic keys, it shall be in accordance with specified key distribution methods.
If the VU accesses cryptographic keys, it shall be in accordance with specified cryptographic keys access methods.
If the VU destroys cryptographic keys, it shall be in accordance with specified cryptographic keys destruction methods.
5.

Definition of security mechanisms
Required security mechanisms are specified in Appendix 11.
All other security mechanisms are to be defined by manufacturers.
6.

Minimum strength of security mechanisms
The minimum strength of the Vehicle Unit security mechanisms is
High
, as defined in (ITSEC).
7.

Level of assurance
The target level of assurance for the Vehicle Unit is ITSEC level E3, as defined in (ITSEC).
8.

Rationale
The following matrixes give a rationale for the SEFs by showing:
- which SEFs or means counteract which threats,
- which SEFs fulfil which IT security objectives.

TACHOGRAPH CARD GENERIC SECURITY TARGET
1.

Introduction
This 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.
Requirements 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.
Annex I B body requirements not referred by security targets are not the subject of security enforcing functions.
A 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.
Unique labels have been assigned to threats, objectives, procedural means and SEF specifications for the purpose of traceability to development and evaluation documentation.
2.

Abbreviations, definitions and references
2.1.

Abbreviations
IC
- Integrated Circuit (electronic component designed to perform processing and/or memory functions)
OS
- Operating system
PIN
- Personal identification number
ROM
- Read only memory
SFP
- Security functions policy
TBD
- To be defined
TOE
- Target of evaluation
TSF
- TOE security function
VU
- Vehicle unit.
2.2.

Definitions
Digital tachograph
- Recording equipment.
Sensitive 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.
Security data
- The specific data needed to support security enforcing functions (e.g. crypto keys).
System
- Equipment, people or organisations involved in any way with the recording equipment.
User
- Any entity (human user or external IT entity) outside the TOE that interacts with the TOE (when not used in the expression
‘
user data
’ ).
User data
- Sensitive data stored in the tachograph card, other than security data. User data include identification data and activity data.
Identification data
- Identification data include card identification data and cardholder identification data.
Card identification data
- User data related to card identification as defined by requirements 190, 191, 192, 194, 215, 231 and 235.
Cardholder identification data
- User data related to cardholder identification as defined by requirements 195, 196, 216, 232 and 236.
Activity data
- Activity data include cardholder activities data, events and faults data and control activity data.
Cardholder 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.
Events and faults data
- User data related to events or faults as defined by requirements 204, 205, 207, 208 and 223.
Control activity data
- User data related to law enforcement controls as defined by requirements 210 and 225.
2.3.

References
ITSEC
- ITSEC Information Technology Security Evaluation Criteria 1991
IC PP
- Smartcard Integrated Circuit Protection Profile — version 2.0 — issue September 1998. Registered at French certification body under the number PP/9806
ES 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
3.

Product Rationale
3.1.

Tachograph card description and method of use
A 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.
The basic functions of the tachograph card are:
- to 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,
- to store cardholder activities data, events and faults data and control activities data, related to the cardholder.
A 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.
During 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.
The functional requirements for a tachograph card are specified in Annex I B body text and Appendix 2.
3.2.

Tachograph card life cycle
The tachograph card life cycle conforms to smart card life cycle described in (ES PP).
3.3.

Threats
In addition to the smart card general threats listed in (ES PP) and (IC PP), the tachograph card may face the following threats:
3.3.1.

Final aims
The final aim of attackers will be to modify user data stored within the TOE.
T.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.
T.Activity_Data
- A successful modification of activity data stored in the TOE would be a threat to the security of the TOE.
T.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.
3.3.2.

Attack paths
TOE's assets may be attacked by:
- trying 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, …),
- taking 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, …),
- modifying the TOE or its security functions through physical, electrical or logical attacks or combination of these.
3.4.

Security Objectives
The main security objective of the entire digital tachograph system is the following:
O.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.
Therefore the main security objectives of the TOE, contributing to this global security objective are the following:
O.Card_Identification_Data
- The TOE must preserve card identification data and cardholder identification data stored during card personalisation process,
O.Card_Activity_Storage
- The TOE must preserve user data stored in the card by vehicle units.
3.5.

Information technology security objectives
In 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:
O.Data_Access
- The TOE must limit user data write access rights to authenticated vehicle units,
O.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.
3.6.

Physical, personnel or procedural means
The 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).
4.

Security enforcing functions
This paragraph refines some of the permitted operations such as assignment or selection of (ES PP) and provides additional SEF functional requirements.
4.1.

Compliance to protection profiles
The TOE shall comply with (IC PP).
The TOE shall comply with (ES PP) as refined further.
4.2.

User identification and authentication
The 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).
4.2.1.

User identification
Assignment
(FIA_UID.1.1)
List of TSF mediated actions
: none.
Assignment
(FIA_ATD.1.1)
List of security attributes
:
USER_GROUP
- VEHICLE_UNIT, NON_VEHICLE_UNIT,
USER_ID
- Vehicle Registration Number (VRN) and registering Member State code (USER_ID is known for USER_GROUP = VEHICLE_UNIT only).
4.2.2.

User authentication
Assignment
(FIA_UAU.1.1)
List of TSF mediated actions
:
- Driver and Workshop cards: export user data with security attributes (card data download function),
- Control card: export user data without security attributes except cardholder identification data.
Authentication of a vehicle unit shall be performed by means of proving that it possesses security data that only the system could distribute.
Selection
(FIA_UAU.3.1 and FIA_UAU.3.2): prevent.
Assignment
(FIA_UAU.4.1)
Identified authentication mechanism(s)
: any authentication mechanism.
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).
4.2.3.

Authentication failures
Additionally the following assignments
describe the card reaction for each single user authentication failure.
Assignment
(FIA_AFL.1.1)
Number
: 1,
list of authentication events
: authentication of a card interface device.
Assignment
(FIA_AFL.1.2)
List of actions
:
- warn the entity connected,
- assume the user as NON_VEHICLE_UNIT.
Additionally the following assignments
describe the card reaction in the case of failure of the additional authentication mechanism required in UIA_302.
Assignment
(FIA_AFL.1.1)
Number
: 5,
list of authentication events
: PIN checks (workshop card).
Assignment
(FIA_AFL.1.2)
List of actions
:
- warn the entity connected,
- block the PIN check procedure such that any subsequent PIN check attempt will fail,
- be able to indicate to subsequent users the reason of the blocking.
4.3.

Access control
4.3.1.

Access control policy
During 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.
Assignment
(FDP_ACC.2.1)
Access control SFP
: AC_SFP.
4.3.2.

Access control functions
Assignment
(FDP_ACF.1.1)
Access control SFP
: AC_SFP.
Assignment
(FDP_ACF.1.1)
Named group of security attributes
: USER_GROUP.
Assignment
(FDP_ACF.1.2)
Rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects
:
GENERAL_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.
IDENTIF_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.
ACTIVITY_WRITE
- Activity data may be written to the TOE by VEHICLE_UNIT only.
SOFT_UPGRADE
- No user may upgrade TOE's software.
FILE_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.
4.4.

Accountability
The TOE shall hold permanent identification data.
There shall be an indication of the time and date of the TOE's personalisation. This indication shall remain unalterable.
4.5.

Audit
The TOE must monitor events that indicate a potential violation of its security.
Assignment
(FAU_SAA.1.2) Subset of defined auditable events:
- cardholder authentication failure (5 consecutive unsuccessful PIN checks),
- self test error,
- stored data integrity error,
- activity data input integrity error.
4.6.

Accuracy
4.6.1.

Stored data integrity
Assignment
(FDP_SDI.2.2)
Actions to be taken
: warn the entity connected,
4.6.2.

Basic data authentication
Assignment
(FDP_DAU.1.1)
List of objects or information types
: activity data.
Assignment
(FDP_DAU.1.2)
List of subjects
: any.
4.7.

Reliability of service
4.7.1.

Tests
Selection
(FPT_TST.1.1): during initial start-up, periodically during normal operation.
Note: during initial start-up means before code is executed (and not necessarily during Answer To Reset procedure).
The TOE's self tests shall include the verification of the integrity of any software code not stored in ROM.
Upon detection of a self test error the TSF shall warn the entity connected.
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.
4.7.2.

Software
There shall be no way to analyse, debug or modify TOE's software in the field.
Inputs from external sources shall not be accepted as executable code.
4.7.3.

Power supply
The TOE shall preserve a secure state during power supply cut-off or variations.
4.7.4.

Reset conditions
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.
4.8.

Data exchange
4.8.1.

Data exchange with a vehicle unit
The TOE shall verify the integrity and authenticity of data imported from a vehicle unit.
Upon detection of an imported data integrity error, the TOE shall:
- warn the entity sending the data,
- not use the data.
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.
4.8.2.

Export of data to a non-vehicle unit (download function)
The TOE shall be able to generate an evidence of origin for data downloaded to external media.
The TOE shall be able to provide a capability to verify the evidence of origin of downloaded data to the recipient.
The TOE shall be able to download data to external storage media with associated security attributes such that downloaded data integrity can be verified.
4.9.

Cryptographic support
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.
If the TSF distributes cryptographic keys, it shall be in accordance with specified cryptographic key distribution methods.
5.

Definition of security mechanisms
Required security mechanisms are specified in Appendix 11.
All other security mechanisms are to be defined by the TOE manufacturer.
6.

Claimed minimum strength of mechanisms
The minimum strength of mechanisms for the Tachograph Card is
High
as defined in (ITSEC).
7.

Level of Assurance
The target level of assurance for the Tachograph Card is ITSEC level
E3
, as defined in (ITSEC).
8.

Rationale
The following matrixes give a rationale for the additional SEFs by showing:
- which SEFs counteract which threats,
- which SEFs fulfil which IT security objectives.
| Threats | IT Objectives
T.CLON* | T.DIS_ES2 | T.T_ES | T.T_CMD | T.MOD_SOFT* | T.MOD_LOAD | T.MOD_EXE | T.MOD_SHARE | Ident_Data | Activity_Data | Data_Exchange | O.TAMPER_ES | O.CLON* | O.OPERATE* | O.FLAW* | O.DIS_MECHANISM2 | O.DIS_MEMORY* | O.MOD_MEMORY* | Data_Access | Secured_Communications
UIA_301 Authentication means | | | | | | | | | | | | | | | | | | | x |
UIA_302 PIN checks | | | | | | | | | | | | | | | | | | | x |
ACT_301 Identification data | | | | | | | | | | | | | | | | | | | |
ACT_302 Personalisation date | | | | | | | | | | | | | | | | | | | |
RLB_301 Software integrity | | | | | | | | | | | | x | | x | | | | | |
RLB_302 Self tests | | | | | | | | | | | | x | | x | | | | | |
RLB_303 Manufacturing tests | | | | | x | x | | | | | | x | | x | | | | | |
RLB_304 Software analysis | | | | | x | | x | x | | | | x | | x | | | | | |
RLB_305 Software input | | | | | x | x | | x | | | | x | | x | | | | | |
RLB_306 Power supply | | | | | | | | | x | x | | x | | x | | | | | |
RLB_307 Reset | | | | | | | | | | | | x | | x | | | | | |
DEX_301 Secured data import | | | | | | | | | | | x | | | | | | | | | x
DEX_302 Secured data import | | | | | | | | | | | x | | | | | | | | | x
DEX_303 Secured data export to VU | | | | | | | | | | | x | | | | | | | | | x
DEX_304 Evidence of origin | | | | | | | | | | | x | | | | | | | | | x
DEX_305 Evidence of origin | | | | | | | | | | | x | | | | | | | | | x
DEX_306 Secured export to external media | | | | | | | | | | | x | | | | | | | | | x
CSP_301 key generation | | | | | | | | | | | | x | | | | | | | | x
CSP_302 key distribution | | | | | | | | | | | | x | | | | | | | | x
UIA_101
UIA_102
UIA_103
UIA_104
UIA_105
UIA_106
UIA_107
ACC_101
ACC_102
ACC_103
ACC_104
ACC_105
ACT_101
ACT_102
ACT_103
AUD_101
AUD_102
AUD_103
AUD_104
AUD_105
ACR_101
ACR_102
ACR_103
ACR_104
ACR_105
RLB_101
RLB_102
RLB_103
RLB_104
RLB_105
RLB_106
RLB_107
RLB_108
RLB_109
RLB_110
RLB_111
RLB_112
DEX_101
CSP_101
CSP_102
CSP_103
CSP_104
CSP_105
UIA_201
UIA_202
UIA_203
UIA_204
UIA_205
UIA_206
UIA_207
UIA_208
UIA_209
UIA_210
UIA_211
UIA_212
UIA_213
UIA_214
UIA_215
UIA_216
UIA_217
UIA_218
UIA_219
UIA_220
UIA_221
UIA_222
UIA_223
ACC_201
ACC_202
ACC_203
ACC_204
ACC_205
ACC_206
ACC_207
ACC_208
ACC_209
ACC_210
ACC_211
ACT_201
ACT_202
ACT_203
ACT_204
ACT_205
ACT_206
ACT_207
AUD_201
AUD_202
AUD_203
AUD_204
AUD_205
REU_201
ACR_201
ACR_201a
ACR_202
ACR_203
ACR_204
ACR_205
RLB_201
RLB_202
RLB_203
RLB_204
RLB_205
RLB_206
RLB_207
RLB_208
RLB_209
RLB_210
RLB_211
RLB_212
RLB_213
RLB_214
RLB_215
DEX_201
DEX_202
DEX_203
DEX_204
DEX_205
DEX_206
DEX_207
DEX_208
CSP_201
CSP_202
CSP_203
CSP_204
CSP_205
CPP_301
CPP_302
UIA_301
UIA_302
ACT_301
ACT_302
RLB_301
RLB_302
RLB_303
RLB_304
RLB_305
RLB_306
RLB_307
DEX_301
DEX_302
DEX_303
DEX_304
DEX_305
DEX_306
CSP_301
CSP_302
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.
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).
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).
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).
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).