Textual Amendments
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.
Integrated Circuit (electronic component designed to perform processing and/or memory functions)
Operating system
Personal identification number
Read only memory
Security functions policy
To be defined
Target of evaluation
TOE security function
Vehicle unit.
Recording equipment.
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.
The specific data needed to support security enforcing functions (e.g. crypto keys).
Equipment, people or organisations involved in any way with the recording equipment.
Any entity (human user or external IT entity) outside the TOE that interacts with the TOE (when not used in the expression ‘ user data ’ ).
Sensitive data stored in the tachograph card, other than security data. User data include identification data and activity data.
Identification data include card identification data and cardholder identification data.
User data related to card identification as defined by requirements 190, 191, 192, 194, 215, 231 and 235.
User data related to cardholder identification as defined by requirements 195, 196, 216, 232 and 236.
Activity data include cardholder activities data, events and faults data and control activity 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.
User data related to events or faults as defined by requirements 204, 205, 207, 208 and 223.
User data related to law enforcement controls as defined by requirements 210 and 225.
ITSEC Information Technology Security Evaluation Criteria 1991
Smartcard Integrated Circuit Protection Profile — version 2.0 — issue September 1998. Registered at French certification body under the number PP/9806
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
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.
The tachograph card life cycle conforms to smart card life cycle described in (ES PP).
In addition to the smart card general threats listed in (ES PP) and (IC PP), the tachograph card may face the following threats:
The final aim of attackers will be to modify user data stored within the TOE.
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.
A successful modification of activity data stored in the TOE would be a threat to the security of the TOE.
A successful modification of activity data (addition, deletion, modification) during import or export would be a threat to the security of the TOE.
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.
The main security objective of the entire digital tachograph system is the following:
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:
The TOE must preserve card identification data and cardholder identification data stored during card personalisation process,
The TOE must preserve user data stored in the card by vehicle units.
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:
The TOE must limit user data write access rights to authenticated vehicle units,
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.
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).
This paragraph refines some of the permitted operations such as assignment or selection of (ES PP) and provides additional SEF functional requirements.
[CPP_301] The TOE shall comply with (IC PP).
[CPP_302] The TOE shall comply with (ES PP) as refined further.
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 [F3and 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).
Textual Amendments
Assignment (FIA_UID.1.1) List of TSF mediated actions : none.
[X1Assignment (FIA_ATD.1.1) List of security attributes :
Editorial Information
:
VEHICLE_UNIT, NON_VEHICLE_UNIT,
:
Vehicle Registration Number (VRN) and registering Member State code (USER_ID is known for USER_GROUP = VEHICLE_UNIT only).]
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.
[UIA_301] 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.
[UIA_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).
[F4Additionally the following assignments describe the card reaction for each single user authentication failure.
Textual Amendments
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.
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.
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 :
:
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.]
:
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 data may be written to the TOE by VEHICLE_UNIT only.
:
No user may upgrade TOE's software.
:
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.
[ACT_301] The TOE shall hold permanent identification data.
[ACT_302] There shall be an indication of the time and date of the TOE's personalisation. This indication shall remain unalterable.
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.
Assignment (FDP_SDI.2.2) Actions to be taken : warn the entity connected,
Assignment (FDP_DAU.1.1) List of objects or information types : activity data.
Assignment (FDP_DAU.1.2) List of subjects : any.
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). U.K.
[RLB_301] The TOE's self tests shall include the verification of the integrity of any software code not stored in ROM.
[RLB_302] Upon detection of a self test error the TSF shall warn the entity connected.
[RLB_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.
[RLB_304] There shall be no way to analyse, debug or modify TOE's software in the field.
[RLB_305] Inputs from external sources shall not be accepted as executable code.
[RLB_306] The TOE shall preserve a secure state during power supply cut-off or variations.
[RLB_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.
[DEX_301] The TOE shall verify the integrity and authenticity of data imported from a vehicle unit.
[DEX_302] Upon detection of an imported data integrity error, the TOE shall:
warn the entity sending the data,
not use the data.
[DEX_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.
[DEX_304] The TOE shall be able to generate an evidence of origin for data downloaded to external media.
[DEX_305] The TOE shall be able to provide a capability to verify the evidence of origin of downloaded data to the recipient.
[DEX_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.
[CSP_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.
[CSP_302] If the TSF distributes cryptographic keys, it shall be in accordance with specified cryptographic key distribution methods.
Required security mechanisms are specified in Appendix 11.
All other security mechanisms are to be defined by the TOE manufacturer.
The minimum strength of mechanisms for the Tachograph Card is High as defined in (ITSEC).
The target level of assurance for the Tachograph Card is ITSEC level E3 , as defined in (ITSEC).
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] ] | ||||||||||||||||||