EFAS-4
Security Target EFAS-4.0
I m p o r t a n t n o t i c e : T h i s d o c u m e n t i s t h e p r o p e r t y o f i n t e l l i c
G e r m a n y G m b H a n d s h o u l d n o t b e c o p i e d o r d i s t r i b u t e d w i t h o u t
p e r m i s s i o n .
QM-Vorgabedoument
erstellt
von:
Cerbe/Thielisch
letzte
Änd.
QM-FB:
29.07.2009
Version
1.0
Bezeichnung:
FB
7-2.15
Spezifikation
englisch.doc
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Security Target EFAS-4.0
name of project: EFAS-4
file name: 1030-100-SEC-EN18_APPR_SecurityTargetEFAS-4.doc
version: 18
number of document: 1030-100-SEC-EN18
rendered by/at: Dr. Horst Kießling / 25.08.2010
last edited by/at: Dr. Horst Kießling / 10.11.2011
status: released
location:
project folder and net file:
Z:\_EFAS-4_1030\Zulassung\Security\EigeneDokumente\SecurityTarget\
1030-100-SEC-EN18_APPR_SecurityTargetEFAS-4.doc
Name
(in block letters):
date: signature:
prepared by: Dr. Horst Kießling 10.11.2011
reviewed by: Bernd Hoeppener 10.11.2011
approved by: Simon Veselsky 10.11.2011
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 2 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Release notes:
version date page chapter changes, notes modified by
number
of pages
00 2010-08-25 all all Initial version Dr. Horst Kießling 43
2010-08-25 all all
Adapted suggestions
from Bernd Hoeppener
and Dr. Bernd Rose
Dr. Horst Kießling 42
2010-08-26 all 9.3.1
added reasoning for
SFR-TSF mapping
Dr. Horst Kießling 49
2010-08-27 all - formal corrections Dr. B. Rose 49
01 2010-08-31 all all
integrated all pp SFSs
with ST, enhanced
rationale by SW-
Update TSFs,
amended reasoning
Dr. Horst Kießling 71
02 2010-09-01 all all
Made corrections with
respect to review
comments
Dr. Horst Kießling 72
03 2010-10-28 all all
Editorial changes,
added tables and
sections from the PP,
added additional
assets for SW-update
Dr. Horst Kießling 101
04 2010-11-04 all all
Some formal
corrections after
review
Dr. Bernd Rose 101
05 2010-11-09 all all
Editorial changes and
formal amendments
Dr. Horst Kießling 102
06 2010-11-23 all all
Added reference to
SW-Update, editorial
changes
Dr. Horst Kießling 102
10 2010-12-02 all all
SFR operations,
Added Statement of
Compatibility
Dr. Horst Kießling 110
11 2011-02-24 all all
Changes on requests
of certification body
and evaluation facility
Dr. Horst Kießling 127
12 2011-03-01 all all
Software Update
mechanism (AES)
Dr. Horst Kießling 117
13 2011-05-24 88 9.1.8
Integrity Mechanism
MAC-storage-location
Dr. Horst Kießling 118
14 2011-10-06 all all
Changes due to BSI
comments
Dr. Horst Kießling 117
15 2011-10-24 all all
SC-Processor more
precisely specified
Dr. Horst Kießling 117
16 2011-11-07 all all
Minor corrections on
SFR operations
Minor corrections on
SF.UPDATE
Dr. Horst Kießling 117
17 2011-11-07
49,
52
8.1.5.1
SFRs
FDP_ACC.1/SW-
Upgrade,
FDP_ACF.1/SW-
Upgrade corrected
Dr. Horst Kießling 117
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 3 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
18 2011-11-10 14 3.2
Bluetooth interface
does not exist
Dr. Horst Kießling 118
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 4 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Table of Contents
1 SCOPE................................................................................................................................................................8
2 ST INTRODUCTION (ASE_INT)...................................................................................................................8
2.1 ST REFERENCE................................................................................................................................................8
2.2 TOE REFERENCE.............................................................................................................................................8
2.3 TOE OVERVIEW ..............................................................................................................................................9
2.3.1 TOE Definition and Operational Usage................................................................................................9
2.3.2 TOE Major Security Features for Operational Use............................................................................10
2.3.3 TOE Type ............................................................................................................................................11
2.3.4 Non-TOE hardware/software/firmware ..............................................................................................12
3 TOE DESCRIPTION......................................................................................................................................14
3.1 ARCHITECTURE OVERVIEW ...........................................................................................................................14
3.2 TOE HARDWARE...........................................................................................................................................14
3.3 TOE SOFTWARE ............................................................................................................................................16
3.4 DETAILS OF SECURITY MECHANISMS ............................................................................................................16
3.5 TOE PRODUCT SCOPE ...................................................................................................................................17
3.6 TOE ENVIRONMENT......................................................................................................................................17
3.6.1 Development Environment..................................................................................................................17
3.6.2 Manufacturing Environment ...............................................................................................................17
3.6.3 Fitters and Workshop Environment ....................................................................................................18
3.6.4 End User Environment........................................................................................................................18
4 CONFORMANCE CLAIMS..........................................................................................................................19
4.1 CC CONFORMANCE CLAIMS..........................................................................................................................19
4.2 PP CLAIM ......................................................................................................................................................19
4.3 PACKAGE CLAIM ...........................................................................................................................................19
4.4 CONFORMANCE RATIONALE..........................................................................................................................19
5 SECURITY PROBLEM DEFINITION ........................................................................................................20
5.1 INTRODUCTION..............................................................................................................................................20
5.2 THREATS .......................................................................................................................................................24
5.3 ORGANISATIONAL SECURITY POLICIES .........................................................................................................25
5.4 ASSUMPTIONS ...............................................................................................................................................27
6 SECURITY OBJECTIVES ............................................................................................................................29
6.1 SECURITY OBJECTIVES FOR THE TOE............................................................................................................29
6.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................................30
6.3 SECURITY OBJECTIVE RATIONALE ................................................................................................................33
7 EXTENDED COMPONENTS DEFINITION ..............................................................................................37
8 SECURITY REQUIREMENTS.....................................................................................................................38
8.1 SECURITY FUNCTIONAL REQUIREMENTS.......................................................................................................38
8.1.1 Overview .............................................................................................................................................39
8.1.2 Class FAU Security Audit ...................................................................................................................43
8.1.2.1 FAU_GEN Security audit data generation.......................................................................................................43
8.1.2.2 FAU_SAR Security audit review.....................................................................................................................43
8.1.2.3 FAU_STG Security audit event storage...........................................................................................................44
8.1.3 Class FCO Communication ................................................................................................................44
8.1.3.1 FCO_NRO Non-repudiation of origin.............................................................................................................44
8.1.4 Class FCS Cryptographic Support......................................................................................................45
8.1.4.1 FCS_CKM Cryptographic key management ...................................................................................................45
8.1.4.2 FCS_COP Cryptographic operation ................................................................................................................48
8.1.5 Class FDP User Data Protection........................................................................................................49
8.1.5.1 FDP_ACC Access control policy ....................................................................................................................49
8.1.5.2 FDP_ACF Access control functions................................................................................................................51
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 5 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
8.1.5.3 FDP_ETC Export from the TOE .....................................................................................................................54
8.1.5.4 FDP_ITC Import from outside of the TOE......................................................................................................54
8.1.5.5 FDP_RIP Residual information protection......................................................................................................56
8.1.5.6 FDP_SDI Stored data integrity........................................................................................................................57
8.1.6 Class FIA Identification and Authentication.......................................................................................57
8.1.6.1 FIA_AFL Authentication failures....................................................................................................................57
8.1.6.2 FIA_ATD User attribute definition .................................................................................................................58
8.1.6.3 FIA_UAU User authentication ........................................................................................................................59
8.1.6.4 FIA_UID User identification...........................................................................................................................61
8.1.7 Class FPR Privacy ..............................................................................................................................61
8.1.7.1 FPR_UNO Unobservability.............................................................................................................................61
‘To observe the cryptographic operations’ means here ‘using any TOE external interface in order to gain the
values of cryptographic keys which shall be kept secret’..................................................................................61
8.1.8 Class FPT Protection of the TSF ........................................................................................................62
8.1.8.1 FPT_FLS Fail secure.......................................................................................................................................62
8.1.8.2 FPT_PHP TSF physical protection..................................................................................................................62
8.1.8.3 FPT_STM Time stamps...................................................................................................................................63
8.1.8.4 FPT_TDC Inter-TSF TSF Data Consistency...................................................................................................63
8.1.8.5 FPT_TST TSF self test ....................................................................................................................................63
8.1.9 Class FRU Resource Utilisation .........................................................................................................64
8.1.9.1 FRU_PRS Priority of service...........................................................................................................................64
8.1.10 Class FMT Security Management ..................................................................................................64
8.1.10.1 FMT_MSA Management of security attributes..........................................................................................64
8.1.10.2 FMT_MOF Management of functions in TSF............................................................................................66
8.1.10.3 FMT_SMF Specification of Management Functions .................................................................................66
8.1.10.4 FMT_SMR Security management roles .....................................................................................................66
8.2 SECURITY ASSURANCE REQUIREMENTS ........................................................................................................67
8.3 SECURITY REQUIREMENTS RATIONALE.........................................................................................................68
8.3.1 Security Functional Requirements Rationale......................................................................................68
8.3.2 Rationale for SFR’s Dependencies......................................................................................................71
8.3.3 Security Assurance Requirements Rationale.......................................................................................71
8.3.4 Security Requirements – Internal Consistency....................................................................................71
8.3.4.1 SFRs ................................................................................................................................................................71
8.3.4.2 SARs................................................................................................................................................................71
9 TOE SUMMARY SPECIFICATION............................................................................................................71
9.1 TOE SECURITY FUNCTIONS...........................................................................................................................71
9.1.1 SF.ACS Security Attribute Based Access Control ...............................................................................71
9.1.2 SF.SECAUDIT Audit...........................................................................................................................71
9.1.3 SF.EX_CONF Confidentiality of Data Exchange ...............................................................................71
9.1.4 SF.EX_INT Integrity and Authenticity of Data Exchange...................................................................71
9.1.5 SF.GEN_SKEYS Generation of Session Keys .....................................................................................71
9.1.6 SF.GEN_DIGSIG Generation of Digital Signatures optionally with Encryption ...............................71
9.1.7 SF.VER_DIGSIG Verification of Digital Signatures optionally with Decryption...............................71
9.1.8 SF.DATA_INT Stored Data Integrity Monitoring and Action............................................................71
9.1.9 SF.IA_KEY Key Based User / TOE Authentication.............................................................................71
9.1.10 SF.INF_PROT Residual Information Protection...........................................................................71
9.1.11 SF.FAIL_PROT Failure and Tampering Protection ......................................................................71
9.1.12 SF.SELFTEST Self Test..................................................................................................................71
9.1.13 SF.UPDATE VU Software Upgrade...............................................................................................71
9.2 ASSURANCE MEASURES ................................................................................................................................71
9.3 TOE SUMMARY SPECIFICATION RATIONALE.................................................................................................71
9.3.1 Security Functions Rationale ..............................................................................................................71
9.3.2 Assurance Measures Rationale ...........................................................................................................71
10 STATEMENT OF COMPATIBILITY .........................................................................................................71
10.1 RELEVANCE OF SECURITY CONTROLLER TSF ..........................................................................................71
10.2 SECURITY REQUIREMENTS........................................................................................................................71
10.2.1 Security Functional Requirements..................................................................................................71
10.2.2 Security Assurance Requirements ..................................................................................................71
10.3 SECURITY OBJECTIVES .............................................................................................................................71
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 6 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
10.4 COMPATIBILITY: TOE SECURITY ENVIRONMENT ......................................................................................71
10.4.1 Assumptions....................................................................................................................................71
10.4.2 Threats............................................................................................................................................71
10.4.3 Organisational Security Policies....................................................................................................71
10.5 CONCLUSION ............................................................................................................................................71
11 ANNEX.............................................................................................................................................................71
11.1 GLOSSARY AND LIST OF ACRONYMS .........................................................................................................71
11.2 BIBLIOGRAPHY .........................................................................................................................................71
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 7 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Table of Figures
FIGURE 1: SIMPLIFIED DRAWING OF THE VU...............................................................................................................10
FIGURE 2: EFAS-4.0 LIFE-CYCLE................................................................................................................................11
FIGURE 3: VU OPERATIONAL ENVIRONMENT..............................................................................................................12
FIGURE 4: EFAS-4.0 V02.00 WITH INTERFACES ................................................................................................14
Table of Tables
TABLE 1: PRIMARY ASSETS .........................................................................................................................................20
TABLE 2: SECONDARY ASSETS.....................................................................................................................................22
TABLE 3: SUBJECTS AND EXTERNAL ENTITIES .............................................................................................................23
TABLE 4: SECURITY OBJECTIVES FOR THE TOE...........................................................................................................29
TABLE 5: SECURITY OBJECTIVE RATIONALE ...............................................................................................................34
TABLE 6: SECURITY FUNCTIONAL GROUPS VS. SECURITY FUNCTIONAL REQUIREMENTS............................................42
TABLE 7: COVERAGE OF SECURITY OBJECTIVES FOR THE TOE BY SFR......................................................................70
TABLE 8: SUITABILITY OF THE SFRS ...........................................................................................................................71
TABLE 9: SAR DEPENDENCIES ....................................................................................................................................71
TABLE 10:OVERVIEW OF DEVELOPERS’ TOE RELATED DOCUMENTS..........................................................................71
TABLE 11: COVERAGE OF SECURITY FUNCTIONAL REQUIREMENTS BY TOE SECURITY FUNCTIONALITY...................71
TABLE 12: RELEVANCE OF SECURITY CONTROLLER TSF FOR COMPOSITE ST ............................................................71
TABLE 13: MAPPING OF SECURITY CONTROLLER OBJECTIVES TO TOE OBJECTIVES....................................................71
TABLE 14: MAPPING OF SECURITY CONTROLLER ASSUMPTIONS TO TOE OBJECTIVES ................................................71
TABLE 15: MAPPING OF SECURITY CONTROLLER THREATS TO TOE THREATS ............................................................71
TABLE 16: MAPPING OF SECURITY CONTROLLER OSPS TO TOE OSPS.......................................................................71
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 8 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
1 Scope
This document specifies the Security Target (ST) for the intellic EFAS-4.0 digital
tachograph.
2 ST Introduction (ASE_INT)
2.1 ST Reference
This document is the Security Target (ST) of the EFAS-4.0 (the TOE) provided by
intellic Germany GmbH for a Common Criteria evaluation.
Document Title: Security Target - EFAS-4.0
Document Date: 10.11.2011
Document Version: 18
Editor: Dr. Horst Kießling
Publisher: intellic Germany GmbH
CC-Version: 3.1 (Revision 3)
Assurance Level: The minimum assurance level for this ST is EAL4 augmented.
General Status: Released
TOE: EFAS-4.0
TOE Developer: intellic Germany GmbH
TOE Sponsor: intellic GmbH (Austria)
Certification ID: BSI-DSZ-CC-0726
IT Evaluation Scheme:German CC Evaluation Scheme
Evaluation Body: SRC Security Research & Consulting GmbH (SRC)
2.2 TOE Reference
The target of evaluation (TOE) is the EFAS-4.0 digital tachograph with SW version
02.00 as developed by intellic Germany GmbH, based on INFINEON M7801 A12 (see
[SCST]).
The INFINEON SC is used with the following configuration (Sales name SLE 78 CFX
1600P):
• M7801 A12,
• Chip Identifier Byte = 77h,
• NVM 160 kBytes,
• ROM blocked,
• XRAM 8kBytes,
• with ISO7816(2),
• without I2C,
• with Flash Loader (FL) 3.50.022
• including RMS V8000B0015
• and STS V78.01.07.07
• and SA V1.4 B90
• and Overall-Patch V8013
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 9 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
• with patches for FL, RMS
• and STS
• and SW: RSA2048 V1.02.008
2.3 TOE Overview
2.3.1 TOE Definition and Operational Usage
The Target of Evaluation (TOE) addressed by the current security target is a vehicle unit
(VU) in the sense of Annex I B [EU1B] intended to be installed in road transport vehicles.
Its purpose is to record, store, display, print and output data related to driver activities.
The VU records and stores user activities data in its internal data memory, it also
records user activities data in tachograph cards. The VU outputs data to display, printer
and external devices. 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 physical scope of the TOE is a device to be installed in a vehicle. The TOE consists
of a hardware box (includes processing units, data memory, a real time clock, two smart
card interface devices (driver and co-driver), a printer, a display, a visual warning, a
calibration/ downloading connector, facilities for entry of user's inputs, embedded
software and of related user manuals. It must be connected to a motion sensor (MS)
and to a power supply unit; it can temporarily be connected with other devices used for
calibration, data export, software upgrade and diagnostics.
The TOE receives motion data from the motion sensor and activity data via the facilities
for entry of user's. It stores all these user data internally and can export them to the
tachograph cards inserted, to the display, to the printer, and to electrical interfaces for
download purpose inclusive remote download after corresponding identification and
authentication of the company (by means of the company card).
Furthermore, the TOE contains the functionality for secure update of the defined parts
of the TOE software.
A simplified drawing of the VU is depicted in the following figure (it shall be noted that
although the printer mechanism is part of the TOE, the paper document once produced
is not):
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 10 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Figure 1: Simplified Drawing of the VU
2.3.2 TOE Major Security Features for Operational Use
The main security feature of the TOE is as specified in [EU1B] (O.VU_Main): The data
to be measured (the physical data measurement is performed by the motion sensor
which is not part of this TOE) and recorded and then 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.
It concretely means that security of the VU aims to protect
a) the data recorded and stored in such a way as to prevent unauthorized access
to and manipulation of the data and detecting any such attempts,
b) the integrity and authenticity of data exchanged between the motion sensor
and the vehicle unit,
c) the integrity and authenticity of data exchanged between the recording
equipment and the tachograph cards, and
d) the integrity and authenticity of data downloaded (locally and remotely).
The main security feature stated above is provided by the following major security
services
(please refer to [GST], chapter 4):
a) Identification and authentication of motion sensor und tachograph cards,
b) Access control to functions and stored data,
c) Accountability of users,
d) Audit of events and faults,
e) Object reuse for secret data,
f) Accuracy of recorded and stored data,
g) Reliability of services,
h) Data exchange with motion sensor, tachograph cards and external media
(download function).
‘Identification and Authentication’ as well as ‘data exchange’ directly require
cryptographic support according to [GST], sec. 4.9.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 11 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
2.3.3 TOE Type
The TOE type is the Vehicle Unit EFAS-4.0, a vehicle unit in the sense of Annex I B
[EU1B].
The life cycle of the EFAS-4.0 is based on the principles described in [EU], appendix 10,
chapter 3.2, as shown in Picture 3. Grayed blocks indicate the developing and
manufacturing steps before delivery.
SC software
development
Hardware
development
Design
Hardware
manufacturing
Assembly
Security data
insertion
Storage and
distribution (WF)
Installation (F)
Activation
Calibration
Operation
End of life
Periodic
inspection
Repair (W)
Repair (M)
Storage and
distribution (WR)
Installation (R)
Storage and
distribution (MF)
Storage and
distribution (MR)
MC software
development
Security data
management
Design
environment
Secured
environment
Workshop
/
fitters
environment
End
user
env.
(S1)
(S2)
(S4)
(S3)
(S5)
(S6)
Manufacturing
environment
(S7)
Figure 2: EFAS-4.0 Life-Cycle
The security requirements in section 4 of [GST] limit the scope of the security
examination of the TOE to the operational phase in the end user environment.
Therefore, the security policy defined by this ST also focuses on the operational phase
of the VU in the end user environment. Some single properties of the calibration phase
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 12 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
being significant for the security of the TOE in its operational phase are also considered
by the current ST as required by [GST].
The TOE distinguishes between its calibration and operational phases by modes of
operation as defined in [EU1B], REQ007 and REQ010: operational, control and
company modes presume the operational phase, whereby the calibration mode
presumes the calibration phase of the VU (calibration phase comprises all operations
within the fitters and workshops environment).
This security target takes all life phases into consideration to the extent as required by
the assurance package chosen here for the TOE (see section 4.3 ‘Package Claim’
below) and the requirements from the BSI-CC-PP-0057 protection profile (see [PPT]).
The TOE delivery from its manufacturer to the first customer (approved workshops)
exactly happens at the transition from the manufacturing to the calibration phase, see
also [PPT], sec. 8.2 for delivery interfaces.
A software update can be executed by a workshop on the basis of encrypted update
data prepared by the Security Server in the manufacturing environment (S7).
The VU enables a software update of defined parts of the software (incl. wireless
remote update connection), if the corresponding authentication was successful.
2.3.4 Non-TOE hardware/software/firmware
The vehicle unit’s operational environment while installed in a vehicle is depicted in the
following figure:
Figure 3: VU Operational Environment
The following TOE-external components are
a) mandatory for a proper TOE operation:
• power supply e.g. from the vehicle, where the TOE is installed
• motion sensor;
b) functionally necessary for an Annex I B compliant operation:
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 13 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
• calibration device (fitters and workshops environment only)
• tachograph cards (four different types of them)
• printer paper
• external storage media for data download;
c) helpful for a convenient TOE operation:
• connection to the vehicle network e.g. CAN-connection.
• connection to a remote download device
While operating, the TOE will verify, whether the connected motion sensor and
tachograph cards possess appropriate credentials showing their belonging to the digital
tachograph system. A security certification according to [GST] is a prerequisite for the
type approval of a motion sensor and tachograph cards.
The VU “Digital Tachograph EFAS-4.0” contains a separate Extension Controller – XC
(see next chapter). The Extension Controller controls external interfaces as an agent for
the MC and evaluates the acceleration data from the second motion data source –
Acceleration Sensor UB3. The TOE does not include the Extension Controller
(hardware and software) and the Acceleration Sensor UB3.
In order to avoid redundancy and to minimize the evaluation efforts, the evaluation of
the TOE will be conducted as a composite evaluation and will make use of the
evaluation results of the CC evaluation of the security controller "M7801 A12 (sales
name SLE 78 CFX 1600P)" provided by INFINEON. The IC is evaluated according to
Common Criteria EAL 5 augmented by ALC_DVS.2 and AVA_VAN.5 and is listed under
the Certification ID BSI-DSZ-CC-0727-2011. The evaluation of the IC is based on the
Protection Profile BSI-PP-0035, Version 1.0 as of June 15th
2007.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 14 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
3 TOE Description
3.1 Architecture Overview
The Target of Evaluation (TOE) is the Digital Tachograph EFAS-4.0 (EFAS-4.0 or
vehicle unit (VU) for short in the following). It is designed in accordance with the
Tachograph Specification [EU]. The security relevant parts are specified in appendix 10
(Vehicle Unit Generic Security Target) and appendix 11 of [EU] and summarized in the
PP [PPT].
The following figure 4 shows security relevant physical interfaces and internal
components of the EFAS-4.0 digital tachograph.
Figure 4: EFAS-4.0 V02.00 with Interfaces
3.2 TOE Hardware
The hardware components are:
Security Controller (SC)
The security controller is a micro controller that consists of a central processing unit, a
cryptographic coprocessor and embedded RAM, EEPROM and optionally ROM
memory.
The SC implements most of the security functions of the TOE:
• Storage of sensitive data (certificates, identities, audit records, …)
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 15 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
• Cryptographic operations.
• Supervision of time/date and motion data.
• Supervision of user data stored in the MC flash.
Main Controller (MC)
The main controller controls all external interfaces - either directly or via XC extension
controller - it has exclusive access to the VU onboard flash and RAM.
MC-ext Flash
The MC-ext-flash contains the software for the MC which does not fit into the MC-
internal flash as well as configuration and user data.
MC-ext RAM
The MC-ext-RAM stores temporary data.
Real Time Clock (RTC)
The RTC provides the EFAS-4.0 with a reliable time.
Case Open Supervision
The case open supervision circuit detects any case opening while the external supply
voltage is connected or not. The circuit is triggered when either the housing is opened
or the VU battery is empty.
Battery
The internal battery ensures the proper operation of the RTC, the case open
supervision circuit and the MC RAM while the VU is disconnected from the vehicle
power supply.
Card Reader #1 and #2
The card readers provide the interface to the Tachograph Cards.
Printer
The printer is able to output the data in printed form.
Keypad
With help of the keypad it is possible to input control information.
Display, LED and Buzzer
The VU informs the user via the build-in display, buzzer and LED about the relevant
values (road speed, driving times) and events (e.g. errors or speed limit violations).
Power Supply
The Power Supply hardware provides all components with necessary voltage.
Metal Case
The rigid metal case is secured by a sealed screw and the case opening switch, which
triggers the case open supervision circuit when released.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 16 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
The following hardware is part of the EFAS-4.0 digital tachograph, but not of the
TOE:
Extension Controller (XC)
The extension controller controls external interfaces as an agent for the MC and
evaluates the acceleration data from the second motion data source UB3.
UB3 Acceleration Sensor
The acceleration sensor measures acceleration and delivers measurement data to the
XC.
3.3 TOE Software
The TOE software consists of three parts:
SC Software
The SC software provides data access functions, tachograph card access functions and
motion sensor communication functions for use by the MC application software.
Furthermore, the SC software provides functions for secure communication between the
VU and the Security Server as well as between the VU and a remote company server
(with connection to a Company Card). In addition, the SC software supervises the other
parts of the VU, especially the time/date handling as well as the code and user data
storage in the MC flash.
MC Application Software
The MC application software implements all functions necessary for the operation of a
digital tachograph, as the control of external and internal interfaces, the memory
access, and the supply voltage supervision. For security operations, the MC application
software makes use of the services of the SC.
MC Boot Software
The MC boot software starts the MC application software and executes parts of the
software update.
The following software is part of the EFAS-4.0 digital tachograph, but not of the
TOE:
XC Software
The XC software implements functions necessary for the control of dedicated external
interfaces and of the internal motion data source (acceleration sensor.
3.4 Details of Security Mechanisms
EFAS-4.0 provides all security mechanisms required in the BSI-CC-PP-0057 protection
profile (see [PPT]), in particular the following:
EFAS-4.0 monitors the case opening, the values of the power supply, the RTC, the
flash memory contents and the communication with the motion sensor. The TOE runs
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 17 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
self tests during initial start-up, and during normal operation to verify its correct
operation. For events impairing the security, EFAS-4.0 generates audit records with
associated data. The EFAS-4.0 preserves a secure state independent from the values
of the power supply, including cut-off, and prevents a misuse of security relevant data
involved in its operations.
3.5 TOE Product Scope
This Security Target applies to the following components of the TOE respectively:
• The vehicle unit EFAS-4.0, Hardware/Software
• Operating Manual EFAS-4.0 document in paper / electronic pdf-form (for all
kinds of users)
• Service and Installation Manual EFAS-4.0, document in paper / electronic pdf-
form (for workshop personnel)
The TOE is able to operate in the environment of vehicles with 24 V and 12 V power
supply from different vehicle manufacturers. The TOE is able to be adapted via
parameter settings to cover the vehicle variety (e.g. optional interfaces: the first and
second CAN bus, the K-Line and the info interface).
3.6 TOE Environment
3.6.1 Development Environment
The EFAS-4.0 developers ensure that the assignment of responsibilities during
development is done in a manner which maintains IT security. The TOE is developed in
a well structured environment with well defined responsibilities. The specification,
implementation and tests in the development departments are organised based on
formal methods. Suitable measures enforce the usage of guidelines. The complete
development of the TOE is well documented. The confidentiality and integrity of
development results is protected (usage of file servers with dedicated access rights,
version controls, backup strategies, usage of e-mail encryption for communication and
firewall protection). The used measures are always documented.
3.6.2 Manufacturing Environment
In the manufacturing environment, responsibilities are assigned in a manner which
maintains IT security and the EFAS-4.0 is protected from physical attacks which might
compromise IT security. The manufacturing environment is well documented, supported
by procedures based on ISO 9001:2000 (see [ISO9001]). Measures are defined to
protect security data like cryptographic keys against disclosure and manipulation.
Systems which implement security data generation algorithms are accessible to
authorised and trusted persons only. Security data are generated, transported, and
inserted into the EFAS-4.0, in such a way as to preserve its appropriate confidentiality
and integrity.
When leaving the manufacturing environment, the TOE is complete and ready to be
delivered to the customer.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 18 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
3.6.3 Fitters and Workshop Environment
The EFAS-4.0 fitters and workshop environment is as described in the BSI-CC-PP-0057
protection profile (see [PPT]).
3.6.4 End User Environment
The EFAS-4.0 end user environment is as described in the BSI-CC-PP-0057 protection
profile (see [PPT]).
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 19 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
4 Conformance Claims
4.1 CC Conformance Claims
This security target claims conformance to
• Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and general model; CCMB-2009-07-001, Version 3.1, Revision 3,
July 2009 [CC1]
• Common Criteria for Information Technology Security Evaluation, Part 2:
Security functional components; CCMB-2009-07-002, Version 3.1, Revision 3,
July 2009 [CC2]
• Common Criteria for Information Technology Security Evaluation, Part 3: Security
assurance components; CCMB-2009-07-003, Version 3.1, Revision 3, July 2009
[CC3]
as follows
• Part 2 conformant,
• Part 3 conformant.
The
• Common Methodology for Information Technology Security Evaluation,
Evaluation methodology; CCMB-2009-07-004, Version 3.1, Revision 3, July 2009,
[CM] has to be taken into account.
4.2 PP Claim
This security target claims conformance to the protection profile (PP) BSI-CC-PP-0057
“Protection Profile ‘Digital Tachograph – Vehicle Unit (VU PP)’“ as sponsored by
“Bundesamt für Sicherheit in der Informationstechnik“, author Dr. Igor Furgel T-Systems
GEI GmbH, SC Security Analysis & Testing, version 1.0 as of 13th
July 2010.
4.3 Package Claim
This ST claims conformance to the following security requirements package:
• Assurance package E3hCC31_AP as defined in section 9.2 below.
This assurance package is commensurate with JIL [JIL] defining an assurance package
called E3hAP. This assurance package declares assurance equivalence between the
assurance level E3 of an ITSEC certification and the assurance level of the package
E3hAP within a Common Criteria (ver. 3.1) certification (in conjunction with the Digital
Tachograph System) as demonstrated in [PPT].
The assurance package E3hCC31_AP represents the standard assurance package
EAL4 augmented by the assurance components ATE_DPT.2 and AVA_VAN.5 (see
section 9.2 below).
4.4 Conformance Rationale
Since this security target (ST) claims strict conformance with the protection profile (PP)
BSI-CC-PP-0057 referenced in 4.2 “PP Claim”, no rationale is necessary here.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 20 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
5 Security Problem Definition
5.1 Introduction
The primary and secondary assets to be secured are as introduced in BSI-CC-PP-0057
(see [PPT] section 3.1), but enhanced as described in the following tables (marked
yellow).
1 The primary assets to be protected by the TOE as long as they are in scope of
the TOE are (please refer to the glossary in chap. 11.1 for the term definitions)
Object
No.
Asset Definition Generic security
property to be
maintained by the
current security policy
1 user data
(recorded or
stored in the
TOE)
Any data, other than security
data (sec. III.12.2 of [EU]) and
authentication data, recorded
or stored by the VU, required
by Chapter III.12 of the
Commission Regulation [EU].
Integrity
Authenticity
2 user data
transferred
between the
TOE and an
external
device
connected
All user data being transferred
from or to the TOE.
A TOE communication partner
can be:
- a motion sensor,
- a tachograph card, or
- an external medium for data
download.
Motion data are part of this
asset.
User data can be received and
sent (exchange ⇔ {receive,
send}).
Confidentiality1
Integrity
Authenticity2
Table 1: Primary Assets
2 All these primary assets represent User Data in the sense of the CC.
3 The secondary assets also having to be protected by the TOE in order to
achieve a sufficient protection of the primary assets are:
1 Not each data element being transferred represents a secret. Whose data confidentiality shall be protected while
transferring them (i) between the TOE and a MS, is specified in [ISO16844], sec. 7.6 (instruction #11); (ii) between
the TOE and a tachograph card – in Appendix 2 of Annex I B of Commission Regulation (EEC) No. 1360/2002 –
Tachograph Cards Specification, chap. 4 (access condition = PRO SM). Confidentiality of data to be downloaded to
an external medium is not required to be protected.
2
Not each data element being transferred shall be protected for its integrity and authenticity. Whose data integrity
and authenticity shall be protected while transferring them (i) between the TOE and a MS, is specified in [ISO16844],
sec. 7.5 (instruction #80); (ii) between the TOE and a tachograph card – in Appendix 2 of Annex I B of Commission
Regulation (EEC) No. 1360/2002, chap. 4 (access condition = AUT). Integrity and authenticity of data to be
downloaded to en external medium shall always be protected.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 21 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Object
No.
Asset Definition Property to be
maintained by the
current security
policy
3 Accessibility
to the TOE
functions and
data only for
authorised
subjects
Property of the TOE to restrict access
to TSF and TSF-data stored in the
TOE to authorised subjects only.
Availability
4 Genuineness
of the TOE
Property of the TOE to be authentic in
order to provide the claimed security
functionality in a proper way.
Availability
5 TOE
immanent
secret security
data
Secret security elements used by the
TOE in order to enforce its security
functionality.
There are the following security
elements of this category:
- equipment private key (EQT.SK),
see [EU1B], sec. III.12.2,
- vehicle unit part of the symmetric
master key for communication with
MS (KmVU), see [CSM], sec. 3.1.3,
- session key between motion
sensor and vehicle unit KSm (see
[ISO16844], sec. 7.4.5 (instruction
42)),
- session key between tachograph
cards and vehicle unit KSt (see
[CSM], sec. 3.2)
- SW-Update Keys
Confidentiality
Integrity
6 TOE
immanent
non-secret
security data
Non-secret security elements used by
the TOE in order to enforce its
security functionality.
There are the following security
elements of this category:
- European public key (EUR.PK),
- Member State certificate (MS.C),
- equipment certificate (EQT.C).
- Serial Number and Production
date
see [EU1B], sec. III.12.2.
Integrity
Authenticity
7 TOE security
relevant
software
Updateable security relevant software
components of the TOE (inclusive
update credentials), in particular SC
Confidentiality
Authenticity
Integrity
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 22 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Object
No.
Asset Definition Property to be
maintained by the
current security
policy
components
(security
patch)
software (except the update
mechanism).
8 TOE non-
security
relevant
software
components
(patch)
Updateable non-security relevant
software components of the TOE
(inclusive update credentials), such
as MC software and other software
components.
Confidentiality
Authenticity
Integrity
Table 2: Secondary assets
The workshop tachograph card requires an additional human user authentication by
presenting a correct PIN value to the card. The vehicle unit (i) transmits the PIN
verification value input by the user to the card and (ii) receives the card response to this
verification attempt. A workshop tachograph card can only be used within the fitters and
workshops environment (see A.Card_Availability below), which is presumed to be
trustworthy (see A.Approved_Workshops below). Hence, no threat agent is presumed
while using a workshop tachograph card.
In this context, the VU is not required to secure a PIN verification value and any card
response to a verification attempt, cf. [CSM], chap. 4.
Subjects and external entities
4 This security target considers the following subjects:
External
Entity
No.
Subject
No.
Role Definition
1 1 User Users are to be understood as legal human user of the
TOE. The legal users of the VU comprise drivers,
controllers, workshops and companies. User
authentication is performed by possession of a valid
tachograph card.
There can also be Unknown User of the TOE and
malicious user of the TOE – an attacker.
User identity is kept by the VU in form of a
concatenation of User group and User ID, cf. [GST],
UIA_208 representing security attributes of the role
‘User’.
An attacker is a threat agent (a person or a process
acting on his behalf) trying to undermine the security
policy defined by the current PP/ST, especially to
change properties of the assets having to be
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 23 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
External
Entity
No.
Subject
No.
Role Definition
maintained.
The attacker is assumed to possess an at most high
attack potential.
Please note that the attacker might ‘capture’ any subject
role recognised by the TOE.
Due to constraints and definitions in [GST], an attacker
is an attribute of the role ‘User’ in the context of the
current PP/ST. Being a legal user is also an attribute of
the role User.
2 2 Unknown
User
not authenticated user.
3 3 Motion
Sensor
Part of the recording equipment, providing a signal
representative of vehicle speed and/or distance
travelled.
A MS possesses valid credentials for its authentication
and their validity is verifiable.
Valid credentials are MS serial number encrypted with
the identification key (Enc(KID|NS)) together with pairing
key encrypted with the master key (Enc(KM|KP))
4 - Tachogra
ph Card
Smart cards intended for use with the recording
equipment. Tachograph cards allow for identification by
the recording equipment of the identity (or identity
group) of the cardholder and allow for data transfer and
storage. A tachograph card may be of the following
types:
driver card,
control card,
workshop card,
company card.
A tachograph card possesses valid credentials for its
authentication and their validity is verifiable.
Valid credentials are a certified key pair for
authentication being verifiable up to EUR.PK.
5 4 Unknown
equipmen
t
A technical device not possessing valid credentials for
its authentication or validity of its credentials is not
verifiable.
Valid credentials can be either a certified key pair for
authentication of a device or MS serial number
encrypted with the identification key (Enc(KID|NS))
together with pairing key encrypted with the master key
(Enc(KM|KP)).
6 - Attacker see item User above.
Table 3: Subjects and external entities
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 24 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
This table defines the subjects in the sense of [CC1] which can be recognised by the
TOE independent of their nature (human or technical user). As result of an appropriate
identification and authentication process, the TOE creates – for each of the respective
external entity – an ‘image’ inside and ‘works’ then with this TOE internal image (also
called subject in [CC1]). From this point of view, the TOE itself does not differ between
‘subjects’ and ‘external entities’. There is no dedicated subject with the role ‘attacker’
within the current security policy, whereby an attacker might ‘capture’ any subject role
recognised by the TOE.
5.2 Threats
The threats to the security target (ST) are as described in the protection profile BSI-CC-
PP-0057 (see [PPT] section 3.2) they are fully cited here for convenience.
Threats averted solely by the TOE:
T.Card_Data_Exchan
ge
Users could try to modify user data while exchanged between VU
and tachograph cards (addition, modification, deletion, replay of
signal).
T.Faults Faults in hardware, software, communication procedures could
place the VU in unforeseen conditions compromising its security3
.
T.Output_Data Users could try to modify data output (print, display or
download)3
.
Threats averted by the TOE and its operational environment:
T.Access Users could try to access functions3
not allowed to them (e.g.
drivers gaining access to calibration function).
T.Calibration_Param
eters
Users could try to use miscalibrated equipment3
(through
calibration data modification, or through organisational
weaknesses).
T.Clock Users could try to modify internal clock3
.
T.Design Users could try to gain illicit knowledge of design3
either from
manufacturer’s material (through theft, bribery …) or from reverse
engineering.
T.Environment Users could compromise the VU security3
through environmental
attacks (thermal, electromagnetic, optical, chemical,
mechanical,…).
T.Fake_Devices Users could try to connect fake devices (motion sensor, smart
cards) to the VU4
.
3
The terms ‘miscalibrated equipment’, ‘VU security’, ‘VU security objectives’, ‘data output’, ‘not allowed functions’,
‘VU in a well defined state’, ‘VU design’, ‘correctness of the internal clock’, ‘integrity of VU hardware’, ‘integrity of the
VU software’, ‘full activated security functionality of the VU’ correspond with [GST] and are covered by the assets
‘Accessibility to the TOE functions and data only for authorised subjects’ and ‘Genuineness of the TOE’
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 25 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
T.Hardware Users could try to modify VU hardware3
.
T.Identification Users could try to use several identifications or no identification5
.
T.Motion_Data Users could try to modify the vehicle’s motion data (addition,
modification, deletion, replay of signal)6
.
T.Power_Supply Users could try to defeat the VU security objectives3
by modifying
(cutting, reducing, increasing) its power supply.
T.Security_Data Users could try to gain illicit knowledge of security data7
during
security data generation or transport or storage in the equipment.
T.Software Users could try to modify VU software3
on the VU or during the
updates (modification of patches for updates).
T.Stored_Data Users could try to modify stored data (security8
or user data).
T.Tests The use of non invalidated test modes or of existing back doors
could compromise the VU security3
.
Threat T.Faults represents a ‘natural’ flaw not induced by an attacker; hence, no threat agent can be
stated here.
The threat agent for T.Tests is User. It can be deduced from the semantic content of T.Tests.
Threats averted solely by the TOE’s operational environment:
T.Non_Activated Users could use non activated equipment3
.
5.3 Organisational Security Policies
The organisational security policies are as described in BSI-CC-PP-0057 (see [PPT]
section 3.3) enhanced as described in the following tables (marked yellow).
The TOE and/or its environment shall comply with the following Organisational Security Policies
(OSP) as security rules, procedures, practices, or guidelines imposed by an organisation upon its
operations.
4
Communication with genuine/known equipment is a prerequisite for a secure data exchange and, hence, represents
a partial aspect of the asset ‘user data transferred between the TOE and an external device connected’.
5
Identification data are part of the asset ‘User data’, see Glossary.
6
Motion data transmitted are part of the asset ‘user data transferred between the TOE and an external device
connected’.
7
‘security data’ are covered by the assets ‘TOE immanent secret security data’ and ‘TOE immanent non-secret
security data’
8
it means ‘TOE immanent secret security data’ and ‘TOE immanent non-secret security data’
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 26 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
They are defined here to reflect those security objectives from [GST] for which there is no threat
directly and fully associated.
OSPs related to the TOE:
OSP.Accountability The VU must collect accurate accountability data.
OSP.Audit The VU must audit attempts to undermine system security
and should trace them to associated users.
OSP.Processing The VU must ensure that processing of inputs to derive user
data is accurate.
OSP.Test_Points All commands, actions or test points, specific to the testing
needs of the manufacturing phase of the VU must be disabled
or removed before the VU activation during the
manufacturing process.
OSPs related to the TOE and its operational environment:
OSP.Type_Approved_M
S9
The VU shall only be operated together with a motion sensor
being type approved according to Annex I B.
OSP.SW_Upgrade The software updates have to be performed in the way that
the update process itself and the transport of software parts
for update to the VU will be secured to ensure the
compliance to the software requirements RLB_204,
RLB_205 of [GST].
OSPs related to the TOE’s operational environment:
OSP.PKI 1) The European Authority shall establish a PKI according
to [CSM], sec. 3.1.1 (starting with ERCA). This PKI is
used for device authentication (TOE <-> Tachograph
Cards) and for digital signing the user data to be
downloaded. The European Authority shall properly
operate the ERCA steering other levels (the Member
State and the equipment levels) of the PKI.
2) The ERCA shall securely generate its own key pair
(EUR.PK and EUR.SK) and Member State certificates
(MSi.C) over the public keys of the MSCAs.
3) The ERCA shall ensure that it issues MSi.C certificates
9
The identity data of the motion sensor (serial number NS) will be sent to the VU on request by the MS itself (see
instruction #40 in [ISO16844]). The ‘certificate’ Enc(KID|NS) stored in the motion sensor is merely used by it for VU
authentication, but not for verifying NS by the VU (see instruction #41 in [ISO16844]). Therefore, the VU accepts this
data (serial number NS) as it is. Hence, the structure of the motion sensor Identification Data is the matter of the IT
environment (here: MS), but not of the VU itself. A correct structure of the MS identity is guaranteed by the fact that
the MS is type approved.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 27 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
only for the rightful MSCAs.
4) The ERCA shall issue the ERCA policy steering its own
acting and requiring MSCAs to enforce at least the same
rules.
5) MSCAs shall securely generate their own key pairs
(MSi.PK and MSi.SK) and equipment certificates
(EQTj.C) over the public keys of the equipment.
6) MSCAs shall ensure that they issue EQTj.C certificates
only for the rightful equipment.
OSP.MS_Keys 1) The European Authority shall establish a special key
infrastructure for management of the motion sensor keys
according to [ISO16844] (starting with ERCA). This key
infrastructure is used for device authentication (TOE <->
MS). The European Authority shall properly operate the
ERCA steering other levels (the Member State and the
equipment levels) of this key infrastructure.
2) The ERCA shall securely generate both parts (KmVU and
KmWC) of the master key (Km).
3) The ERCA shall ensure that it securely convey this key
material only to the rightful MSCAs.
4) The ERCA shall issue the ERCA policy steering its own
acting and requiring MSCAs to enforce at least the same
rules.
5) MSCAs shall securely calculate the motion sensor
identification key (KID) and the motion sensor’s
credentials: MS individual serial number encrypted with
the identification key (Enc(KID|NS)) and MS individual
pairing key encrypted with the master key (Enc(KM|KP)).
6) MSCAs shall ensure that they issue these MS
credentials10
, KmVU
11
and KmWC
12
only to the rightful
equipment.
5.4 Assumptions
The assumptions are as described in BSI-CC-PP-0057 (see [PPT] section 3.4).
The assumptions describe the security aspects of the environment in which the TOE will be used or is
intended to be used.
The GST in [GST] does not define any dedicated assumption, but measures; these measures will be
reflected in the current PP in form of the security objectives for the TOE environment below. Hence, it is
to define some assumptions in the current PP being sensible and necessary from the formal point of view
(to reflect those environmental measures from [GST]).
10
to the motion sensors
11
to the vehicle units
12
to the workshop cards
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 28 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
A.Activation Vehicle manufacturers and fitters or workshops activate the
TOE after its installation before the vehicle leaves the premises
where installation took place.
A.Approved_Worksho
ps
The Member States approve, regularly control and certify
trusted fitters and workshops to carry out installations,
calibrations, checks, inspections, repairs.
A.Card_Availability Tachograph cards are available to the TOE users and delivered
by Member State authorities to authorised persons only.
A.Card_Traceability Card delivery is traceable (white lists, black lists), and black
lists are used during security audits.
A.Controls Law enforcement controls will be performed regularly and ran-
domly, and must include security audits (as well as visual
inspection of the equipment).
A.Driver_Card_Unique
ness
Drivers possess, at one time, one valid driver card only.
A.Faithful_Calibration Approved fitters and workshops enter proper vehicle
parameters in recording equipment during calibration.
A.Faithful_Drivers Drivers play by the rules and act responsibly (e.g. use their
driver cards; properly select their activity for those that are
manually selected …)13
.
A.Regular_Inspections Recording equipment will be periodically inspected and cali-
brated.
13
The assumption A.Faithful_Drivers taken from the Generic Security Target [GST] seems not to be
realistic and enforceable (from security point of view), because the driver is the person, who has to be
controlled and surveyed (see the Comission Regulation [EU]). This assumption is made in the current
PP/ST only for the sake of compatibility with the GST [GST] and is necessary from functional point of
view.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 29 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
6 Security Objectives
This chapter describes the security objectives for the TOE and the security objectives
for the TOE environment.
6.1 Security Objectives for the TOE
The security objectives for the TOE are as described in the protection profile BSI-CC-
PP-0057 (see [PPT] section 4.1) enhanced as described in the following table (marked
yellow).
The following TOE security objectives address the protection provided by the TOE
independent of the TOE environment.
They are derived from the security objectives as defined in [GST], sec. 3.5.
O.Access The TOE must control user access to functions and data.
O.Accountability The TOE must collect accurate accountability data.
O.Audit The TOE must audit attempts to undermine system security and
should trace them to associated users.
O.Authentication The TOE should authenticate users and connected entities
(when a trusted path needs to be established between entities).
O.Integrity The TOE must maintain stored data integrity.
O.Output The TOE must ensure that data output reflects accurately data
measured or stored.
O.Processing The TOE must ensure that processing of inputs to derive user
data is accurate.
O.Reliability The TOE must provide a reliable service.
O.Secured_Data_Excha
nge
The TOE must secure data exchanges with the motion sensor
and with tachograph cards.
O.Software_Analysis14
There shall be no way to analyse or debug software15
in the
field after the TOE activation.
O.Software_Upgrade The TOE must ensure confidentiality, authenticity and integrity
of software to be installed during a software upgrade.
Table 4: Security Objectives for the TOE
14
This objective is added for the sake of a more clear description of the security policy: In the GST [GST], this aspect
is part of O.Reliability, what might be not self-evident. The special concern here is RLB_204 in [GST].
15
It is a matter of the decision by the certification body and the evaluation facility involved in a concrete certification
process on a classification of the TOE (hard- and software) into security relevant and irrelevant parts.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 30 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
6.2 Security Objectives for the Operational Environment
The security objectives for the operational environment are as described in BSI-CC-PP-
0057 (see [PPT] section 4.2) enhanced as described in the following tables (marked
yellow):
The following security objectives for the TOE’s operational environment address the
protection provided by the TOE environment independent of the TOE itself.
They are derived from the security objectives as defined in GST [GST], sec. 3.6,
where they are represented as security measures.
a) design environment (cf. the life cycle diagram in Figure 2: EFAS-4.0 Life-Cycle above):
OE.Development VU developers shall ensure that the assignment of responsibili-
ties during development is done in a manner which maintains
IT security.
b) Manufacturing environment
OE.Manufacturing VU manufacturers shall ensure that the assignment of responsi-
bilities during manufacturing is done in a manner which main-
tains IT security and that during the manufacturing process the
VU is protected from physical attacks which might
compromise IT security.
OE.Sec_Data_Generati
on
Security data generation algorithms shall be accessible to
authorised and trusted persons only.
OE.Sec_Data_Transpor
t
Security data shall be generated, transported, and inserted into
the TOE, in such a way to preserve its appropriate
confidentiality and integrity.
OE.Delivery VU manufacturers, vehicle manufacturers and fitters or work-
shops shall ensure that handling of the TOE is done in a
manner which maintains IT security.
OE.Software_Upgrade Software revisions shall be granted security certification before
they can be implemented in the TOE. The software parts for
updates have to be secured during the generation and transport
to the VU.
OE.Sec_Data_Strong16
Security data inserted into the TOE shall be as
cryptographically strong as required by [CSM].
OE.Test_Points17
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 by the VU manufacturer
during the manufacturing process.
16
The security objective OE.Sec_Data_Strong is defined in addition to [GST] in order to reflect an aim of establishing
the PKI and the symmetric key infrastructure (OSP.PKI and OSP.MS_Keys)
17
This objective is added for the sake of a more clear description of the security policy: In the GST [GST], this aspect
is part of O.Reliability, what might be not self-evident: A TOE cannot achieve an objective depending on action of its
manufacturer. The special concern here is RLB_201 in [GST].
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 31 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Please note that the design and the manufacturing environments are not the intended usage
environments for the TOE. The security objectives for these environments being due to the current
security policy (OE.Development, OE.Manufacturing, OE.Test_Points, OE.Delivery) are the subject
to the assurance class ALC. Hence, the related security objectives for the design and the
manufacturing environments do not address any potential TOE user and, therefore, cannot be reflected
in the documents of the assurance class AGD.
The remaining security objectives for the manufacturing environment (OE.Sec_Data_Generation,
OE.Sec_Data_Transport, OE.Sec_Data_Strong and OE.Software_Upgrade) are subject to the ERCA
and MSA Policies and, therefore, are not specific for the TOE.
c) Workshops environment
OE.Activation Vehicle manufacturers and fitters or workshops shall activate
the TOE after its installation before the vehicle leaves the
premises where installation took place.
OE.Approved_Worksh
ops
Installation, calibration and repair of recording equipment shall
be carried by trusted and approved fitters or workshops.
OE.Faithful_Calibratio
n
Approved fitters and workshops shall enter proper vehicle
parameters in recording equipment during calibration.
d) End-user environment
OE.Card_Availability Tachograph cards shall be available to TOE users and delivered
by Member State Authorities to authorised persons only.
OE.Card_Traceability Card delivery shall be traceable (white lists, black lists), and
black lists must be used during security audits.
OE.Controls Law enforcement controls shall be performed regularly and
randomly, and must include security audits.
OE.Driver_Card_Uniqu
eness
Drivers shall possess, at one time, one valid driver card only.
OE.Faithful_Drivers18
Drivers shall play by the rules and act responsibly (e.g. use
their driver cards; properly select their activity for those that
are manually selected …).
OE.Regular_Inspection
s
Recording equipment shall be periodically inspected and cali-
brated.
OE.Type_Approved_M
S19
The Motion Sensor of the recording equipment connected to
the TOE shall be type approved according to Annex I B.
18
The objective OE.Faithful_Drivers taken from the Generic Security Target [GST] seems not to be realistic and
enforceable (from security point of view), because the driver is the person, who has to be controlled and surveyed
(see the Commission Regulation [EU]). This objective is claimed in the current PP only for the sake of compatibility
with the GST [GST] and is necessary from functional point of view, see also A.Faithful_Drivers.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 32 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
19
The identity data of the motion sensor (serial number NS) will be sent to the VU on request by the MS itself (see
instruction #40 in [ISO16844]). The ‘certificate’ Enc(KID|NS) stored in the motion sensor is merely used by it for VU
authentication, but not for verifying NS by the VU (see instruction #41 in [ISO16844]). Therefore, the VU accepts this
data (serial number NS) as it is. Hence, the structure of the motion sensor Identification Data is the matter of the IT
environment (here: MS), but not of the VU itself. A correct structure of the MS identity is guaranteed by the fact that
the MS is type approved (-> UIA_202).
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 33 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
6.3 Security Objective Rationale
The following table provides an overview for security objectives coverage (TOE and its
environment) also giving an evidence for sufficiency and necessity of the security
objectives defined. It shows that all threats (see 5.2) and OSPs (see 5.3) are addressed
by the security objectives. It also shows that all assumptions (see 5.4) are addressed by
the security objectives for the TOE environment.
This rationale covers the rationale part in [GST], chap. 8 and in its corrigendum 2004
(see [EU]) as described in [PPT]; however, enhanced by the additional rationale for
T.Software (partly), OSP.SW_Upgrade, O.Software_Upgrade, OE.Software_Upgrade
(partly).
T.Access
T.Identification
T.Faults
T.Tests
T.Design
T.Calibration_Parameters
T.Card_Data_Exchange
T.Clock
T.Environment
T.Fake_Devices
T.Hardware
T.Motion_Data
T.Non_Activated
T.Output_Data
T.Power_Supply
T.Security_Data
T.Software
T.Stored_Data
OSP.Accountability
OSP.Audit
OSP.Processing
OSP.Test_Points
OSP.Type_Approved_MS
OSP.PKI
OSP.MS_Keys
OSP.SW_Upgrade
A.Activation
A.Approved_Workshops
A.Card_Availability
A.Card_Traceability
A.Controls
A.Driver_Card_Uniqueness
A.Faithful_Calibration
A.Faithful_Drivers
A.Regular_Inspections
O.Access x x x x x x
O.Accountability x x
O.Audit x x x x x x x x x x x
O.Authenticatio
n
x x x x x x x
O.Integrity x x
O.Output x x x x x
O.Processing x x x x x x x x x
O.Reliability x x x x x x x x x x x x x
O.Secured_Dat
a_Echange
x x x x
O.Software_A
nalysis
x
O.Software_Up
grade
x x
OE.Developme
nt
x x
OE.Software_
Upgrade
x x x x
OE.Delivery x
OE.Manufacturi
ng
x x
OE.Sec_Data_
Strong
x x x
OE.Sec_Data_
Generation
x x x
OE.Sec_Data_
Transport
x x x
OE.Test.Points x
OE.Activation x x x
OE.Approved_
Workshops
x x x x x
OE.Card_Ava
ilability
x x
OE.Card_Trac
eability
x x
OE.Controls x x x x x x x x x x x
OE.Driver_Card
_Uniqueness
x x
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 34 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
T.Access
T.Identification
T.Faults
T.Tests
T.Design
T.Calibration_Parameters
T.Card_Data_Exchange
T.Clock
T.Environment
T.Fake_Devices
T.Hardware
T.Motion_Data
T.Non_Activated
T.Output_Data
T.Power_Supply
T.Security_Data
T.Software
T.Stored_Data
OSP.Accountability
OSP.Audit
OSP.Processing
OSP.Test_Points
OSP.Type_Approved_MS
OSP.PKI
OSP.MS_Keys
OSP.SW_Upgrade
A.Activation
A.Approved_Workshops
A.Card_Availability
A.Card_Traceability
A.Controls
A.Driver_Card_Uniqueness
A.Faithful_Calibration
A.Faithful_Drivers
A.Regular_Inspections
OE.Faithful_C
alibration
x x x
OE.Faithful_
Drivers
x
OE.Regular_
Inspections
x x x x x x x x x
OE.Type_Appro
ved_MS
x x x
Table 5: Security Objective Rationale
A detailed justification required for suitability of the security objectives to coup with the security
problem definition is given below (as taken from the protection profile [PPT], no amendmends
necessary).
T.Access is addressed by O.Authentication to ensure the identification of the user, O.Access to control
access of the user to functions and O.Audit to trace attempts of unauthorised accesses. OE.Activation:
The activation of the TOE after its installation ensures access of the user to functions.
T.Identification is addressed by O.Authentication to ensure the identification of the user, O.Audit to
trace attempts of unauthorised accesses. O.Accountability contributes to address this threat by storing
all activity carried (even without an identification) with the VU. The OE.Driver_Card_Uniqueness,
OE.Card_Availability and OE.Card_Traceability objectives, also required from Member States by
law, help addressing the threat.
T.Faults is addressed by O.Reliability for fault tolerance. Indeed, if the TOE provides a reliable
service as required by O.Reliability, the TOE cannot experience uncontrollable internal states. Hence,
also each possible fault of the TOE will be controllable, i.e. the TOE will be in a well-known state at
any time. Therefore, threats grounding in faults of the TOE will be eliminated.
T.Tests is addressed by O.Reliability and OE.Manufacturing. Indeed, if the TOE provides a reliable
service as required by O.Reliability and its security cannot be compromised during the manufacturing
process (OE.Manufacturing), the TOE can neither enter any invalidated test mode nor have any back
door. Hence, the related threat will be eliminated.
T.Design is addressed by OE.Development and OE.Manufacturing before activation, and after
activation by O.Software_Analysis to prevent reverse engineering and by O.Output (RLB_206) to
ensure that data output reflects accurately data measured or store and O.Reliability (RLB_201, 204,
206).
T.Calibration_Parameters is addressed by O.Access to ensure that the calibration function is
accessible to workshops only and by O.Authentication to ensure the identification of the workshop
and by O.Processing to ensure that processing of inputs made by the workshop to derive calibration
data is accurate, by O.Integrity to maintain the integrity of calibration parameters stored. Workshops
are approved by Member States authorities and are therefore trusted to calibrate properly the
equipment (OE.Approved_Workshops, OE.Faithful_Calibration). Periodic inspections and calibration
of the equipment, as required by law (OE.Regular_Inspections), contribute to address the threat.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 35 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Finally, OE.Controls includes controls by law enforcement officers of calibration data records held in
the VU, which helps addressing the threat.
T.Card_Data_Exchange is addressed by O.Secured_Data_Exchange. O.Audit contributes to address
the threat by recording events related to card data exchange integrity or authenticity errors.
O.Reliability (ACR_201, 201a), O.Processing (ACR_201a).
T.Clock is addressed by O.Access to ensure that the full time adjustment function is accessible to
workshops only and by O.Authentication to ensure the identification of the workshop and by
O.Processing to ensure that processing of inputs made by the workshop to derive time adjustment data
is accurate. Workshops are approved by Member States authorities and are therefore trusted to
properly set the clock (OE.Approved_Workshops). Periodic inspections and calibration of the
equipment, as required by law (OE.Regular_Inspections, OE.Faithful_Calibration), contribute to
address the threat. Finally, OE.Controls includes controls by law enforcement officers of time
adjustment data records held in the VU, which helps addressing the threat.
T.Environment: is addressed by O.Processing to ensure that processing of inputs to derive user data
is accurate.and by O.Reliability to ensure that physical attacks are countered. OE.Controls includes
controls by law enforcement officers of time adjustment data records held in the VU, which helps
addressing the threat.
T.Fake_Devices is addressed by O.Access (ACC_205) O.Authentication (UIA_201 – 205, 207 – 211,
213, UIA_221 – 223), O.Audit (UIA_206, 214, 220), O.Processing (ACR_201a), O.Reliability
(ACR_201, 201a), O.Secured_Data_Exchange (CSP_201 - 205). OE.Type_Approved_MS ensures
that only motion sensors with correct identification data have the credentials that are required to suc-
cessfully authenticate themselves. OE.Controls and OE.Regular_Inspections help addressing the threat
through visual inspection of the whole installation.
T.Hardware is mostly addressed in the user environment by O.Reliability, O.Output., O.Processing
and by O.Audit contributes to address the threat by recording events related to hardware manipulation.
The OE.Controls and OE.Regular_Inspections help addressing the threat through visual inspection of
the installation.
T.Motion_Data is addressed by O.Authentication, O.Reliability (UIA_206, ACR_201, 201a),
O.Secured_Data_Exchange and OE.Regular_Inspections , OE.Type_Approved_MS. O.Audit
contributes to address the threat by recording events related to motion data exchange integrity or
authenticity errors.
T.Non_Activated is addressed by the OE.Activation and OE.Delivery. Workshops are approved by
Member States authorities and are therefore trusted to activate properly the equipment
(OE.Approved_Workshops). Periodic inspections and calibration of the equipment, as required by law
(OE.Regular_Inspections, OE.Controls), also contribute to address the threat.
T.Output_Data is addressed by O.Output. O.Audit contributes to address the threat by recording
events related to data display, print and download.
T.Power_Supply is mainly addressed by O.Reliability to ensure appropriate behaviour of the VU
against the attack. O.Audit contributes to address the threat by keeping records of attempts to tamper
with power supply. OE.Controls includes controls by law enforcement officers of power supply
interruption records held in the VU, which helps addressing the threat. OE.Regular_Inspections helps
addressing the threat through installations, calibrations, checks, inspections , repairs tcarried out by
trusted fitters and workshops.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 36 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
T.Security_Data is addressed by OE.Sec_Data_Generation, OE.Sec_Data_Strong,
OE.Sec_Data_Transport, OE.Software_Upgrade, OE.Controls. It is addressed by the O.Access,
O.Processing, O.Secured_Data_Exchange to ensure appropriate protection while stored in the VU.
O.Reliability (REU_201, RLB_206).
T.Software is addressed in the user environment by the O.Output, O.Processing, O.Reliability and
O.Software_Upgrade as well as OE.Software_Upgrade to ensure the confidentiality, authenticity and
integrity of the code. O.Audit contributes to address the threat by recording events related to integrity
errors. During design and manufacture, the threat is addressed by the OE.Development objectives.
OE.Controls, OE.Regular_Inspections (checking for the audit records related).
T.Stored_Data is addressed mainly by O.Integrity, O.Access, O.Output and O.Reliability to ensure
that no illicit access to data is possible. The O.Audit contributes to address the threat by recording data
integrity errors. OE.Sofware_Upgrade included that software revisions shall be security certified
before they can be implemented in the TOE to prevent to alter or delete any stored driver activity data.
OE.Controls includes controls by law enforcement officers of integrity error records held in the VU
helping in addressing the threat.
OSP.Accountability is fulfilled by O.Accountability.
OSP.Audit is fulfilled by O.Audit.
OSP.SW_Upgrade is fulfilled by O.Software_Upgrade and OE.Software_Upgrade,
OSP.Processing is fulfilled by O.Processing.
OSP.Test_Points is fulfilled by O.Reliability and OE.Test_Points.
OSP.Type_Approved_MS is fulfilled by O.Authentication and OE.Type_Approved_MS.
OSP.PKI is fulfilled by OE.Sec_Data_Generation, OE.Sec_Data_Strong, OE.Sec_Data_Transport.
OSP.MS_Keys is fulfilled by OE.Sec_Data_Generation, OE.Sec_Data_Strong,
OE.Sec_Data_Transport.
A.Activation is upheld by OE.Activation.
A.Approved_Workshops is upheld by OE.Approved_Workshops.
A.Card_Availability is upheld by OE.Card_Availability.
A.Card_Traceability is upheld by OE.Card_Traceability.
A.Controls is upheld by OE.Controls.
A.Driver_Card_Uniqueness is upheld by OE.Driver_Card_Uniqueness.
A.Faithful_Calibration is upheld by OE.Faithful_Calibration and OE.Approved_Workshops.
A.Faithful_Drivers is upheld by OE.Faithful_Drivers.
A.Regular_Inspections is upheld by OE.Regular_Inspections.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 37 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
7 Extended Components Definition
This security target does not use any components defined as extensions to CC part 2.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 38 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
8 Security Requirements
This security target (ST) clarifies and adapts the security requirements as given in the
protection profile BSI-CC-PP-0057([PPT] chapter 6).
This part of the ST defines the detailed security requirements that shall be satisfied by
the TOE. The statement of TOE security requirements shall define the functional and
assurance security requirements that the TOE needs to satisfy in order to meet the
security objectives for the TOE.
The CC allows several operations to be performed on security requirements (on the
component level); refinement, selection, assignment, and iteration are defined in
paragraph 8.1 of Part 1 [CC1] of the CC. These operations are used in the protection
profile BSI-CC-PP-0057 [PPT] and in this ST, respectively.
The refinement operation is used to add detail to a requirement, and, thus, further
restricts a requirement. Refinements of security requirements are denoted in such a
way that added words are in bold text and changed words are crossed out.
The selection operation is used to select one or more options provided by [PPT] or CC
in stating a requirement. Selections having been made are denoted as underlined text.
The assignment operation is used to assign a specific value to an unspecified
parameter, such as the length of a password. Assignments having been made are
denoted by showing as underlined text.
The iteration operation is used when a component is repeated with varying operations.
Iteration is denoted by showing a slash “/”, and the iteration indicator after the
component identifier. In order to trace elements belonging to a component, the same
slash “/” with iteration indicator is used behind the elements of a component.
For the sake of a better readability, an additional notation is used in order to indicate
belonging of some SFRs to same functional cluster, namely a double slash “//” with the
related functional group indicator after the component identifier. In order to trace
elements belonging to a component, the same double slash “//” with functional cluster
indicator is used behind the elements of a component.
Whenever an element in [PPT] contains an operation that the PP author left
uncompleted, the ST author has to complete that operation and the operation within the
ST is shown with yellow background.
8.1 Security Functional Requirements
The security functional requirements are as derived in the protection profile BSI-CC-PP-
0057 ([PPT] chapter 6.1) which covers the SEFs from the generic security target (see
[GST] chapter 4) as demonstrated in ([PPT] chapter 6.1) and documented in ([PPT]
Annex A chapter 9).
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 39 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
In the following the necessary assignments as foreseen by [PPT] for the SFRs in the
protection profile and the necessary enhancements for software-update functionality
and remote download access are processed. For the remote download functionality, the
corresponding application notes are considered as recommended in the [PPT]. For the
software-update functionality, some new SFRs are included. Hereby, the security
functionality defined in the PP is not constricted.
SFRs below include – if adequate - in curly braces {…} a list of SEFs related. This not
only explains why the given SFR has been chosen, but moreover is used to state further
detail of the SFR without verbose repetition of the original text of the corresponding
SEF(s) from [GST]. The main advantage of this approach is avoiding redundancy, and,
more important, any unambiguity.
The complete coverage of the SEF(s) from [GST] is documented in the protection profile
[PPT] Annex A, chap. 9.
8.1.1 Overview
In order to give an overview of the security functional requirements in the context of the
security services offered by the TOE, the author of the ST defined the security
functional groups as given in the [PPT] and allocated the functional requirements
described in the following sections to them. For better comparison, the security
functional groups are copied from [PPT] and the additional functional requirements are
shown with yellow background.
Security Functional Groups Security Functional Requirements concerned
Identification and
authentication of motion
sensor, tachograph cards
(according to [GST], sec. 4.1)
– FIA_UID.2/MS: Identification of the motion sensor
– FIA_UID.2/TC: Identification of the tachograph
cards
– (FIA_UAU.2//MS, FIA_UAU.3/MS,
FIA_UAU.6/MS): Authentication of the motion
sensor
– (FIA_UAU.1/TC, FIA_UAU.3/TC, FIA_UAU.5//TC,
FIA_UAU.6/TC): Authentication of the tachograph
cards
– FIA_UAU.1/PIN: additional PIN authentication for
the workshop card
– FIA_AFL.1/MS: Authentication failure: motion
sensor
– FIA_AFL.1/TC: Authentication failure: tachograph
cards
– (FIA_ATD.1//TC, FMT_SMR.1//TC): User groups
to be maintained by the TOE
Supported by:
– FCS_COP.1/TDES: for the motion sensor
– FCS_COP.1/RSA: for the tachograph cards
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 40 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Security Functional Groups Security Functional Requirements concerned
– (FCS_CKM.1, FCS_CKM.2, FCS_CKM.3,
FCS_CKM.4): cryptographic key management
– FAU_GEN.1: Audit records: Generation
– (FMT_MSA.1, FMT_SMF.1/PP)
– FIA_AFL.1/Remote: remote TC authentication
failure handling
Access control to functions
and stored data (according to
[GST], sec. 4.2)
– (FDP_ACC.1/FIL, FDP_ACF.1/FIL): file structures
– (FDP_ACC.1/FUN, FDP_ACF.1/FUN): functions
– (FDP_ACC.1/DAT, FDP_ACF.1/DAT): stored data
– (FDP_ACC.1/UDE, FDP_ACF.1/UDE): user data
export
– (FDP_ACC.1/IS, FDP_ACF.1/IS): input sources
– FDP_ACC.1/SW-Upgrade: authenticate the
software upgrades as destined for a particular TOE
– FDP_ACF.1/SW-Upgrade: capability to control
access to the TSF software upgrade function
Supported by:
– (FIA_UAU.2//MS, FIA_UAU.3/MS,
FIA_UAU.6/MS): Authentication of the motion
sensor
– (FIA_UAU.1/TC, FIA_UAU.3/TC, FIA_UAU.5//TC,
FIA_UAU.6/TC): Authentication of the tachograph
cards
– FIA_UAU.1/PIN: additional PIN authentication for
the workshop card
– FMT_MSA.3/FIL
– FMT_MSA.3/FUN
– FMT_MSA.3/DAT
– FMT_MSA.3/UDE
– FMT_MSA.3/IS
– (FMT_MSA.1, FMT_SMF.1/PP, FMT_SMR.1//TC)
Accountability of users
(according to [GST], sec. 4.3)
– FAU_GEN.1: Audit records: Generation
– FAU_STG.1: Audit records: Protection against
modification
– FAU_STG.4: Audit records: Prevention of loss
– FDP_ETC.2: Export of user data with security
attributes
Supported by:
– (FDP_ACC.1/DAT, FDP_ACF.1/DAT): VU
identification data
– (FDP_ACC.1/UDE, FDP_ACF.1/UDE): Data
update on the TC
– FPT_STM.1: time stamps
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 41 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Security Functional Groups Security Functional Requirements concerned
– FCS_COP.1/TDES: for the motion sensor and the
tachograph cards
Audit of events and faults
(according to [GST], sec. 4.4)
– FAU_GEN.1: Audit records: Generation
– FAU_SAR.1: Audit records: Capability of reviewing
Supported by:
– (FDP_ACC.1/DAT, FDP_ACF.1/DAT): Storing
motion sensor’s audit records
– FDP_ETC.2 Export of user data with security
attributes: Related audit records to the TC.
Object reuse for secret data
(according to [GST], sec. 4.5)
– FDP_RIP.1 Subset residual information protection
Supported by:
– FCS_CKM.4: Cryptographic key destruction
Accuracy of recorded and
stored data (according to
[GST], sec. 4.6) and of SW-
upgrade data
– FDP_ITC.1: right input sources without sec.
attributes (keyboard, calibration data, RTC)
– FDP_ITC.2/IS: right input sources with sec.
attributes (MS and TC)
– FPT_TDC.1/IS: Inter-TSF basic TSF data
consistency (MS and TC)
– FDP_SDI.2: Stored data integrity
Supported by:
– (FDP_ACC.1/IS, FDP_ACF.1/IS): right input
sources
– (FDP_ACC.1/FUN, FDP_ACF.1/FUN): limited
manual entry
– FAU_GEN.1: Audit records: Generation
– FPT_STM.1: Reliable time stamps
– FPT_TDC.1/SW-Upgrade: capability to ensure the
consistency of data for the update
– FCS_COP.1/AES: for decryption and CMAC
verification of the software update data
– (FIA_UAU.2//MS, FIA_UAU.3/MS,
FIA_UAU.6/MS): Authentication of the motion
sensor
– (FIA_UAU.1/TC, FIA_UAU.3/TC, FIA_UAU.5//TC,
FIA_UAU.6/TC): Authentication of the tachograph
cards
Reliability of services
(according to [GST], sec. 4.7)
– FDP_ITC.2/IS: no executable code from external
sources
– FDP_ITC.2/SW-Upgrade: definition of conditions
for update acceptance
– FPR_UNO.1: Unobserveability of leaked data
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 42 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Security Functional Groups Security Functional Requirements concerned
– FPT_FLS.1: Failure with preservation of secure
state
– FPT_PHP.2//Power_Deviation: Notification of
physical attack
– FPT_PHP.3: Resistance to physical attack: stored
data
– FPT_TST.1: TSF testing
– FRU_PRS.1: Availability of services
Supported by:
– FAU_GEN.1: Audit records: Generation
– (FDP_ACC.1/IS, FDP_ACF.1/IS): no executable
code from external sources
– (FDP_ACC.1/FUN, FDP_ACF.1/FUN):
Tachograph Card withdrawal
– FMT_MOF.1: No test entry points
Data exchange with motion
sensor, tachograph cards and
external media (download
function)
(according to [GST], sec. 4.8)
– FCO_NRO.1: Selective proof of origin for data to
be downloaded to external media
– FDP_ETC.2 Export of user data with security
attributes: to the TC and to external media
– FDP_ITC.2/IS Import of user data with security
attributes: from the MS and the TC
Supported by:
– FCS_COP.1/TDES: for the motion sensor and the
tachograph cards (secure messaging)
– FCS_COP.1/RSA: for data downloading to
external media (signing)
– (FCS_CKM.1, FCS_CKM.2, FCS_CKM.3,
FCS_CKM.4): cryptographic key management
– (FDP_ACC.1/UDE, FDP_ACF.1/UDE): User data
export to the TC and to external media
– (FDP_ACC.1/IS, FDP_ACF.1/IS): User data
import from the MS and the TC
– FAU_GEN.1: Audit records: Generation
Management of and access to
TSF and TSF-data
– The entire class FMT.
Supported by:
– the entire class FIA: user
identification/authentication
Table 6: Security Functional Groups vs. Security Functional Requirements
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 43 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Note that in the following all additional SFRs and all completed operations compared to
[PPT] are shown with yellow background.
8.1.2 Class FAU Security Audit
8.1.2.1 FAU_GEN Security audit data generation
FAU_GEN.1 Audit data generation {UIA_206, UIA_214, ACT_201, ACT_203,
ACT_204, ACT_205, AUD_201, AUD_202, AUD_203, ACR_205, RLB_203,
RLB_206, RLB_210, RLB_214, DEX_202, DEX_204}
Hierarchical to: -
Dependencies: FPT_STM.1 Reliable time stamps: is fulfilled by FPT_STM.1
FAU_GEN.1.1 The TSF shall be able to generate an audit record of the
following auditable events:
a) Start-up and shutdown of the audit functions;
b) All auditable events for the not specified level of audit;
and
c) the activities and auditable events specified in REQ
081, 084, 087, 090, 093, 094, 096, 098, 101, 102,
103, and 105a20
and {UIA_206, UIA_214, AUD_202,
ACR_205, RLB_203, RLB_206, RLB_210,
RLB_21421
, DEX_202, DEX_204};
RLB_208, UIA_220.
FAU_GEN.1.2 The TSF shall record within each audit record at least the
following information:
a) Date and time of the event, type of event, subject
identity, and the outcome (success or failure) of the
event; and
b) For each audit event type, based on the auditable
event definitions of the functional components
included in the PP/ST, the information specified in
{REQ 081, 084, 087, 090, 093, 094, 096, 098, 101,
102, 103, 105a22
};
none.
8.1.2.2 FAU_SAR Security audit review
FAU_SAR.1 Audit review {AUD_205}
Hierarchical to: -
20
all these REQ are referred to in {ACT_201, ACT_203, ACT_204, ACT_205, AUD_201, AUD_203}
21
Last card session not correctly closed
22
all these REQ are referred to in {ACT_201, ACT_203, ACT_204, ACT_205, AUD_203}
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 44 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Dependencies: FAU_GEN.1 Audit data generation: is fulfilled by
FAU_GEN.1
FAU_SAR.1.1 The TSF shall provide everybody with the capability to read
the recorded information according to REQ011 from the audit
records.
FAU_SAR.1.2 The TSF shall provide the audit records in a manner suitable
for the user to interpret the information.
8.1.2.3 FAU_STG Security audit event storage
FAU_STG.1 Protected audit trail storage {ACT_206}23
Hierarchical to: -
Dependencies: FAU_GEN.1 Audit data generation: is fulfilled by
FAU_GEN.1
FAU_STG.1.1 The TSF shall protect the stored audit records in the audit
trail from unauthorised deletion.
FAU_STG.1.2 The TSF shall be able to detect unauthorised modifications
to the stored audit records in the audit trail.
FAU_STG.4 Prevention of audit data loss {ACT_206}24
Hierarchical to: FAU_STG.3
Dependencies: FAU_STG.1 Protected audit trail storage: is fulfilled by
FAU_STG.1
FAU_STG.4.1 The TSF shall overwrite the oldest stored audit records and
behave according to REQ 083, 086, 089, 092 and 105b, if
the audit trail is full.
8.1.3 Class FCO Communication
8.1.3.1 FCO_NRO Non-repudiation of origin
FCO_NRO.1 Selective proof of origin {DEX_206, DEX_207}
Hierarchical to: -
Dependencies: FIA_UID.1 Timing of identification: not fulfilled, but justified
the components FIA_UID.2/MS, FIA_UID.2/TC being present
in the PP do not fulfil this dependency, because they are not
affine to DEX_206, DEX_207 (data download).
The sense of the current dependency would be to attach the
VU identity (ACT_202) to the data to be downloaded; the VU
identification data are permanently stored in the VU, so that
23
REQ081 to 093 and REQ102 to 105a
24
REQ 083, 086, 089, 092, 105b; REQ105b is completely covered by ACT_206.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 45 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
the VU always ‘knows’ its own identity.
FCO_NRO.1.1 The TSF shall be able to generate evidence of origin for
transmitted data to be downloaded to external media at the
request of the originator.
FCO_NRO.1.2 The TSF shall be able to relate the VU identity of the
originator of the information, and the data to be downloaded
to external media of the information to which the evidence
applies.
FCO_NRO.1.3 The TSF shall provide a capability to verify the evidence of
origin of information to the recipient given
- according to specification [CSM], sec. 6.1,
limited to the scope as required in {DEX_207} and {DEX
208}.
8.1.4 Class FCS Cryptographic Support
8.1.4.1 FCS_CKM Cryptographic key management
FCS_CKM.1 Cryptographic key generation {CSP_202}
Hierarchical to: -
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]: is fulfilled by
FCS_CKM.2;
FCS_CKM.4 Cryptographic key destruction: is fulfilled by
FCS_CKM.4
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance
with a specified cryptographic key generation algorithm
cryptographic key derivation algorithms (for the session keys
KSM and KST as well as for the temporarily stored keys Km, KP
and KID) and specified cryptographic key sizes 112 bits that
meet the following: list of standards:
a) Km, KP, KID and KSM: two-keys TDES as specified in
[ISO16844];
b) KST: two-keys TDES as specified in [CSM].
FCS_CKM.2 Cryptographic key distribution {CSP_203}
Hierarchical to: -
Dependencies: [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]: is fulfilled by
FCS_CKM.1
FCS_CKM.4: is fulfilled by FCS_CKM.4
FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance
with a specified cryptographic key distribution method as
specified in the list below that meets the following list of
standards:
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 46 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
a) KSM: as specified in [ISO16844], sec. 7.4.5;
b) KST: as specified in [CSM], CSM_020.
FCS_CKM.3 Cryptographic key access {CSP_204}
Hierarchical to: -
Dependencies: [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]:
a) fulfilled by FCS_CKM.1 for the session keys KSM and
KST as well as for the temporarily stored keys Km, KP
and KID;
b) fulfilled by FDP_ITC.2/IS for the temporarily stored
key Kmwc (entry DEX_203); fulfilled by
FDP_ITC.2/SW-Upgrade for the temporarily stored
keys KAuth, KFirmware-SC and KFirmware-MC;
c) not fulfilled, but justified for EUR.PK, EQT.SK, Kmvu,
KENCUpdateVu and KAUTHUpdateVu: The persistently
stored keys (EUR.PK, EQTj.SK, Kmvu, KENCUpdateVu
and KAUTHUpdateVu) will be loaded into the TOE
outside of its operational phase, cf. also
OE.Sec_Data_xx.
FCS_CKM.4: is fulfilled by FCS_CKM.4
FCS_CKM.3.1 The TSF shall perform cryptographic key access and storage
in accordance with a specified cryptographic key access
method as specified below that meets the following list of
standards:
a) Kmwc: part of the Master key read out from the
workshop card and temporarily stored in the TOE
(calibration phase);
b) Km: temporarily reconstructed from part of the Master
key Kmvu and part of the Master key Kmwc as specified
in [ISO16844], sec. 7.2 and in [CSM], sec. 3.1.3,
CSM_036, CSM_037 (calibration phase);
c) KID: temporarily reconstructed from the Master key Km
as specified in [ISO16844], sec. 7.2, 7.4.3 (calibration
phase);
d) KP: temporarily reconstructed from Enc(Km|KP) as
specified in [ISO16844], sec. 7.2, 7.4.3 (calibration
phase);
e) KSM: internally generated and temporarily stored
during a session between the TOE and the motion
sensor connected (calibration and operational
phases);
f) KST: internally generated and temporarily stored during
a session between the TOE and the tachograph card
connected (calibration and operational phases);
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 47 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
g) EUR.PK: stored during manufacturing of the TOE
(calibration and operational phases);
h) EQTj.SK: stored during manufacturing of the TOE
(calibration and operational phases);
i) part of the Master key Kmvu: stored during
manufacturing of the TOE (calibration and operational
phases);
j) SW-Update Keys - KENCUpdateVu and KAUTHUpdateVu:
stored during manufacturing of the TOE; KAuth,
KFirmware-SC and KFirmware-MC: stored during the
software update process.
FCS_CKM.4 Cryptographic key destruction {CSP_205}
Hierarchical to: -
Dependencies: [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]: see explanation
for FCS_CKM.3 above
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with
a specified cryptographic key destruction method as
specified below that meets the following list of standards:
a) Kmwc: delete after use (at most by the end of the
calibration phase);
b) Km: delete after use (at most by the end of the
calibration phase);
c) KID: delete after use (at most by the end of the
calibration phase);
d) KP: delete after use (at most by the end of the
calibration phase);
e) KSM: delete by replacement (by closing a motion
sensor communication session during the next pairing
process);
f) KST: delete by replacement (by closing a card
communication session);
g) EUR.PK: this public key does not represent any secret
and, hence, needn’t to be deleted;
h) EQTj.SK: will be loaded into the TOE outside of its
operational phase, cf. also OE.Sec_Data_xx and must
not be destroyed as long as the TOE is operational;
i) part of the Master key Kmvu: will be loaded into the
TOE outside of its operational phase, cf. also
OE.Sec_Data_xx and must not be destroyed as long
as the TOE is operational;
j) SW-Update Keys - KENCUpdateVu and KAUTHUpdateVu:
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 48 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
will be loaded into the TOE outside of its operational
phase, cf. also OE.Sec_Data_xx, and must not be
destroyed as long as the TOE is operational; KAuth,
KFirmware-SC and KFirmware-MC: delete after use (at the
end of the software update process);
k) Each deletion denoted above means value overwriting
with “FF”.
The component FCS_CKM.4 relates to any instantiation of cryptographic keys independent of
whether it is of temporary or permanent nature. In contrast, the component FDP_RIP.1 concerns in
this PP only the temporarily stored instantiations of objects in question.
The permanently stored instantiations of EQTj.SK and of the part of the Master key Kmvu must not be
destroyed as long as the TOE is operational. Making the permanently stored instantiations of EQTj.SK
and of the part of the Master key Kmvu unavailable at decommissioning the TOE is a matter of the
related organisational policy.
8.1.4.2 FCS_COP Cryptographic operation
FCS_COP.1/TDES Cryptographic operation {CSP_201}
Hierarchical to: -
Dependencies: [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]: is fulfilled by
FCS_CKM.1
FCS_CKM.4: is fulfilled by FCS_CKM.4
FCS_COP.1.1/TDES The TSF shall perform the cryptographic operations
(encryption, decryption, Retail-MAC) in accordance with
a specified cryptographic algorithm Triple DES in CBC
and ECB modes and cryptographic key size 112 bits that
meet the following:[ISO16844] for the Motion Sensor
and [CSM] for the Tachograph Cards.
FCS_COP.1/AES Cryptographic operation
Hierarchical to: -
Dependencies: [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]:
a) fulfilled by FDP_ITC.2/SW-Upgrade for the
temporarily stored keys KAuth, KFirmware-SC and
KFirmware-MC;
b) not fulfilled, but justified for KENCUpdateVu and
KAUTHUpdateVu: The persistently stored keys
KENCUpdateVu and KAUTHUpdateVu will be loaded
into the TOE outside of its operational phase, cf.
also OE.Sec_Data_xx.
FCS_CKM.4: is fulfilled by FCS_CKM.4
FCS_COP.1.1/AES The TSF shall perform the cryptographic operations
(decryption and data integrity protection) in accordance
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 49 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
with a specified cryptographic algorithm AES in CBC
mode and CMAC and cryptographic key size 128 bits
that meet the following: [FIPS 197] (AES), [NIST SP800-
38A] (AES CBC mode) and [NIST SP800-38B] (AES
CMAC).
FCS_COP.1/RSA Cryptographic operation {CSP_201}
Hierarchical to: -
Dependencies: [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1]: not fulfilled,
but justified
It is a matter of RSA decrypting and verifying in the
context of CSM_020 (VU<->TC authentication) and of
RSA signing according to CSM_034 using static keys
imported outside of the VU’s operational phase
(OE.Sec_Data_xx).
FCS_CKM.4: is fulfilled by FCS_CKM.4
FCS_COP.1.1/RSA The TSF shall perform the cryptographic operations
(decryption, verifying for the Tachograph Cards
authentication and signing for downloading to external
media) in accordance with a specified cryptographic
algorithm RSA and cryptographic key size 1024 bits that
meet the following: [CSM], CSM_020 for the Tachograph
Cards authentication and [CSM], CSM_034 for
downloading to external media, respectively.
8.1.5 Class FDP User Data Protection
8.1.5.1 FDP_ACC Access control policy
FDP_ACC.1/FIL Subset access control {ACC_211}
Hierarchical to: -
Dependencies: FDP_ACF.1: is fulfilled by FDP_ACF.1/FIL
FDP_ACC.1.1/FIL The TSF shall enforce the File_Structure SFP on
tachograph application and data files structure as required
by ACC_211.
FDP_ACC.1/FUN Subset access control {ACC_201}
Hierarchical to: -
Dependencies: FDP_ACF.1: is fulfilled by FDP_ACF.1/FUN
FDP_ACC.1.1/FUN The TSF shall enforce the SFP FUNCTION on subjects,
objects, and operations as referred to in
- operational modes {ACC_202} and the related
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 50 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
restrictions on access rights {ACC_203},
- calibration functions {ACC_206} and time adjustment
{ACC_208},
- limited manual entry {ACR_201a}, and
- Tachograph Card withdrawal {RLB_213}
as required by ACC_201.
FDP_ACC.1/DAT Subset access control {ACC_201}
Hierarchical to: -
Dependencies: FDP_ACF.1: is fulfilled by FDP_ACF.1/DAT
FDP_ACC.1.1/DAT The TSF shall enforce the SFP DATA on subjects,
objects, and operations as referred to in:
- VU identification data: REQ075 (structure) {ACT_202}
and REQ076 (once recorded) {ACC_204},
- MS identification data: REQ079 (Manufacturing-ID) and
REQ155 (pairing) {ACC_205},
- Calibration Mode Data: REQ097 {ACC_207} and
REQ100 {ACC_209},
- Security Data: REQ080 {ACC_210},
- MS Audit Records: {AUD_204} as required by ACC_201.
FDP_ACC.1/SW-Upgrade Subset access control {ACC_201}
Hierarchical to: -
Dependencies: FDP_ACF.1: is fulfilled by FDP_ACF.1/SW-Upgrade
FDP_ACC.1.1/
SW-Upgrade
The TSF shall enforce the SFP SW_Upgrade on
updateable software components and User with identity
UNKNOWN for updates of MC software components and
User with identity WORKSHOP for updates of SC software
components.
FDP_ACC.1/UDE Subset access control {ACT_201, ACT_203, ACT_204}: REQ 109
and 109a
Hierarchical to: -
Dependencies: FDP_ACF.1: is fulfilled by FDP_ACF.1/UDE
FDP_ACC.1.1/U
DE
The TSF shall enforce the SFP User_Data_Export on
subjects, objects, and operations as required by REQ 109
and 109a.
FDP_ACC.1/IS Subset access control {ACR_201, RLB_205}
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 51 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Hierarchical to: -
Dependencies: FDP_ACF.1: is fulfilled by FDP_ACF.1/IS
FDP_ACC.1.1/IS The TSF shall enforce the SFP Input_Sources on subjects,
objects, and operations as required by ACR_201 (right input
sources) and RLB_205 (no external executable code).
8.1.5.2 FDP_ACF Access control functions
FDP_ACF.1/FIL Security attribute based access control {ACR_211}
Hierarchical to: -
Dependencies: FDP_ACC.1: is fulfilled by FDP_ACC.1/FIL
FMT_MSA.3: is fulfilled by FMT_MSA.3/FIL
FDP_ACF.1.1/FIL The TSF shall enforce the File_Structure SFP to objects
based on the following: the entire files structure of the TOE-
application as required by {ACC_211}.
FDP_ACF.1.2/FIL The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects
is allowed: none.
FDP_ACF.1.3/FIL The TSF shall explicitly authorise access of subjects to
objects based on the following additional rules: none.
FDP_ACF.1.4/FIL The TSF shall explicitly deny access of subjects to objects
based on the following additional rules as required by
{ACC_211}.
FDP_ACF.1/FUN Security attribute based access control {ACC_202, ACC_203,
ACC_206, ACC_208, ACR_201a, RLB_213}
Hierarchical to: -
Dependencies: FDP_ACC.1: is fulfilled by FDP_ACC.1/FUN
FMT_MSA.3: is fulfilled by FMT_MSA.3/FUN
FDP_ACF.1.1/FUN The TSF shall enforce the SFP FUNCTION to objects
based on the following: subjects, objects, and their
attributes as referred to in:
- operational modes {ACC_202} and the related
restrictions on access rights {ACC_203},
- calibration functions {ACC_206} and time adjustment
{ACC_208},
- limited manual entry {ACR_201a}, and
- Tachograph Card withdrawal {RLB_213}.
FDP_ACF.1.2/FUN The TSF shall enforce the following rules to determine if
an operation among controlled subjects and controlled
objects is allowed: rules in {ACC_202, ACC_203,
ACC_206, ACC_208, ACR_201a, RLB_213}.
FDP_ACF.1.3/FUN The TSF shall explicitly authorise access of subjects to
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 52 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
objects based on the following additional rules: none.
FDP_ACF.1.4/FUN The TSF shall explicitly deny access of subjects to objects
based on the following additional rules: none.
FDP_ACF.1/DAT Security attribute based access control {ACC_204, ACC_205,
ACC_207, ACC_209, ACC_210, ACT_202, AUD_204}
Hierarchical to: -
Dependencies: FDP_ACC.1: is fulfilled by FDP_ACC.1/DAT
FMT_MSA.3: is fulfilled by FMT_MSA.3/DAT
FDP_ACF.1.1/DAT The TSF shall enforce the SFP DATA to objects based on
the following: subjects, objects, and their attributes as
referred to in:
- VU identification data: REQ075 (structure) {ACT_202}
and REQ076 (once recorded) {ACC_204},
- MS identification data: REQ079 (Manufacturing-ID) and
REQ155 (pairing) {ACC_205},
- Calibration Mode Data: REQ097 {ACC_207} and
REQ100 {ACC_209},
- Security Data: REQ080 {ACC_210},
- MS Audit Records: {AUD_204}.
FDP_ACF.1.2/DAT The TSF shall enforce the following rules to determine if
an operation among controlled subjects and controlled
objects is allowed: the access rules as required by
{ACC_204, ACC_205, ACC_207, ACC_209, ACC_210,
ACT_202, AUD_204}.
FDP_ACF.1.3/DAT The TSF shall explicitly authorise access of subjects to
objects based on the following additional rules: none.
FDP_ACF.1.4/DAT The TSF shall explicitly deny access of subjects to
objects based on the following additional rules: none.
FDP_ACF.1/UDE Security attribute based access control {ACT_201, ACT_203,
ACT_204} (REQ109 and 109a)
Hierarchical to: -
Dependencies: FDP_ACC.1: is fulfilled by FDP_ACC.1/UDE
FMT_MSA.3: is fulfilled by FMT_MSA.3/UDE
FDP_ACF.1.1/UDE The TSF shall enforce the SFP User_Data_Export to
objects based on the following: subjects, objects, and
their attributes as required by REQ 109 and 109a.
FDP_ACF.1.2/UDE The TSF shall enforce the following rules to determine if
an operation among controlled subjects and controlled
objects is allowed: rules in REQ109 and 109a.
FDP_ACF.1.3/UDE The TSF shall explicitly authorise access of subjects to
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 53 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
objects based on the following additional rules: none.
FDP_ACF.1.4/UDE The TSF shall explicitly deny access of subjects to
objects based on the following additional rules: none.
FDP_ACF.1/IS Security attribute based access control {ACR_201, RLB_205}
Hierarchical to: -
Dependencies: FDP_ACC.1: is fulfilled by FDP_ACC.1/IS
FMT_MSA.3: is fulfilled by FMT_MSA.3/IS
FDP_ACF.1.1/IS The TSF shall enforce SFP Input_Sources to objects based
on the following: subjects, objects, and their attributes as
required by ACR_201 (right input sources) and RLB_205 (no
external executable code).
FDP_ACF.1.2/IS The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed: rules in {ACR_20125
}.
FDP_ACF.1.3/IS The TSF shall explicitly authorise access of subjects to
objects based on the following additional rules: none.
FDP_ACF.1.4/IS The TSF shall explicitly deny access of subjects to objects
based on the following additional rules as required by
{RLB_205}.
FDP_ACF.1/SW-Upgrade Security attribute based access control
Hierarchical to: -
Dependencies: FDP_ACC.1: is fulfilled by FDP_ACC.1/SW-Upgrade
FMT_MSA.3: not fulfilled but justified:
For an update, the patch data are accepted only together
with the corresponding credentials, which contain all
information needed for verification. So, it is not necessary
to initialise any static attributes.
FDP_ACF.1.1/SW-
Upgrade
The TSF shall enforce SFP SW_Upgrade to objects
based on the following: updateable software components
may be exchanged if the integrity and the authenticity of
the patch data is confirmed with help of the update
credentials.
FDP_ACF.1.2/SW-
Upgrade
The TSF shall enforce the following rules to determine if
an operation among controlled subjects and controlled
objects is allowed:
- update of SC software components is only possible after
workshop card authentication,
- update of software components is only possible if the
25
Especially for MS and TC
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 54 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
integrity and the authenticity of the patch data were
confirmed with help of the update credentials.
FDP_ACF.1.3/SW-
Upgrade
The TSF shall explicitly authorise access of subjects to
objects based on the following additional rules: none.
FDP_ACF.1.4/SW-
Upgrade
The TSF shall explicitly deny access of subjects to
objects based on the following additional rules: none.
8.1.5.3 FDP_ETC Export from the TOE
FDP_ETC.2 Export of user data with security attributes {ACT_201, ACT_203,
ACT_204, ACT_207, AUD_201, DEX_205, DEX_208} (REQ109 and 109a)
Hierarchical to: -
Dependencies: [FDP_ACC.1 or FDP_IFC.1]: is fulfilled by FDP_ACC.1/UDE
FDP_ETC.2.1 The TSF shall enforce the SFP User_Data_Export when
exporting user data, controlled under the SFP(s), outside of
the TOE.
FDP_ETC.2.2 The TSF shall export the user data with the user data's
associated security attributes.
FDP_ETC.2.3 The TSF shall ensure that the security attributes, when
exported outside the TOE, are unambiguously associated
with the exported user data.
FDP_ETC.2.4 The TSF shall enforce the following rules when user data is
exported from the TOE: REQ110, DEX_205, DEX_208.
8.1.5.4 FDP_ITC Import from outside of the TOE
FDP_ITC.1 Import of user data without security attributes {ACR_201}
Hierarchical to: -
Dependencies: [FDP_ACC.1 or FDP_IFC.1]: is fulfilled by FDP_ACC.1/IS
FMT_MSA.3: is fulfilled by FMT_MSA.3/IS
FDP_ITC.1.1 The TSF shall enforce the SFP Input_Sources when
importing user data, controlled under the SFP, from outside
of the TOE.
FDP_ITC.1.2 The TSF shall ignore any security attributes associated with
the user data when imported from outside the TOE.
FDP_ITC.1.3 The TSF shall enforce the following rules when importing
user data controlled under the SFP from outside the TOE: as
required by {ACR_201} for recording equipment calibration
parameters and user’s inputs.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 55 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
FDP_ITC.2/IS Import of user data with security attributes {ACR_201, RLB_205,
DEX_201, DEX_202, DEX_203, DEX_204}
Hierarchical to: -
Dependencies: [FDP_ACC.1 or FDP_IFC.1]: is fulfilled by FDP_ACC.1/IS
[FTP_ITC.1 or FTP_TRP.1]: not fulfilled, but justified:
Indeed, trusted channels VU<->MS and VU<->TC will be
established. Since the component FTP_ITC.1 represents just
a higher abstraction level integrative description of this
property and does not define any additional properties
comparing to {FDP_ITC.2/IS + FDP_ETC.2 + FIA_UAU.1/TC
(and /MS)}, it can be dispensed with this dependency in the
current context of the PP.
FPT_TDC.1: is fulfilled by FPT_TDC.1/IS
FDP_ITC.2.1/IS The TSF shall enforce the SFP Input_Sources when
importing user data, controlled under the SFP, from outside
of the TOE.
FDP_ITC.2.2/IS The TSF shall use the security attributes associated with the
imported user data.
FDP_ITC.2.3/IS The TSF shall ensure that the protocol used provides for the
unambiguous association between the security attributes and
the user data received.
FDP_ITC.2.4/IS The TSF shall ensure that interpretation of the security
attributes of the imported user data is as intended by the
source of the user data.
FDP_ITC.2.5/IS The TSF shall enforce the following rules when importing
user data controlled under the SFP from outside the TOE as
required by:
- [ISO16844] for the Motion Sensor {ACR_201, DEX_201},
- DEX_202 (audit record and continue to use imported data),
- [CSM] for the Tachograph Cards {ACR_201, DEX_203},
- DEX_204 (audit record and not using of the data),
- RLB_205 (no executable code from external sources).
FDP_ITC.2/SW-Upgrade Import of user data26
with security attributes
Hierarchical to: -
Dependencies: [FDP_ACC.1 or FDP_IFC.1]: is fulfilled by FDP_ACC.1/SW-
Upgrade
[FTP_ITC.1 or FTP_TRP.1]: not fulfilled, but justified:
For an update, the patch data are accepted only together
with the corresponding credentials, which contain all
information needed for verification. So, it is not necessary to
establish trusted channel or trusted path.
FPT_TDC.1: is fulfilled by FPT_TDC.1/SW-Upgrade
26
User data means here patch data as well as credentials material needed for software updates
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 56 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
FDP_ITC.2.1/S
W-Upgrade
The TSF shall enforce the SFP SW_Upgrade when importing
user data, controlled under the SFP, from outside of the
TOE.
FDP_ITC.2.2/S
W-Upgrade
The TSF shall use the security attributes associated with the
imported user data.
FDP_ITC.2.3/S
W-Upgrade
The TSF shall ensure that the protocol used provides for the
unambiguous association between the security attributes and
the user data received.
FDP_ITC.2.4/S
W-Upgrade
The TSF shall ensure that interpretation of the security
attributes of the imported user data is as intended by the
source of the user data.
FDP_ITC.2.5/S
W-Upgrade
The TSF shall enforce the following rules when importing
user data controlled under the SFP from outside the TOE:
update of the indicated software components only if the
integrity and the authenticity of the patch data is confirmed
with help of the update credentials.
8.1.5.5 FDP_RIP Residual information protection
FDP_RIP.1 Subset residual information protection {REU_201}
Hierarchical to: -
Dependencies: -
FDP_RIP.1.1 The TSF shall ensure that any previous information content
of a temporarily stored resource is made unavailable upon
the allocation of the resource to the following objects:
a) Kmwc: workshop card part of the motion sensor master
key (at most by the end of the calibration phase);
b) Km: motion sensor master key (at most by the end of
the calibration phase);
c) KID: motion sensor identification key (at most by the
end of the calibration phase);
d) KP: motion sensor pairing key (at most by the end of
the calibration phase);
e) KSM: session key between motion sensor and vehicle
unit (when its temporarily stored value shall not be
used any more);
f) KST: session key between tachograph cards and
vehicle unit (by closing a card communication
session);
g) EQTj.SK: equipment private key (when its temporarily
stored value shall not be used any more);
h) Kmvu: VU part of the motion sensor master key (when
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 57 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
its temporarily stored value shall not be used any
more);
i) PIN: the verification value of the workshop card PIN
temporarily stored in the TOE during its calibration (at
most by the end of the calibration phase);
j) SW-Update Keys - KENCUpdateVu, KAUTHUpdateVu,
KAuth, KFirmware-SC and KFirmware-MC (when the
temporarily stored values shall not be used any more,
at most by the end of the software update).
The component FDP_RIP.1 concerns in this ST only the temporarily stored (e.g. in RAM) instantiations
of objects in question. In contrast, the component FCS_CKM.4 relates to any instantiation of
cryptographic keys independent of whether it is of temporary or permanent nature.
Making the permanently stored instantiations of EQTj.SK and of the part of the Master key Kmvu
unavailable at decommissioning the TOE is a matter of the related organisational policy.
The functional family FDP_RIP possesses such a general character, so that it is applicable not only to
user data (as assumed by the class FDP), but also to TSF-data; in this respect it is similar to the functional
family FPT_EMS. Applied to cryptographic keys, FDP_RIP.1 requires a certain quality metric (‘any
previous information content of a resource is made unavailable’) for key’s destruction in addition to
FCS_CKM.4 that merely requires a fact of key destruction according to a method/standard.
8.1.5.6 FDP_SDI Stored data integrity
FDP_SDI.2 Stored data integrity monitoring and action {ACR_204, ACR_205}
Hierarchical to: -
Dependencies: -
FDP_SDI.2.1 The TSF shall monitor user data stored in the TOE’s data
memory containers controlled by the TSF for integrity errors
on all objects, based on the following attributes: [assignment:
user data attributes].
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall
generate an audit record.
The context for the current SFR is built by the related requirements ACR_204, ACR_205 (sec. 4.6.3 of
[GST] ‘Stored data integrity’). This context gives a clue for interpretation that it is not a matter of
temporarily, but of permanently stored user data27
.
8.1.6 Class FIA Identification and Authentication
8.1.6.1 FIA_AFL Authentication failures
FIA_AFL.1/MS Authentication failure handling {UIA_206}
27
see definition in glossary
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 58 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Hierarchical to: -
Dependencies: FIA_UAU.1: is fulfilled by FIA_UAU.2//MS
FIA_AFL.1.1/MS The TSF shall detect when 20 unsuccessful authentication
attempts occur related to motion sensor authentication.
FIA_AFL.1.2/MS When the defined number of unsuccessful authentication
attempts has been surpassed, the TSF 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.
FIA_AFL.1/TC Authentication failure handling {UIA_214}
Hierarchical to: -
Dependencies: FIA_UAU.1: is fulfilled by FIA_UAU.1/TC
FIA_AFL.1.1/TC The TSF shall detect when 5 unsuccessful authentication
attempts occur related to tachograph card authentication.
FIA_AFL.1.2/TC When the defined number of unsuccessful authentication
attempts has been surpassed, the TSF shall
- generate an audit record of the event,
- warn the user,
- assume the user as Unknown User and the card as non
valid28
(definition (z) and REQ007).
FIA_AFL.1/Remote Authentication failure handling {UIA_214, UIA_220}
Hierarchical to: -
Dependencies: FIA_UAU.1: is fulfilled by FIA_UAU.1/TC
FIA_AFL.1.1/Re
mote
The TSF shall detect when 5 unsuccessful authentication
attempts occur related to tachograph card authentication.
FIA_AFL.1.2/Re
mote
When the defined number of unsuccessful authentication
attempts has been surpassed, the TSF shall
- generate an audit record of the event,
- warn the user,
- assume the user as Unknown User and the card as non
valid29
(definition (z) and REQ007).
- warn the remote station about having 5 unsuccessful
authentication attempts.
8.1.6.2 FIA_ATD User attribute definition
FIA_ATD.1//TC User attribute definition {UIA_208}
28
is commensurate with ‘Unknown equipment’ in the current PP
29
is commensurate with ‘Unknown equipment’ in the current PP
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 59 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Hierarchical to: -
Dependencies: -
FIA_ATD.1.1//T
C
The TSF shall maintain the following list of security attributes
belonging to individual users: as defined in {UIA_208,
UIA_216}.
8.1.6.3 FIA_UAU User authentication
FIA_UAU.1/TC Timing of authentication {UIA_209} and {UIA_217}
Hierarchical to: -
Dependencies: FIA_UID.1: is fulfilled by FIA_UID.2/TC
FIA_UAU.1.1/TC The TSF shall allow (i) TC identification as required by
FIA_UID.2.1/TC and (ii) reading out audit records as required
by FAU_SAR.1 on behalf of the user to be performed before
the user is authenticated30
.
FIA_UAU.1.2/TC The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated
actions on behalf of that user.
FIA_UAU.1/PIN Timing of authentication {UIA_212}
Hierarchical to: -
Dependencies: FIA_UID.1: is fulfilled by FIA_UID.2/TC31
FIA_UAU.1.1/PI
N
The TSF shall allow (i) TC (Workshop Card) identification as
required by FIA_UID.2.1/TC and (ii) reading out audit records
as required by FAU_SAR.1 on behalf of the user to be per-
formed before the user is authenticated32
.
FIA_UAU.1.2/PI
N
The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated
actions on behalf of that user.
FIA_UAU.2//MS User authentication before any action {UIA_203}33
.
30
According to CSM_20 in [CSM] the TC identification (certificate exchange) is to perform strictly before the mutual
authentication between the VU and the TC.
31
the PIN-based authentication is applicable for the workshop cards, whose identification is ruled by FIA_UID.2/TC
32
According to CSM_20 in [CSM] the TC identification (certificate exchange) is to perform strictly before the PIN
authentication of the Workshop Card.
33
Though MS identification happens before the MS authentication, they will be done within same command (80 or
11); hence, it is also plausible to choose here the functional component FIA_UAU.2.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 60 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Hierarchical to: FIA_UAU.1
Dependencies: FIA_UID.1: is fulfilled by FIA_UID.2/MS
FIA_UAU.2.1//M
S
The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated
actions on behalf of that user.
FIA_UAU.3/MS Unforgeable authentication {UIA_205}.
Hierarchical to: -
Dependencies: -
FIA_UAU.3.1/M
S
The TSF shall detect and prevent use of authentication data
that has been forged by any user of the TSF.
FIA_UAU.3.2/M
S
The TSF shall detect and prevent use of authentication data
that has been copied from any other user of the TSF.
FIA_UAU.3/TC Unforgeable authentication {UIA_213} and {UIA_219}.
Hierarchical to: -
Dependencies: -
FIA_UAU.3.1/TC The TSF shall detect and prevent use of authentication data
that has been forged by any user of the TSF.
FIA_UAU.3.2/TC The TSF shall detect and prevent use of authentication data
that has been copied from any other user of the TSF.
FIA_UAU.5//TC Multiple authentication mechanisms {UIA_211} and {UIA_218}.
Hierarchical to: -
Dependencies: -
FIA_UAU.5.1//T
C
The TSF shall provide multiple authentication mechanisms
according to CSM_20 in [CSM] to support user
authentication.
FIA_UAU.5.2//T
C
The TSF shall authenticate any user's claimed identity
according to the CSM_20 in [CSM].
FIA_UAU.6/MS Re-authenticating {UIA_204}.
Hierarchical to: -
Dependencies: -
FIA_UAU.6.1/M The TSF shall re-authenticate the user under the conditions:
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 61 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
S more frequently than once per hour, cf. UIA_204 in [GST].
FIA_UAU.6/TC Re-authenticating {UIA_210}.
Hierarchical to: -
Dependencies: -
FIA_UAU.6.1/TC The TSF shall re-authenticate the user under the conditions:
more frequently than once per day, cf. UIA_210 in [GST].
8.1.6.4 FIA_UID User identification
FIA_UID.2/MS User identification before any action {UIA_201}
Hierarchical to: FIA_UID.1
Dependencies: -
FIA_UID.2.1/MS The TSF shall require each user to be successfully identified
before allowing any other TSF-mediated actions on behalf of
that user.
FIA_UID.2/TC User identification before any action {UIA_207} and {UIA_215}
Hierarchical to: FIA_UID.1
Dependencies: -
FIA_UID.2.1/TC The TSF shall require each user to be successfully identified
before allowing any other TSF-mediated actions on behalf of
that user.
8.1.7 Class FPR Privacy
8.1.7.1 FPR_UNO Unobservability
FPR_UNO.1 Unobservability {RLB_204 for leaked data}
Hierarchical to: -
Dependencies: -
FPR_UNO.1.1 The TSF shall ensure that all users are unable to observe the
cryptographic operations as required by FCS_COP.1/AES,
FCS_COP.1/TDES and FCS_COP.1/RSA on cryptographic
keys being to keep secret (as listed in FCS_CKM.3 excepting
EUR.PK) by the TSF [assignment: list of protected users
and/or subjects].
‘To observe the cryptographic operations’ means here ‘using any TOE external
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 62 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
interface in order to gain the values of cryptographic keys which shall be kept secret’.
8.1.8 Class FPT Protection of the TSF
8.1.8.1 FPT_FLS Fail secure
FPT_FLS.1 Failure with preservation of secure state
Hierarchical to: -
Dependencies: -
FPT_FLS.1.1 The TSF shall preserve a secure state when the following
types of failures occur: as specified in {RLB_203, RLB_210,
RLB_211}.
8.1.8.2 FPT_PHP TSF physical protection
FPT_PHP.2//Power_Deviation Notification of physical attack {RLB_209}
Hierarchical to: FPT_PHP.1
Dependencies: FMT_MOF.1: not fulfilled, but justified:
It is a matter of RLB_209: this function (detection of
deviation) must not be deactivated by anybody. But
FMT_MOF.1 is formulated in a not applicable way for
RLB_209
FPT_PHP.2.1//P
ower_Deviation
The TSF shall provide unambiguous detection of physical
tampering that might compromise the TSF.
FPT_PHP.2.2//P
ower_Deviation
The TSF shall provide the capability to determine whether
physical tampering with the TSF's devices or TSF's elements
has occurred.
FPT_PHP.2.3//P
ower_Deviation
For the devices/elements for which active detection is
required in {RLB_209}, the TSF shall monitor the devices
and elements and notify the user and audit record generation
when physical tampering with the TSF's devices or TSF's
elements has occurred.
FPT_PHP.3 Resistance to physical attack {RLB_204 for stored data}
Hierarchical to: -
Dependencies: -
FPT_PHP.3.1 The TSF shall resist physical tampering attacks to the TOE
security enforcing part of the software in the field after the
TOE activation by responding automatically such that the
SFRs are always enforced.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 63 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
8.1.8.3 FPT_STM Time stamps
FPT_STM.1 Reliable time stamps {ACR_201}
Hierarchical to: -
Dependencies: -
FPT_STM.1.1 The TSF shall be able to provide reliable time stamps.
This requirement is the matter of the VU’s real time clock.
8.1.8.4 FPT_TDC Inter-TSF TSF Data Consistency
FPT_TDC.1/IS Inter-TSF basic TSF data consistency {ACR_201}
Hierarchical to: -
Dependencies: -
FPT_TDC.1.1/IS The TSF shall provide the capability to consistently interpret
secure messaging attributes as defined by [ISO16844] for
the Motion Sensor and by [CSM] for the Tachograph Cards
when shared between the TSF and another trusted IT
product.
FPT_TDC.1.2/IS The TSF shall use the interpretation rules (communication
protocols) as defined by [ISO16844] for the Motion Sensor
and by [CSM] for the Tachograph Cards when interpreting
the TSF data from another trusted IT product.
FPT_TDC.1/SW-Upgrade Inter-TSF basic TSF data consistency
Hierarchical to: -
Dependencies: -
FPT_TDC.1.1/S
W-Upgrade
The TSF shall provide the capability to consistently interpret
SW upgrade patch data and update credentials when shared
between the TSF and another trusted IT product.
FPT_TDC.1.2/S
W-Upgrade
The TSF shall use the credentials which belong to software
component and particular VU when interpreting the TSF data
from another trusted IT product.
8.1.8.5 FPT_TST TSF self test
FPT_TST.1 TSF testing {RLB_202}
Hierarchical to: -
Dependencies: -
FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up,
periodically during normal operation to demonstrate the
integrity of security data and the integrity of stored
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 64 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
executable code (if not in ROM) the correct operation of
[selection: [assignment: parts of TSF], the TSF].
FPT_TST.1.2 The TSF shall provide authorised users with the capability to
verify the integrity of security data.
FPT_TST.1.3 The TSF shall provide authorised users with the capability to
verify the integrity of stored TSF executable code.
8.1.9 Class FRU Resource Utilisation
8.1.9.1 FRU_PRS Priority of service
FRU_PRS.1 Limited priority of service {RLB_212}
Hierarchical to: -
Dependencies: -
FRU_PRS.1.1 The TSF shall assign a priority to each subject in the TSF.
FRU_PRS.1.2 The TSF shall ensure that each access to functions and data
covered by the current set of SFRs shall be mediated on the
basis of the subjects’ assigned priority.
8.1.10 Class FMT Security Management
8.1.10.1 FMT_MSA Management of security attributes
FMT_MSA.1 Management of security attributes {UIA_208}
Hierarchical to: -
Dependencies: [FDP_ACC.1 or FDP_IFC.1]: is fulfilled by FDP_ACC.1/FUN
FMT_SMR.1: is fulfilled by FMT_SMR.1//TC
FMT_SMF.1: is fulfilled by FMT_SMF.1/PP
FMT_MSA.1.1 The TSF shall enforce the SFP FUNCTION to restrict the
ability to change_default the security attributes User Group,
User ID34
to nobody.
FMT_MSA.3/FUN Static attribute initialisation
Hierarchical to: -
Dependencies: FMT_MSA.1: is fulfilled by FMT_MSA.1
FMT_SMR.1: is fulfilled by FMT_SMR.1//TC
FMT_MSA.3.1/F
UN
The TSF shall enforce the SFP FUNCTION to provide
restrictive default values for security attributes that are used
to enforce the SFP.
FMT_MSA.3.2/F The TSF shall allow nobody to specify alternative initial
34
see definition of the role ‘User’ in Table 3 above.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 65 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
UN values to override the default values when an object or
information is created.
FMT_MSA.3/FIL Static attribute initialisation
Hierarchical to: -
Dependencies: FMT_MSA.1: is fulfilled by FMT_MSA.1
FMT_SMR.1: is fulfilled by FMT_SMR.1//TC
FMT_MSA.3.1/FI
L
The TSF shall enforce the File_Structure SFP to provide
restrictive default values for security attributes that are used
to enforce the SFP.
FMT_MSA.3.2/FI
L
The TSF shall allow nobody to specify alternative initial
values to override the default values when an object or
information is created.
FMT_MSA.3/DAT Static attribute initialisation
Hierarchical to: -
Dependencies: FMT_MSA.1: is fulfilled by FMT_MSA.1
FMT_SMR.1: is fulfilled by FMT_SMR.1//TC
FMT_MSA.3.1/D
AT
The TSF shall enforce the SFP DATA to provide restrictive
default values for security attributes that are used to enforce
the SFP.
FMT_MSA.3.2/D
AT
The TSF shall allow nobody to specify alternative initial
values to override the default values when an object or
information is created.
FMT_MSA.3/UDE Static attribute initialisation
Hierarchical to: -
Dependencies: FMT_MSA.1: is fulfilled by FMT_MSA.1
FMT_SMR.1: is fulfilled by FMT_SMR.1//TC
FMT_MSA.3.1/U
DE
The TSF shall enforce the SFP User Data Export to provide
restrictive default values for security attributes that are used
to enforce the SFP.
FMT_MSA.3.2/U
DE
The TSF shall allow nobody to specify alternative initial
values to override the default values when an object or
information is created.
FMT_MSA.3/IS Static attribute initialisation
Hierarchical to: -
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 66 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Dependencies: FMT_MSA.1: is fulfilled by FMT_MSA.1
FMT_SMR.1: is fulfilled by FMT_SMR.1//TC
FMT_MSA.3.1/I
S
The TSF shall enforce the SFP Input_Sources to provide
restrictive default values for security attributes that are used
to enforce the SFP.
FMT_MSA.3.2/I
S
The TSF shall allow nobody to specify alternative initial
values to override the default values when an object or
information is created.
8.1.10.2 FMT_MOF Management of functions in TSF
FMT_MOF.1 Management of security functions behaviour {RLB_201}
Hierarchical to: -
Dependencies: FMT_SMR.1: is fulfilled by FMT_SMR.1//TC
FMT_SMF.1: is fulfilled by FMT_SMF.1/PP
FMT_MOF.1.1 The TSF shall restrict the ability to enable the functions
specified in {RLB_201} to nobody.
8.1.10.3 FMT_SMF Specification of Management Functions
FMT_SMF.1/PP Specification of Management Functions {UIA_208}
Hierarchical to: -
Dependencies: -
FMT_SMF.1.1/P
P
The TSF shall be capable of performing the following
management functions: all operations being allowed only in
the calibration mode as specified in REQ010.
FMT_SMF.1/SW-Upgrade Specification of Management Functions
Hierarchical to: -
Dependencies: -
FMT_SMF.1.1/S
W-Upgrade
The TSF shall be capable of performing the following
management functions: update of updateable software
components if the rights and conditions are fulfilled as
specified in FDP_ACC.1/SW-Upgrade and FDP_ACF.1/SW-
Upgrade.
8.1.10.4 FMT_SMR Security management roles
FMT_SMR.1//TC Security roles {UIA_208}
Hierarchical to: -
Dependencies: FIA_UID.1: is fulfilled by FIA_UID.2/TC
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 67 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
FMT_SMR.1.1//
TC
The TSF shall maintain the roles as defined in {UIA_208} as
User Groups:
- DRIVER (driver card),
- CONTROLLER (control card),
- WORKSHOP (workshop card),
- COMPANY (company card),
- UNKNOWN (no card inserted),
- Motion Sensor,
- Unknown equipment.
FMT_SMR.1.2//
TC
The TSF shall be able to associate users with roles.
8.2 Security Assurance Requirements
The security assurance requirements are as derived in BSI-CC-PP-0057 (see [PPT]
section 6.2).
The European Regulation [EU] requires for a vehicle unit the assurance level ITSEC E3, high as specified
in [GST], chap. 6 and 7.
JIL [JIL] defines an assurance package called E3hAP declaring assurance equivalence between the assur-
ance level E3 of an ITSEC certification and the assurance level of the package E3hAP within a Common
Criteria (ver. 2.1) certification (in conjunction with the Digital Tachograph System).
The current official CCMB version of Common Criteria is Version 3.1, Revision 3. This version defines
in its part 3 assurance requirements components partially differing from the respective requirements of
CC v2.x.
The CC community acts on the presumption that the assurance components of CCv3.1 and CCv2.x are
equivalent to each other.
Due to this fact, the ST includes the appropriate assurance package E3hCC31_AP
compiled and defined in the PP [PPT] as shown below (validity of this proposal is
confined to the Digital Tachograph System):
Assurance Classes Assurance
Family
E3hCC31_AP
(based on EAL4)
ADV_ARC 1
ADV_FSP 4
ADV_IMP 1
ADV_INT -
ADV_TDS 3
Development
ADV_SPM -
AGD_OPE 1
Guidance Documents
AGD_PRE 1
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 68 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Assurance Classes Assurance
Family
E3hCC31_AP
(based on EAL4)
ALC_CMC 4
ALC_CMS 4
ALC_DVS 1
ALC_TAT 1
ALC_DEL 1
ALC_FLR -
Life Cycle Support
ALC_LCD 1
Security Target evaluation
ASE
standard approach for
EAL4
ATE_COV 2
ATE_DPT 2
ATE_FUN 1
Tests
ATE_IND 2
AVA Vulnerability
Assessment
AVA_VAN 5
The assurance package E3hCC31_AP represents the standard assurance package EAL4 augmented by the
assurance components ATE_DPT.2 and AVA_VAN.5.
The requirement {RLB_215} is covered by ADV_ARC (security domain separation); the requirement
{RLB_204} is partially covered by ADV_ARC (self-protection).
8.3 Security Requirements Rationale
8.3.1 Security Functional Requirements Rationale
The SFR rationale is taken from BSI-CC-PP-0057 ([PPT] sections 6.3.1, 6.3.2 and
6.3.4) and enhanced by necessary rationale for SW upgrade and remote download.
O.Access
O.Accountability
O.Audit
O.Authentication
O.Integrity
O.Output
O.Processing
O.Reliability
O.Secured_Data_Excha
nge
O.Software_Analysis
O.Software_Upgrade
FAU_GEN.1 Audit data generation x x
FAU_SAR.1 Audit review x x
FAU_STG.1 Protected audit trail storage x x x
FAU_STG.4 Prevention of audit data loss x x
FCO_NRO.1 Selective proof of origin x x
FCS_CKM.1 Cryptographic key generation x
FCS_CKM.2 Cryptographic key distribution x
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 69 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
O.Access
O.Accountability
O.Audit
O.Authentication
O.Integrity
O.Output
O.Processing
O.Reliability
O.Secured_Data_Excha
nge
O.Software_Analysis
O.Software_Upgrade
FCS_CKM.3 Cryptographic key access x
FCS_CKM.4 Cryptographic key destruction x
FCS_COP.1/TDES Cryptographic operation x
FCS_COP.1/AES Cryptographic operation x
FCS_COP.1/RSA Cryptographic operation x
FDP_ACC.1/FIL Subset access control x
FDP_ACC.1/FUN Subset access control x x x x x
FDP_ACC.1/DAT Subset access control x
FDP_ACC.1/UDE Subset access control x
FDP_ACC.1/IS Subset access control x x x
FDP_ACC.1/SW-
Upgrade
Subset access control x x x
FDP_ACF.1/FIL Security attribute based access
control
x
FDP_ACF.1/FUN Security attribute based access
control
x x x x x
FDP_ACF.1/DAT Security attribute based access
control
x
FDP_ACF.1/UDE Security attribute based access
control
x
FDP_ACF.1/IS Security attribute based access
control
x x x
FDP_ACF.1/SW-
Upgrade
Security attribute based access
control
x x x
FDP_ETC.2 Export of user data with
security attributes
x x x x
FDP_ITC.1 Import of user data without
security attributes
x x
FDP_ITC.2/IS Import of user data with security
attributes
x x x
FDP_ITC.2/SW-
Upgrade
Import of user data with security
attributes
x x
FDP_RIP.1 Subset residual information
protection
x x x
FDP_SDI.2 Stored data integrity monitoring
and action
x x x x
FIA_AFL.1/MS Authentication failure handling x x x
FIA_AFL.1/TC Authentication failure handling x x x
FIA_AFL.1/Remote Authentication failure handling x x x
FIA_ATD.1//TC User attribute definition x x
FIA_UAU.1/TC Timing of authentication x x
FIA_UAU.1/PIN Timing of authentication x
FIA_UAU.2//MS User authentication before any
action
x x
FIA_UAU.3/MS Unforgeable authentication x
FIA_UAU.3/TC Unforgeable authentication x
FIA_UAU.5//TC Multiple authentication mechanisms x x x
FIA_UAU.6/MS Re-authenticating x x
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 70 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
O.Access
O.Accountability
O.Audit
O.Authentication
O.Integrity
O.Output
O.Processing
O.Reliability
O.Secured_Data_Excha
nge
O.Software_Analysis
O.Software_Upgrade
FIA_UAU.6/TC Re-authenticating x x
FIA_UID.2/MS User identification before any
action
x x x x x
FIA_UID.2/TC User identification before any
action
x x x x x
FMT_MSA.1 Management of security attributes x x
FMT_MSA.3/FUN Static attribute initialisation x x x x x
FMT_MSA.3/FIL Static attribute initialisation x
FMT_MSA.3/DAT Static attribute initialisation x
FMT_MSA.3/IS Static attribute initialisation x x x
FMT_MSA.3/UDE Static attribute initialisation x
FMT_MOF.1 Management of security functions x x
FMT_SMF.1/PP Specification of Management
Functions
x x
FMT_SMF.1/SW-
Upgrade
Specification of Management
Functions
x
FMT_SMR.1//TC Security roles x x
FPR_UNO.1 Unobservability x x x x x
FPT_FLS.1 Failure with preservation of secure
state.
x x
FPT_PHP.2//Power
_Deviation
Notification of physical attack x
FPT_PHP.3 Resistance to physical attack x x x x
FPT_STM.1 Reliable time stamps x x x x
FPT_TDC.1/IS Inter-TSF basic TSF data
consistency
x x
FPT_TDC.1/SW-
Upgrade
Inter-TSF basic TSF data
consistency
x x
FPT_TST.1 TSF testing x x
FRU_PRS.1 Limited priority of service x
Table 7: Coverage of Security Objectives for the TOE by SFR
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 71 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
A detailed justification required for suitability of most of the aforementioned security
functional requirements to achieve the security objectives is given in [PPT] section 6.3.1
in the table “Suitability of the SFRs”. The following table argues for the suitability of all
SFRs and particularly marks those which are not already covered by the table
“Suitability of the SFRs” in [PPT] section 6.3.1.
security
objectives
Security functional requirement
O.Access FDP_ACC.1/FIL File structure SFP on application and data
files structure
FDP_ACC.1/FUN SFP FUNCTION on the functions of the
TOE
FDP_ACC.1/DAT SFP DATA on user data of the TOE
FDP_ACC.1/UDE SFP User_Data_Export for the export of
user data
FDP_ACC.1/IS SFP Input Sources to ensure the right input
sources
FDP_ACC.1/SW-
Upgrade
Ensure the rights for software updates
FDP_ACF.1/FIL Entire files structure of the TOE-application
FDP_ACF.1/FUN Defines security attributes for SFP
FUNCTION according to the modes of
operation
FDP_ACF.1/DAT Defines security attributes for SFP DATA on
user
FDP_ACF.1/UDE Defines security attributes for SFP
User_Data_Export
FDP_ACF.1/IS Defines security attributes for SFP Input
Sources.
FDP_ACF.1/SW-
Upgrade
Ensure the conditions for software updates
FDP_RIP.1 Any previous information content of a
resource is made unavailable upon
allocation or deallocation of resource
FIA_UAU.5//TC Multiple authentication mechanisms
according to CSM_20 in [CSM] to support
user authentication.
FIA_UID.2/MS A motion sensor is successfully identified
before allowing any other action
FIA_UID.2/TC A tachograph card is successfully identified
before allowing any other action
FMT_MSA.1 Provides the SFP FUNCTION to restrict the
ability to change_default the security
attributes User Group, User ID to nobody.
FMT_MSA.3/FUN Provides the SFP FUNCTION to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 72 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
security
objectives
Security functional requirement
initial values to override the default values
when an object or information is created.
FMT_MSA.3/FIL Provides the File_Structure SFP to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
FMT_MSA.3/DAT Provides the SFP DATA to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
FMT_MSA.3/IS Provides the SFP Input_Sources to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
FMT_MSA.3/UDE Provides the SFP User Data Export to
provide restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
FMT_MOF.1 Restricts the ability to enable the test
functions as specified in {RLB_201} to no-
body and, thus, prevents an unintended
access to data in the operational phase.
FMT_SMF.1/PP Performing all operations being allowed
only in the calibration mode.
FMT_SMR.1//TC Maintain the roles as defined in {UIA_208}
as User Groups.
O.Accountability FAU_GEN.1 Generates correct audit records
FAU_SAR.1 Allows users to read accountability audit
records
FAU_STG.1 Protect the stored audit records from
unauthorised deletion
FAU_STG.4 Prevent loss of audit data loss (overwrite
the oldest stored audit records and behave
according to REQ 105b if the audit trail is
full.)
FDP_ETC.2 Provides export of user data with security
attributes using the SFP User_Data_Export
FIA_UID.2/MS A motion sensor is successfully identified
before allowing any other action
FIA_UID.2/TC A tachograph card is successfully identified
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 73 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
security
objectives
Security functional requirement
before allowing any other action
FPT_STM.1 Provides accurate time
O.Audit FAU_GEN.1 Generates correct audit records
FAU_SAR.1 Allows users to read accountability audit
records
FAU_STG.1 Protect the stored audit records from
unauthorised deletion.
FAU_STG.4 Prevent loss of audit data loss (overwrite
the oldest stored audit records and behave
according to REQ 105b if the audit trail is
full.)
FDP_SDI.2 monitors user data stored for integrity error
FIA_AFL.1/MS Detects and records authentication failure
events for the motion sensor
FIA_AFL.1/TC Detects and records authentication failure
events for the tachograph cards
FIA_AFL.1/Remote Authentication failure handling, additionally
to normal failure handling the remote station
is warned about having 5 unsuccessful
authentication attempts
FIA_ATD.1//TC Defines user attributes for tachograph cards
FIA_UID.2/MS A motion sensor is successfully identified
before allowing any other action
FIA_UID.2/TC A tachograph card is successfully identified
before allowing any other action
FPT_FLS.1 Preserves a secure state when the following
types of failures occur: as specified in
{RLB_203, RLB_210, RLB_211}
FPT_STM.1 Provides accurate time
FPT_TST.1 Detects integrity failure events for security
data and stored executable code
O.Authentication FIA_AFL.1/MS Detects and records authentication failure
events for the motion sensor
FIA_AFL.1/TC Detects and records authentication failure
events for the tachograph cards
FIA_AFL.1/Remote Authentication failure handling, additionally
to normal failure handling the remote station
is warned about having 5 unsuccessful
authentication attempts
FIA_UAU.1/TC Allows TC identification before
authentication
FIA_UAU.1/PIN Allows TC (Workshop Card) identification
before authentication
FIA_UAU.2//MS Motion sensor has to be successfully
authenticated before allowing any action
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 74 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
security
objectives
Security functional requirement
FIA_UAU.3/MS Provides unforgeable authentication for the
motion sensor
FIA_UAU.3/TC Provides unforgeable authentication for the
tachograph cards
FIA_UAU.5//TC Multiple authentication mechanisms
according to CSM_20 in [CSM] to support
user authentication.
FIA_UAU.6/MS Periodically re-authenticate the motion
sensor
FIA_UAU.6/TC Periodically re-authenticate the tachograph
cards
FIA_UID.2/MS A motion sensor is successfully identified
before allowing any other action
FIA_UID.2/TC A tachograph card is successfully identified
before allowing any other action
O.Integrity FAU_STG.1 Protect the stored audit records from
unauthorised deletion
FDP_ETC.2 Provides export of user data with security
attributes using the SFP User_Data_Export
FDP_SDI.2 monitors user data stored for integrity error
O.Output FCO_NRO.1 Generates an evidence of origin for the data
to be downloaded to external media.
FDP_ETC.2 Provides export of user data with security
attributes using the SFP User_Data_Export
FDP_SDI.2 monitors user data stored for integrity error
FPR_UNO.1 Ensures unobservability of secrets
FPT_PHP.3 Ensures resistance to physical attack to the
TOE software in the field after the TOE
activation
O.Processing FDP_ACC.1/FUN Defines security attributes for SFP
FUNCTION according to the modes of
operation
FDP_ACC.1/IS SFP Input Sources to ensure the right input
sources
FDP_ACF.1/FUN Defines security attributes for SFP
FUNCTION according to the modes of
operation
FDP_ACF.1/IS Defines security attributes for SFP
User_Data_Export
FDP_ITC.1 Provides import of user data from outside of
the TOE using the SFP Input Sources
FDP_ITC.2/IS Provides import of user data from outside of
the TOE, using the security attributes
associated with the imported user data for
the Motion Sensor and for the Tachograph
Cards
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 75 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
security
objectives
Security functional requirement
FDP_RIP.1 Any previous information content of a
resource is made unavailable upon
allocation or deallocation of resource
FMT_MSA.3/FUN Provides the SFP FUNCTION to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
FMT_MSA.3/IS Provides the SFP Input_Sources to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
FPR_UNO.1 Ensures unobservability of secrets
FPT_PHP.3 Ensures Resistance to physical attack to
the TOE software in the field after the TOE
activation
FPT_STM.1 Provides accurate time
FPT_TDC.1/IS Provides the capability to consistently
interpret secure messaging attributes as
defined by [ISO16844] for the Motion
Sensor and by [CSM] for the Tachograph
Cards.
O.Reliability FDP_ACC.1/FUN Defines security attributes for SFP
FUNCTION according to the modes of
operation
FDP_ACC.1/IS SFP Input Sources to ensure the right input
sources
FDP_ACC.1/SW-
Upgrade
Ensure the rights for software updates
FDP_ACF.1/FUN Defines security attributes for SFP
FUNCTION according to the modes of
operation
FDP_ACF.1/IS Defines security attributes for SFP
User_Data_Export
FDP_ACF.1/SW-
Upgrade
Ensure the conditions for software updates
FDP_ITC.1 Provides import of user data from outside of
the TOE using the SFP Input Sources
FDP_ITC.2/IS Provides import of user data from outside of
the TOE, using the security attributes
associated with the imported user data for
the Motion Sensor and for the Tachograph
Cards
FDP_ITC.2/SW-Upgrade Provides import of SW upgrade data from
outside of the TOE, using the defined
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 76 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
security
objectives
Security functional requirement
conditions for the update acceptance
FDP_RIP.1 Any previous information content of a
resource is made unavailable upon
allocation or deallocation of resource
FDP_SDI.2 monitors user data stored for integrity error
FIA_AFL.1/MS Detects and records authentication failure
events for the motion sensor
FIA_AFL.1/TC Detects and records authentication failure
events for the tachograph cards
FIA_AFL.1/Remote Authentication failure handling, additionally
to normal failure handling the remote station
is warned about having 5 unsuccessful
authentication attempts.
FMT_MOF.1 Restricts the ability to enable the test
functions as specified in {RLB_201} to
nobody and, thus, increases TOE reliability
in the operational phase.
FMT_MSA.3/FUN Provides the SFP FUNCTION to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
FMT_MSA.3/IS Provides the SFP Input_Sources to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
FPR_UNO.1 Ensures unobservability of secrets
FPT_FLS.1 Preserves a secure state when the following
types of failures occur: as specified in
{RLB_203, RLB_210, RLB_211}
FPT_PHP.2//Power_Devi
ation
Detection of physical tampering
(Power_Deviation) and generation of an
audit record
FPT_PHP.3 Ensures Resistance to physical attack to
the TOE software in the field after the TOE
activation
FPT_STM.1 Provides accurate time
FPT_TDC.1/IS Provides the capability to consistently
interpret secure messaging attributes as
defined by [ISO16844] for the Motion
Sensor and by [CSM] for the Tachograph
Cards.
FPT_TDC.1/SW-Upgrade Provides the capability to consistently
interpret the patch data and the
corresponding credentials.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 77 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
security
objectives
Security functional requirement
FPT_TST.1 Detects integrity failure events for security
data and stored executable code
FRU_PRS.1 Ensures that resources will be available
when needed
O.Secured_Data_E
xchange
FCO_NRO.1 Generates an evidence of origin for the data
to be downloaded to external media.
FCS_CKM.1 Generates of session keys for the motion
sensor and the tachograph cards
FCS_CKM.2 Controls distribution of cryptographic keys
in accordance with a specified
cryptographic key distribution method as
specified in the table below that meets the
following list of standards.
FCS_CKM.3 Controls cryptographic key access and
storage in the TOE
FCS_CKM.4 Destroys cryptographic keys in the TOE
FCS_COP.1/TDES Provides the cryptographic operation TDES
FCS_COP.1/RSA Provides the cryptographic operation RSA
FDP_ACC.1/FUN Defines security attributes for SFP
FUNCTION according to the modes of
operation
FDP_ACF.1/FUN Defines security attributes for SFP
FUNCTION according to the modes of
operation
FDP_ETC.2 Provides export of user data with security
attributes using the SFP User_Data_Export
FDP_ITC.2/IS Provides import of user data from outside of
the TOE, using the security attributes
associated with the imported user data for
the Motion Sensor and for the Tachograph
Cards
FIA_ATD.1//TC Defines user attributes for tachograph cards
FIA_UAU.1/TC Allows TC identification before
authentication
FIA_UAU.2//MS Motion sensor has to be successfully
authenticated before allowing any action
FIA_UAU.5//TC Multiple authentication mechanisms
according to CSM_20 in [CSM] to support
user authentication.
FIA_UAU.6/MS Periodically re-authenticate the motion
sensor
FIA_UAU.6/TC Periodically re-authenticate the tachograph
cards
FIA_UID.2/MS A motion sensor is successfully identified
before allowing any other action
FIA_UID.2/TC A tachograph card is successfully identified
before allowing any other action
FMT_MSA.1 Provides the SFP FUNCTION to restrict the
ability to change_default the security
attributes User Group, User ID to nobody
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 78 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
security
objectives
Security functional requirement
FMT_MSA.3/FUN Provides the SFP FUNCTION to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
FMT_SMF.1/PP Performing all operations being allowed
only in the calibration mode
FMT_SMR.1//TC Maintain the roles as defined in {UIA_208}
as User Groups
O.Software_Analysi
s
FPT_PHP.3 Ensures resistance to physical attack to the
TOE software in the field after the TOE
activation
FPR_UNO.1 Ensures unobservability of secrets
FDP_ACC.1/FUN Defines security attributes for SFP
FUNCTION according to the modes of
operation
FDP_ACF.1/FUN Defines security attributes for SFP
FUNCTION according to the modes of
operation
FMT_MSA.3/FUN Provides the SFP FUNCTION to provide
restrictive default values for security
attributes that are used to enforce the SFP
and allows nobody to specify alternative
initial values to override the default values
when an object or information is created.
O.Software_Upgrad
e
FDP_ACC.1/SW-
Upgrade
Ensure the rights for software updates
FDP_ACF.1/SW-
Upgrade
Ensure the conditions for software updates
FDP_ITC.2/SW-Upgrade Provides import of SW upgrade data
inclusive the corresponding credentials from
outside of the TOE.
FPT_TDC.1/SW-Upgrade Provides the capability to consistently
interpret the patch data and the
corresponding credentials.
FCS_COP.1/AES Provides the cryptographic operation AES
decryption and CMAC.
FMT_SMF.1/SW-
Upgrade
Performs the update if the rights and
conditions allow it.
Table 8: Suitability of the SFRs
8.3.2 Rationale for SFR’s Dependencies
The dependency analysis for the security functional requirements shows that the basis
for mutual support and internal consistency between all defined functional requirements
is satisfied. All dependencies between the chosen functional components are analysed,
and non-dissolved dependencies are appropriately explained.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 79 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
The dependency analysis has directly been made within the description of each SFR in
sec. 8.1 above. All dependencies being expected by [CC2] are either fulfilled or their
non-fulfilment is justified.
8.3.3 Security Assurance Requirements Rationale
The security assurance requirements rationale is as derived in the protection profile
BSI-CC-PP-0057 ([PPT] sections 6.3.3 and 6.3.4)
The current protection profile/ST is claimed to be conformant with the assurance package E3hCC31_AP
(cf. sec. 4.3 above). As already noticed there in sec.8.2, the assurance package E3hCC31_AP represents
the standard assurance package EAL4 augmented by the assurance components ATE_DPT.2 and
AVA_VAN.5.
The main reason for choosing made is the legislative framework [JIL], where the assurance level required
is defined in form of the assurance package E3hAP (for CCv2.1). The PP author translated this assurance
package E3hAP into the assurance package E3hCC31_AP. These packages are commensurate with each
other.
The current assurance package was chosen based on the pre-defined assurance package EAL4. This
package permits a developer to gain maximum assurance from positive security engineering based on
good commercial development practices which, though rigorous, do not require substantial specialist
knowledge, skills, and other resources. EAL4 is the highest level, at which it is likely to retrofit to an
existing product line in an economically feasible way. EAL4 is applicable in those circumstances where
developers or users require a moderate to high level of independently assured security in conventional
commodity TOEs and are prepared to incur additional security specific engineering costs.
The selection of the component ATE_DPT.2 provides a higher assurance than the pre-defined EAL4
package due to requiring the functional testing of SFR-enforcing modules.
The selection of the component AVA_VAN.5 provides a higher assurance than the pre-defined EAL4
package, namely requiring a vulnerability analysis to assess the resistance to penetration attacks
performed by an attacker possessing a high attack potential. This decision represents a part of the
conscious security policy for the recording equipment required by the legislative [EU] and reflected by
the current PP and ST.
The set of assurance requirements being part of EAL4 fulfils all dependencies a priori.
The augmentation of EAL4 chosen comprises the following assurance components:
– ATE_DPT.2 and
– AVA_VAN.5.
For these additional assurance component, all dependencies are met or exceeded in the EAL4 assurance
package:
Component Dependencies required
by CC Part 3 or ASE_ECD
Dependency fulfilled by
TOE security assurance requirements (only additional to EAL4)
ADV_ARC.1 ADV_ARC.1
ADV_TDS.3 ADV_TDS.3
ATE_DPT.2
ATE_FUN.1 ATE_FUN.1
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 80 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Component Dependencies required
by CC Part 3 or ASE_ECD
Dependency fulfilled by
ADV_ARC.1 ADV_ARC.1
ADV_FSP.4 ADV_FSP.4
ADV_TDS.3 ADV_TDS.3
ADV_IMP.1 ADV_IMP.1
AGD_OPE.1 AGD_OPE.1
AGD_PRE.1 AGD_PRE.1
AVA_VAN.5
ATE_DPT.1 ATE_DPT.2
Table 9: SAR Dependencies
8.3.4 Security Requirements – Internal Consistency
The argumentation in [PPT] section 6.3.4 applies, in particular:
The following part of the security requirements rationale shows that the set of security
requirements for the TOE consisting of the security functional requirements (SFRs) and
the security assurance requirements (SARs) together form an internally consistent
whole.
8.3.4.1 SFRs
The dependency analysis in section 8.3.1 Rationale for SFR’s Dependencies for the
security functional requirements shows that the basis for internal consistency between
all defined functional requirements is satisfied. All dependencies between the chosen
functional components are analysed and non-satisfied dependencies are appropriately
explained.
All subjects and objects addressed by more than one SFR in section 8.1 are also
treated in a consistent way: the SFRs impacting them do not require any contradictory
property and behaviour of these ‘shared’ items. The current ST accurately and
completely reflects the Generic Security Target [GST] and Protection Profile [PPT].
Since the GST [GST] is part of the related legislation, it is assumed to be internally
consistent.
Therefore, due to conformity between the current PP and [GST] (see [PPT] section
6.3.4) and the conformity between [PPT] and this ST, also subjects and objects being
used in the current ST are used in a consistent way.
8.3.4.2 SARs
The assurance package EAL4 is a pre-defined set of internally consistent assurance
requirements. The dependency analysis for the sensitive assurance components in
section 8.3.3 “Security Assurance Requirements Rationale” shows that the assurance
requirements are internally consistent, because all (additional) dependencies are
satisfied and no inconsistency appears.
Inconsistency between functional and assurance requirements could only arise, if there
are functional-assurance dependencies being not met – an opportunity having been
shown not to arise in sections 8.3.2 “Rationale for SFR’s Dependencies” and 8.3.3
“Security Assurance Requirements Rationale”. Furthermore, as also discussed in
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 81 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
section 8.3.3 “Security Assurance Requirements Rationale”, the chosen assurance
components are adequate for the functionality of the TOE. So, there are no
inconsistencies between the goals of these two groups of security requirements.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 82 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
9 TOE Summary Specification
In addition to the requirements of CC [CC1], the current ST defines not only the TOE
Security Functionality (TSF) but also Security Functions (SF.xxx) whose combination
constitutes the TOE Security Functionality.
9.1 TOE Security Functions
For the definition of the Security Functions (SF_xxx) related to the SC, it is referred to
the Security Target [SCST], chapter 7. Security Functions of the SC are relevant for the
EFAS-4.0. The following sections provide a survey of the Security Functions of the TOE
under consideration of the requirements in the protection profile [PPT] including all
extensions and operations made in chapter 8.1.
9.1.1 SF.ACS Security Attribute Based Access Control
SF.ACS controls the access to the data and functions and enforces the File_Structure
SFP, SFP FUNCTION, SFP DATA, SFP User_Data_Export, SFP Input_Sources, SFP
SW-Upgrade (see 8.1.5.1) as required by FDP_ACC.1/*, FDP_ACF.1/* and FDP_ITC.1,
FDP_ITC.2/IS and FMT_MSA.3/FUN, FMT_MSA.3/FIL, FMT_MSA.3/DAT,
FMT_MSA.3/IS, FMT_MSA.3/UDE.
SF.ACS implements the File_Structure SFP for tachograph application and data files
structure as required by ACC_211 (FDP_ACC.1/FIL, FDP_ACF.1/FIL) and enforces the
SFP FUNCTION, SFP DATA, SFP User_Data_Export on subjects, objects, and
operations as required in 4 of [GST] and described in 8.1.5 (FDP_ACC.1/DAT,
FDP_ACF.1/DAT, FDP_ACC.1/UDE, FDP_ACF.1/UDE) .
In particular, SF.ACS ensures that access to resources is obtained when required and
that resources are neither requested nor retained unnecessarily as required by
FRU_PRS.1, furthermore, it preserves the audit trail as required by FAU_STG.1 and
protects keys as required by FPR_UNO.1. SF.ACS ensures that cards cannot be
released before relevant data have been stored to them:
• The recording equipment is designed such that the tachograph cards are locked
in position on their proper insertion into the card interface devices.
• The release of tachograph cards may function only when the vehicle is stopped
and after the relevant data have been stored on the cards. The release of the card
shall require positive action by the user.
SF.ACS ensures that user data related to requirements 081, 084, 087, 090, 093, 102,
104, 105, 105a and 109 ([EU], Annex 1B) may only be processed from the right input
sources:
• vehicle motion data, as required by FPT_TDC.1/IS
• VU's real time clock, as required in FPT_STM.1
• recording equipment calibration parameters, as required in FDP_ITC.1
• tachograph cards, as required by FPT_TDC.1/IS, supported by
• users’ inputs
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 83 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
in accordance with the requirements FDP_ACC.1/IS, FDP_ACF.1/IS, FPT_STM.1,
FDP_ITC.1,FDP_ITC.2/IS, FPT_TDC.1/IS.
SF.ACS ensures that user data (entered manually) related to requirement 109a ([EU],
Annex 1B) may only be entered for the period last card withdrawal — current insertion
(requirement 050a) in accordance with the requirements FDP_ACC.1/UDE,
FDP_ACF.1/UDE.
SF.ACS controls the access to the data and functions of the TOE and prevents the
possibility to analyse or debug TOE's software (inclusive the cryptographic keys) in the
field after the EFAS-4.0 activation (ADV_ARC, FPR_UNO.1). This includes that SF.ACS
allows the calibration functions only in calibration mode (as specified in REQ 010) in
accordance with FMT_SMF.1/PP.
Inputs from external sources are not accepted as executable code (as required in
FDP_ITC.2/IS, FDP_ACC.1/IS, FDP_ACF.1/IS). Software update of the security and
non-security relevant software components is only possible after the corresponding
authentication and verification with help of credentials as required in FDP_ACC.1/SW-
Upgrade and FDP_ACF.1/SW-Upgrade,.
SF.ACS contributes audit data through logging of events which deviate from the
admissible FDP_ACC.1 in accordance with FAU_GEN.1.
Nobody may change the public/private keys and the KMVU after their insertion during the
production process. Nobody may read the private keys and the KMVU after their
insertion during the production process in full compliance with FMT_MSA.1,
FMT_MSA.3/FUN, FMT_MSA.3/FIL, FMT_MSA.3/DAT, FMT_MSA.3/IS,
FMT_MSA.3/UDE (see 8.1.10.1).
In doing so, SF.ACS directly supports FCS_CKM.3 and FCS_COP.1/RSA.
The SF is effective only with support of the Security Functions of the SC, see 10.
9.1.2 SF.SECAUDIT Audit
SF.SECAUDIT generates an audit record inter alia of the following auditable events:
start-up and shutdown of the audit functions and all other events described below. The
audit function will be started up as soon as the TOE has external power supply after
activation and shut down, when the external power supply is interrupted. In this case
SF.SECAUDIT records within each audit record at least the information date and time of
begin and end of the event and the type of event.
SF.SECAUDIT, for events impairing the security of the EFAS-4.0, records those events
with associated data ([EU], Annex 1B (requirements 094, 096 and 109) as required in
FAU_GEN.1.
In particular, for the activities and auditable events specified in REQ 081, 084, 087, 090,
093, 094, 096, 098, 101, 102, 103, and 105a35
and UIA_206, UIA_214, AUD_202,
35
all these REQ are referred to in {ACT_201, ACT_203, ACT_204, ACT_205, AUD_201, AUD_203}
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 84 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
ACR_205, RLB_203, RLB_206, RLB_210, RLB_21436
, DEX_202, DEX_204, RLB_208,
UIA_220 the following information will be stored: date, time and type of the event,
subject identity, and the outcome (success or failure) of the event and the information
specified in REQ 081, 084, 087, 090, 093, 094, 096, 098, 101, 102, 103, 105a.
Upon detection of a data integrity error, SF.SECAUDIT generates an audit record about
it (FDP_SDI.2).
SF.SECAUDIT enforces audit records storage rules [EU], Annex 1B (requirement 094)
and (requirement 096) in a way as required in FDP_ETC.2. In particular, SF.SECAUDIT
supports the enforcing the SFP User_Data_Export and provides the capability to read
recorded information possibly secured with help of associated security attributes.
SF.SECAUDIT stores audit records generated by the motion sensor in its data memory
as required by FAU_GEN.1.
SF.SECAUDIT makes it possible to print, display and download audit records except for
the events listed in REQ 011 as required by FAU_SAR.1.
SF.SECAUDIT shall enforce the following rules for monitoring audited events known to
indicate a potential security violation:
Accumulation or combination of
• security breach attempts like
• motion sensor authentication failure,
• tachograph card authentication failure,
• unauthorized change of motion sensor,
• card data input integrity error,
• stored user data integrity error,
• internal data transfer error,
• unauthorised case opening,
• hardware manipulation,
• last card session not correctly closed,
• motion data error event,
• power supply interruption event,
• EFAS-4.0 internal fault.
in a way which covers FAU_GEN.1.
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 for security.
36
Last card session not correctly closed
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 85 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
SF.SECAUDIT is also able to provide reliable time stamps based on the RTC time
information (as required in FPT_STM.1) for its own use.
SF.SECAUDIT overwrites the oldest stored audit records and behaves according to
[EU] requirements 083, 086, 089, 092 and 105b, if the audit trail is full as required in
FAU_STG.4.
The SF is effective only with support of the Security Functions of the SC, see 10.
9.1.3 SF.EX_CONF Confidentiality of Data Exchange
SF.EX_CONF protects the confidentiality of secret data being exchanged between the
TOE and the external subjects
• tachograph card
• motion sensor
• external device and
• Security Server
For this purpose, encryption based on symmetric Triple DES cryptography is used.
The data transfer between the EFAS-4.0 and
• tachograph cards is secured according to ISO/IEC 7816-4 (see [ISO7816]) to the
extent as defined in [GST] CSM_021 - TDES in CBC mode with key length 112
bits as required in FCS_COP.1/TDES
• the motion sensor is secured according to ISO/DIS 16844-3 (see [ISO16844]) -
TDES in ECB mode with key length 112 bits as required in FCS_COP.1/TDES
The communication with the remote external device is secured with TDES-
cryptographic mechanisms with calculation of a session key based on secrets stored in
the SC and external device and dynamic data portions provided by both components at
connection time (mutual authentication mechanism) - TDES in CBC mode with key
length 112 bits as required in FCS_COP.1/TDES
The SW-upgrade data inclusive credentials are secured with AES-cryptographic
mechanisms based on VU-specific keys according to the BSI recommendations in [TR-
02102] - AES in CBC mode with key length 128 bits as required in FCS_COP.1/AES
and FDP_ITC.2/SW-Upgrade. The software update patch contains two files. The
firmware image file is encrypted by the Security Server with AES keys KFirmware-SC and
KFirmware-MC. The credentials file is encrypted with the unique keys of the associated
VUs (KENCUpdateVu).
The cryptographic keys used for securing the data transfer as session keys are
generated during the preceding mutual authentication process between the EFAS-4.0
and the external subject (see SF.IA_KEY and SF.GEN_SKEYS).
The SF is effective only with support of the Security Functions of the SC, see 10.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 86 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
9.1.4 SF.EX_INT Integrity and Authenticity of Data Exchange
SF.EX_INT protects the authenticity and integrity of data being exchanged between the
TOE and the external subjects
• tachograph card,
• motion sensor,
• Security Server,
• external device and
• downloading equipment
The data transfer between the EFAS-4.0 and
• tachograph cards is secured according to ISO/IEC 7816-4 (see [ISO7816]) to
the extent as defined in [GST] CSM_021 – Retail-MAC as required in
FCS_COP.1/TDES. SF.EX_INT verifies the integrity and authenticity of data
imported from tachograph cards. Upon detection of card data integrity or
authenticity error, SF.EX_INT generates an audit record compliant with
FAU_GEN.1 and does not use the data as required in FDP_ITC.2/IS.
SF.EX_INT exports data to tachograph smart cards with associated security
attributes such that the card will be able to verify its integrity and authenticity
as required in FDP_ETC.2.
• the motion sensor is secured according to ISO/DIS 16844-3 (see
[ISO16844]) and as required in FCS_COP.1/TDES and after proper
authentication as required in FIA_UAU.2//MS, FIA_UAU.6/MS,
FIA_UID.2/MS. SF.EX_INT verifies the integrity and authenticity of motion
data imported from the motion sensor. Upon detection of a motion data
integrity or authenticity error, SF.EX_INT generates an audit record and
continues to use imported data as required in FDP_ITC.2/IS. .
• the external device is secured according to ISO/IEC 7816-4 (see [ISO7816])
to the extent as defined in [GST] CSM_021 – Retail-MAC as required in
FCS_COP.1/TDES after mutual authentication between the VU and the
external device.
• downloading equipment are secured according to PKCS#1 V2.0 and with
hash algorithm SHA-1 as required in FCS_COP.1/RSA.
(Note: The source equipment (EFAS-4.0) identification and its security
certification (Member state and equipment) are also downloaded. The verifier
of the data must possess a trusted European public key to verify the
certificate chain.)
SF.EX_INT is able to generate evidence of origin for transmitted data, to relate the VU
identity and to provide a capability to verify the evidence of origin of information as
required in FCO_NRO.1.
SF.EX_INT verifies the authenticity and integrity of received software upgrade data as
required by FDP_ITC.2/SW-Upgrade. The SW-upgrade data inclusive credentials are
secured with AES-cryptographic mechanisms based on VU-specific keys according to
the BSI recommendations in [TR-02102], - AES in CBC mode with key length 128 bits
(CMAC) as required in FCS_COP.1/AES and FDP_ITC.2/SWUpgrade. The software
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 87 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
update patch contains two files. The firmware image file is encrypted by the Security
Server (see SF.EX_CONF above) and secured additionally (AES CMAC) with an AES
key KAuth. The credentials file is encrypted (see SF.EX_CONF above) and secured
additionally (AES CMAC) with the unique key of the associated VUs (KAUTHUpdateVu).
The cryptographic keys used for securing the data transfer for tachograph cards are
session keys which are generated during the preceding mutual authentication process
between the EFAS-4.0 and the tachograph card (see SF.IA_KEY, FCS_COP.1/RSA
and SF.GEN_SKEYS).
The SF is effective only with support of the Security Functions of the SC, see 10.
9.1.5 SF.GEN_SKEYS Generation of Session Keys
SF.GEN_SKEYS generates session keys for symmetric cryptography used for
protecting the confidentiality, integrity and authenticity of data exchanged between the
TOE and the external world
• tachograph card,
• motion sensor,
• external device.
SF.GEN_SKEYS enforces that the key material meets the following requirements:
• random numbers generated by the EFAS-4.0 and used in the key
generation process have a high quality and
• symmetric keys generated by the TOE are checked by the TSF with
regard to their cryptographic strength, and only cryptographically strong
keys (with the required key length) will be accepted by the TSF.
• Calculation of a session key based on secrets stored in the TSF and in the
external device and based on dynamic data portions provided by both
components at connection time.
SF.GEN_SKEYS generates and managed session keys (TDES keys) in accordance
with the cryptographic key derivation algorithms as specified in [ISO16844] and [CSM].
as required in FCS_CKM.1, FCS_CKM.2 and FCS_CKM.4. The deletion of keys takes
place due value overwriting with “FF”.
Random numbers are generated by the random number generator of the SC.
SF.GEN_SKEYS is directly connected with SF.IA_KEY which realises the internal and
external authentication process.
SF.GEN_SKEYS destroys cryptographic keys in accordance with a specified
cryptographic key destruction method as implemented in the SC (overwriting with “FF”)
as required by FDP_RIP.1.
The SF is effective only with support of the Security Functions of the SC, see 10.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 88 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
9.1.6 SF.GEN_DIGSIG Generation of Digital Signatures optionally with
Encryption
SF.GEN_DIGSIG provides a digital signature generation functionality based on
asymmetric cryptography, particularly the RSA algorithm with a key length of 1024 bit as
required in FCS_COP.1/RSA.
The digital signature function will be used for several purposes with different signature
keys and different formats for the digital signature input:
• Explicit generation of digital signatures of data using the signature scheme with
appendix (signature generation operation) according to the standard PKCS#1
V2.0 and with hash algorithm SHA-1.
• Within authentication processes between the EFAS-4.0 and the tachograph card
for the creation of authentication tokens using the signature scheme with
message recovery (signature generation operation) according to the standard ISO
9796-2 (see [ISO9796]) and with hash algorithm SHA-1.
SF.GEN_DIGSIG is able to generate evidence of origin for transmitted data, to relate
the VU identity and to provide a capability to verify the evidence of origin of information
as required in FCO_NRO.1.
Random numbers necessary for the generation of digital signatures are generated by
the SC.
SF.GEN_DIGSIG provides the functionality to encrypt and decrypt data based on
asymmetric cryptography, particularly the RSA algorithm with a key length of 1024. The
decryption function will be used for the following purpose:
• Within the authentication process between the EFAS-4.0 and the tachograph card
for the generation of authentication tokens using the decryption primitive
according to the standard PKCS#1 V2.0.
Signatures are generated and verified in compliance with FCS_COP.1/RSA, key access
and its storage are compliant with FCS_CKM.3.
The SF is effective only with support of the Security Functions of the SC, see 10.
9.1.7 SF.VER_DIGSIG Verification of Digital Signatures optionally with
Decryption
SF.VER_DIGSIG provides a functionality to verify digital signatures based on
asymmetric cryptography, particularly the RSA algorithm with a key length of 1024 bit.
The SF to verify a digital signature will be used for several purposes with different keys
and different formats for the digital signature input:
• Explicit verification of digital signatures of data using the signature scheme with
appendix (signature verification operation) according to the standard PKCS#1
V2.0 and with hash algorithm SHA-1.
• Within authentication processes between EFAS-4.0 and tachograph card for the
verification of authentication tokens using the signature scheme with message
recovery (signature verification operation) according to the standard ISO 9796-2
(see [ISO9796]) and with hash algorithm SHA-1.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 89 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
• Within the verification and unwrapping of imported certificates using the signature
scheme with message recovery (signature verification operation) according to the
standard ISO 9796-2 (see [ISO9796]) and with hash algorithm SHA-1.
SF.VER_DIGSIG provides the functionality to encrypt data based on asymmetric
cryptography, particularly the RSA algorithm with a key of 1024 bit. The encryption
function will be used for the following purpose:
• Within the authentication processes between EFAS-4.0 and tachograph card for
the verification of authentication tokens using the decryption primitive according to
the standard PKCS#1 V2.0.
Signatures are verified in compliance with FCS_COP.1/RSA, key access to EU.PK and
its storage are compliant with FCS_CKM.3.
The SF is effective only with support of the Security Functions of the SC, see 10.
9.1.8 SF.DATA_INT Stored Data Integrity Monitoring and Action
SF.DATA_INT protects the integrity of user data (defined in [EU], Annex 1B, III.12).
User data include cryptographic keys. User data is stored
• in the data memory of the SC,
• in the data memory of the main processor.
Monitoring
SF.DATA_INT includes hardware mechanisms of the SC which protect user data
against manipulation. Such hardware mechanisms are features within the design and
construction which make reverse-engineering and tamper attacks more difficult. These
features comprise dedicated shielding techniques and different scrambling features for
the memory blocks.
SF.DATA_INT protects the user data stored in the data memory of the MC by AES
CMAC values which are calculated about the data and stored in the MC together with
the data. The CMAC-key is stored in the SC, also CMAC-verification of stored data is
done in the SC (FCS_COP.1/AES).
SF.DATA_INT protects the user data stored in the SC by checksums and/or double
storage.
The integrity of the user data is checked regularly and before data download.
SF.DATA_INT is implemented with ensuring the fulfilment of the SFRs FDP_SDI.2 and
FAU_STG.1. Upon detection of a stored user data integrity error, SF.DATA_INT
generates an audit record in accordance with FAU_GEN.1 and FAU_STG.1.
SF.DATA_INT overwrites the oldest stored audit records, if the audit trail is full.
If a cryptographic key (public or private) is corrupted, then the cryptographic key is not
used.
The SF is effective only with support of the Security Functions of the SC, see 10.
9.1.9 SF.IA_KEY Key Based User / TOE Authentication
The following subjects can be identified and authenticated with regard to the TOE by
means of a challenge response procedure using random numbers (external
authentication).
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 90 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
a) Initial motion sensor identification and authentication (pairing, calibration):
The EFAS-4.0 authenticates the motion sensor it is connected to:
• at motion sensor connection,
• at each calibration of the recording equipment,
• at power supply recovery.
Authentication is mutual and triggered by the EFAS-4.0 before allowing any other
TSF-mediated actions in accordance with FIA_UAU.2//MS (the identification as
required in FIA_UID.2/MS takes place too). I.e. the TOE itself is also authenticated
towards the motion sensor by means of a challenge-response procedure. Hereby,
SF.IA_KEY detects and prevents use of authentication data that has been forged by
or copied from any other user of the TSF (FIA_UAU.3/MS) and supports enforcing
the SFP FUNCTION and SFP Input_Sources to avoid value changes of security
attributes (FMT_MSA.1, FMT_MSA.3/FUN and FMT_MSA.3/IS).
b) User identification and authentication via tachograph card:
The EFAS-4.0 identifies and authenticates its users at card insertion before
allowing any other TSF-mediated actions in accordance with FIA_UID.2/TC,
FIA_UAU.1/TC and FIA_UAU.5//TC as well as FIA_UAU.1/PIN. The authentication
is mutual and triggered by the EFAS-4.0. I.e. the TOE itself is also authenticated
towards the tachograph card by means of a challenge-response procedure. Hereby,
SF.IA_KEY detects and prevents use of authentication data that has been forged
by or copied from any other user of the TSF (FIA_UAU.3/TC), maintains the list of
security attributes belonging to individual users as required by FIA_ATD.1//TC and
supports enforcing the SFP FUNCTION to avoid value changes of security
attributes (FMT_MSA.1). Authentication is performed by means of proving that the
card inserted is a valid tachograph card, possessing security data that only the
system could distribute. After this the EFAS-4.0 maintains the following roles
DRIVER (driver card), CONTROLLER (control card), WORKSHOP (workshop
card), COMPANY (company card) and UNKNOWN (no card inserted) as required
by FMT_SMR.1//TC.
Note: The external authentication of the EFAS-4.0 corresponds to the internal
authentication of the tachograph card and vice versa.
c) External device identification and authentication:
Before allowing any further interaction, the EFAS-4.0 shall successfully authenticate
the external device. Authentication shall be mutual. I.e. the TOE itself is also
authenticated towards the external device by means of a challenge-response
procedure.
Cryptography:
In the cases
a) SF.IA_KEY uses symmetric cryptography according to ISO/DIS 16844-3 (see
[ISO16844]), using TDES in a way as required in FCS_COP.1/TDES.
b) SF.IA_KEY uses asymmetric cryptography according to ISO 9796-2 (see
[ISO9796]) and with hash algorithm SHA-1 for digital signatures with partial
recovery, using RSA in a way as required by FCS_COP.1/RSA.
c) SF.IA_KEY makes use of symmetric cryptography for mutual authentication
between the VU and the external device as well as for data integrity during data
exchange between the EFAS-4.0 and the external device.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 91 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Cryptographic Protocol:
In the case a):
SF.IA_KEY applies the initial identification and authentication as described in
chapter 7.4 of ISO/DIS 16844-3 (see [ISO16844]).
The extended serial-number NS of the motion sensor is sent to the EFAS-4.0. The
EFAS-4.0 encrypts the extended serial number NS of the motion sensor, using the
“identification key” KID. The motion sensor transmits a pairing key KP which is encrypted
with the “master key” KM to the EFAS-4.0.
The “session key” KS is transmitted from the EFAS-4.0 to the motion sensor encrypted
with the “pairing key” KP. Pairing information is transmitted from the EFAS-4.0 to the
motion sensor encrypted with the “pairing key” in a way as required in FCS_CKM.2 and
FDP_ETC.2.
The initial identification and authentication leads to the generation of a “session key” KS
which secures a challenge response mechanism for the following communication
between the EFAS-4.0 and the motion sensor.
In the case b):
SF.IA_KEY operates as described in [EU], Appendix 11 (“Get Challenge Operation”,
“Generation of a digital signature” and “Encryption” for the internal authentication,
“Random generation of the EFAS-4.0”, “Decryption” and “Verification of a digital
signature” for the external authentication.
The private key necessary on the EFAS-4.0´s side for authentication purposes is stored
on the EFAS-4.0 and is implicitly connected with the corresponding commands. The
access to the keys is controlled by the SFP FUNCTION, which is realised by SF.ACS.
The combination of a successful internal authentication process followed by a
successful external authentication process leads to the generation of a new session key
(with sequence counter sent) which will be used to secure the following data transfer.
The generation of session keys is task of SF.GEN_SKEYS.
For the tachograph card type “Workshop Card” the mutual authentication process
described above is only possible after a successful preceding PIN based user
authentication between user and Workshop Card. Since EFAS-4.0 only transfers the
PIN from the keypad to the Workshop Card this belongs not to the TSF of EFAS-4.0.
Case c):
SF.IA_KEY uses a challenge response protocol with TDES-cryptographic mechanisms
for calculation of a session key based on secrets stored in the SC and in the external
device and based on dynamic data portions provided by both components at connection
time (mutual authentication mechanism). Correct calculation and usage of the session
key – shown in further communication - serves as proof of authenticity. Without proper
authentication, communications will be aborted.
Unsuccessful authentication:
Case a):
After consecutive unsuccessful authentication attempts (specified in the assurance
class development by manufacturer and not more than 20) 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), SF.IA_KEY
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 92 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
• generates an audit record of the event as required by FAU_GEN.1,
• warns the user,
• continues to accept and use non secured motion data sent by the motion sensor
as required by FIA_AFL.1/MS.
Case b):
After 5 consecutive unsuccessful authentication attempts have been detected,
SF.IA_KEY:
• generates an audit record of the event as required by FAU_GEN.1,
• warns the user,
• assumes the user as UNKNOWN, and the card as non valid
as required by FIA_AFL.1/TC.
Case c)
In case of unsuccessful authentication the user will be informed as required by
FIA_AFL.1/Remote.
Re-authentication and re-identification:
Case a):
SF.IA_KEY periodically (period specified in the assurance class development by
manufacturer and more frequently than once per hour) re-identifies and re-authenticates
the connected motion sensor as required by FIA_UAU.6/MS, and ensures that the
motion sensor identified during the last calibration of the recording equipment has not
been changed. Thereby the session key generated during the initial identification and
authentication is used.
SF.IA_KEY is able to establish, for every interaction, the identity of the motion sensor to
which it is connected as required by FIA_UID.2/MS. The identity of the motion sensor
consists of the sensor approval number and the sensor serial number.
Case b):
SF.IA_KEY re-authenticates the user using the cryptography described above at
“cryptographic protocol” at power supply recovery, periodically or after occurrence of
specific events (specified in the assurance class development by the manufacturers and
more frequently than once per day) as required by FIA_UAU.6/TC.
SF.IA_KEY permanently and selectively tracks the identity of two users, by monitoring
the tachograph cards inserted in the driver slot and the co-driver slot of the equipment
respectively.
Case c):
For every interaction with an external device, SF.IA_KEY is able to establish the device
identity.
The Identity of the TOE and the corresponding public/private key material is brought-in
during production; nobody may change these attributes of the TSF after leaving the
production environment. The same applies to other not VU-specific static security
attributes. SF.IA_KEY detects and prevents use of authentication data that has been
forged by any user or copied from any other user.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 93 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
The SF is effective only with support of the Security Functions of the SC, see 10.
9.1.10 SF.INF_PROT Residual Information Protection
SF.INF_PROT ensures that any previous information content of a resource used for
operations in which security relevant material is involved in volatile memory in the SC of
the EFAS-4.0, is explicitly erased (overwriting with “FF”) upon the allocation of a new
resource as required in FDP_RIP.1. Furthermore temporarily active keys are distributed
in accordance with FCS_CKM.3 and destroyed in accordance with FCS_CKM.4 as
implemented by SF.GEN_SKEYS. The deletion of keys takes place due value
overwriting with “FF”.
Other temporary storage objects can be re-used without implying inadmissible
information flow.
The SF is effective only with support of the Security Functions of the SC, see 10.
9.1.11 SF.FAIL_PROT Failure and Tampering Protection
SF.FAIL_PROT preserves a secure state when the following types of failures occur:
• Detection of specified values of the power supply, including cut-off.
In the case described above, SF.FAIL_PROT
• generates an audit record (except when in calibration mode) compliant with
FAU_GEN.1,
• preserve the secure state of the EFAS-4.0,
• maintain the security functions, related to components or processes still
operational,
• preserve the stored data integrity
in compliance with FPT_FLS.1.
In case of a power supply interruption, or if a transaction is stopped before completion,
or on any other reset condition, SF.FAIL_PROT resets the EFAS-4.0 clearly as required
by FPT_PHP.2//Power_Deviation.
SF.FAIL_PROT provides the capability to determine whether physical tampering has
occurred in compliance with FPT_PHP.3. The EFAS-4.0 is designed such that the case
open supervision circuit detects any “regular” case opening while the external supply
voltage is connected or not and a corresponding audit record is generated (the audit
record is generated and stored after power supply reconnection as required by
FAU_GEN.1). All other physical tampering attempts can be easily detected by visual
inspection.
After its activation, the EFAS-4.0 detects specified hardware manipulation (specified in
the assurance class development, e.g. manipulation of the real time clock generating
time stamps). In the case of sabotage of the real time clock, SF.FAIL_PROT generates
an audit record as required by FAU_GEN.1 and the EFAS-4.0 will be blocked (other
cases are specified in the assurance class development).
The SF is effective only with support of the Security Functions of the SC, see 10.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 94 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
9.1.12 SF.SELFTEST Self Test
SF.SELFTEST provides the capability of running self tests during initial start-up, and
during normal operation to verify its correct operation (FPT_TST.1).
The EFAS-4.0 self tests include the verification of the integrity of security data and the
verification of stored executable code.
Security data are stored
• in the data memory of the SC
Executable code is stored
• in the program memory of the SC
• in the program memory of the main processor.
The SC verifies the integrity of security data and executable code stored in the memory
of the SC and of respective memory of the main processor. The SC additionally verifies
the integrity of the executable code of the main processor as required by FPT_TST.1.
SF.SELFTEST ensures that only allowed tests are available (FMT_MOF.1) and
preserves a secure state in the case that failures specified in RLB_203, RLB_210,
RLB_211 take place (FPT_FLS.1).
Upon detection of an internal fault during self test, SF.SELFTEST analyses and
classifies the faults.
Classification:
• Class 0: Fatal error, main processor, SC, ROM, Flash defect. EFAS-4.0 operation
and data logging not possible.
• Class 1: Serious faults in non-essential components of the EFAS-4.0. Restricted
EFAS-4.0 operation possible (data logging not possible or only possible in an un-
secured way).
• Class 2: Warning. Single components of the EFAS-4.0 are (temporarily) not
available. EFAS-4.0 operation is possible (with data logging).
• Class 3: No error.
An audit record is generated, if necessary in accordance with FAU_GEN.1.
On failures - as required by FPT_FLS.1 - the TOE preserves a secure state.
All commands, actions or test points, specific to the testing needs of the manufacturing
phase of the EFAS-4.0 are disabled or removed before the EFAS-4.0 is activated in
accordance with FMT_MOF.1. It is not possible to restore them for later use.
The SF is supported by SF.DATA_INT.
The SF is effective only with support of the Security Functions of the SC, see 10.
9.1.13 SF.UPDATE VU Software Upgrade
SF.UPDATE performs updates of software components in a secure way. If SC software
components have to be updated an authentication with the workshop card is required to
allow the update. If the needed authentication was not successfully (FDP_ACC.1/SW-
Upgrade) no further checks take place.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 95 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
The software update mechanism which is implemented in accordance with the SFR
FMT_SMF.1/SW-Upgrade ensures that the update is performed only if the integrity and
the authenticity of the patch data is confirmed by means of update credentials
(FDP_ACF.1/SW-Upgrade, FPT_TDC.1/SW-Upgrade and FDP_ITC.2/SW-Upgrade).
SF.UPDATE decrypts the loaded software components (FCS_COP.1/AES) and
exchanges the corresponding parts of the software. In particular, the VU Software
Upgrade takes place in the following manner:
The software update patch contains two files.
-The firmware image file is encrypted (AES in CBC mode) with a AES key KFirmware.
-The credentials file is encrypted with the unique key of the associated VUs
(KENCUpdateVu) using AES in CBC mode. Only one unique VU which contains this key is
able to encrypt and to verify the credentials which contain among others the keys for
further steps KAuth, KFirmware-SC and KFirmware-MC.
KFirmware-SC and KFirmware-MC
In the first step, after decryption of the credentials file (KENCUpdateVu) the integrity and
authenticity of the credentials (KAUTHUpdateVu) are verified. If all checks are positive the
firmware images are decrypted (for SC and MC separately with KFirmware-SC and
KFirmware-MC) and the integrity (and the authenticity indirectly) of the firmware image
parts (KAuth) is verified. Only if all checks are positive, the update will take place.
The SF is effective only with support of the Security Functions of the SC, see 10.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 96 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
9.2 Assurance Measures
To satisfy the security assurance requirements defined in section 8.2, suitable
assurance measures are employed by the developer of the TOE. For the evaluation of
the TOE, the developer provides suitable documents. The documents describe the
measures and include further information supporting the verification of the conformance
of these measures against the claimed assurance requirements.
The following table includes a mapping between the assurance requirements and the
documents including the relevant information for the correspondent requirement. The
developer of the TOE provides these documents.
Assurance
Class
Family Document(s) containing the relevant information
ADV
Development
ADV_ARC.1 Security architecture description: 1030-120-SEC-DExx
(Sicherheitsarchitektur)
ADV_FSP.4 Complete functional specification: 1030-121-SEC-DExx
(Funktionale Spezifikation)
ADV_IMP.1 Implementation representation of the TSF: 1030-123-
SEC-DExx (Darstellung der Implementierung)
ADV_TDS.3 Basic modular design: 1030-122-SEC-DExx (TOE
Design)
AGD Guidance
Documents
AGD_OPE.1 Part of the Operating manual EFAS-4.0
AGD_PRE.1 Operating manual EFAS-4.0
Service and installation manual EFAS-4.0
ALC Life Cycle
Support
ALC_CMC.4 Production support, acceptance procedures and
automation: 1030-110-SEC-DExx (Leistungsfähigkeit des
Konfigurationsmanagements)
ALC_CMS.4 Problem tracking CM coverage: 1030-111-SEC-DExx
(Geltungsbereich des Konfigurationsmanagements)
ALC_DEL.1 Delivery procedures: 1030-112-SEC-DExx (Auslieferung)
ALC_DVS.1 Identification of security measures: 1030-113-SEC-DExx
(Sicherheit in der Entwicklungsumgebung)
ALC_LCD.1 Developer defined life-cycle model: Part of 1030-114-
SEC-DExx (Lebenszyklus-Beschreibung und Werkzeuge
und Techniken)
ALC_TAT.1 Well-defined development tools: Part of 1030-114-SEC-
DExx (Lebenszyklus-Beschreibung und Werkzeuge und
Techniken)
Security Target
evaluation
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 97 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Assurance
Class
Family Document(s) containing the relevant information
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security requirements
ASE_SPD.1 Security problem definition
ASE_TSS.1 TOE summary specification
ATE Tests ATE_COV.2 Analysis of coverage: Part of 1030-140-SEC-DExx
(Testdokumentation)
ATE_DPT.2 Testing: basic design: Part of 1030-140-SEC-DExx
(Testdokumentation)
ATE_FUN.1 Functional testing: Test specification and test records
ATE_IND.2 Independent testing - sample: Samples of the TOE
Source Code and Hardware
AVA Vulnerability
Assessment
AVA_VAN.5 Advanced methodical vulnerability analysis: Document
Vulnerability Analysis
Table 10:Overview of Developers’ TOE related Documents
9.3 TOE Summary Specification Rationale
9.3.1 Security Functions Rationale
The SF is effective only with support of the Security Functions of the SC see 10.
The following section demonstrates that the set and combination of the defined TOE
Security Functions is suitable to satisfy the identified TOE security functional
requirements (SFRs). Furthermore, this section shows that each of the Security
Functions is related to at least one security functional requirement.
The SFRs for the TOE of section 8.1 are related to the Security Functions of the TOE
defined in chapter 9.1. The mapping of the SFRs for the TOE to the relevant Security
Functions is done in the following.
The table below gives an overview of which Security Functions of the TOE contribute to
the satisfaction of the SFRs for the TOE and the protection profile [PPT].
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 98 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
PP and ST Security Functional
Requirements (SFR)
TOE Security Functionality (TSF)
FAU_GEN.1 SF.ACS, SF.IA_KEY, SF.SECAUDIT,
SF.DATA_INT, SF.SELFTEST, SF.FAIL_PROT,
SF.EX_INT
FAU_SAR.1 SF.SECAUDIT
FAU_STG.1 SF.ACS, SF.DATA_INT
FAU_STG.4 SF.SECAUDIT
FCO_NRO.1 SF.GEN_DIGSIG, SF.EX_INT
FCS_CKM.1 SF.GEN_SKEYS
FCS_CKM.2 SF.IA_KEY, SF.GEN_SKEYS
FCS_CKM.3 SF.ACS, SF.INF_PROT, SF.GEN_DIGSIG ,
SF.VER_DIGSIG
FCS_CKM.4 SF.INF_PROT, SF.GEN_SKEYS
FCS_COP.1/TDES SF.EX_INT, SF.EX_CONF, SF.IA_KEY
FCS_COP.1/AES SF.DATA_INT, SF.EX_INT, SF.EX_CONF,
SF.UPDATE
FCS_COP.1/RSA SF.ACS, SF.EX_INT, SF.GEN_DIGSIG,
SF.VER_DIGSIG, SF.IA_KEY
FDP_ACC.1/FIL SF.ACS
FDP_ACC.1/FUN SF.ACS
FDP_ACC.1/DAT SF.ACS
FDP_ACC.1/UDE SF.ACS
FDP_ACC.1/IS SF.ACS
FDP_ACC.1/SW-Upgrade SF.ACS, SF.UPDATE
FDP_ACF.1/FIL SF.ACS
FDP_ACF.1/FUN SF.ACS
FDP_ACF.1/DAT SF.ACS
FDP_ACF.1/UDE SF.ACS
FDP_ACF.1/IS SF.ACS
FDP_ACF.1/SW-Upgrade SF.ACS, SF.UPDATE
FDP_ETC.2 SF.IA_KEY, SF.EX_INT, SF.SECAUDIT
FDP_ITC.1 SF.ACS
FDP_ITC.2/IS SF.ACS, SF.EX_INT
FDP_ITC.2/SW-Upgrade SF.EX_INT, SF.EX_CONF, SF.UPDATE
FDP_RIP.1 SF.INF_PROT, SF.GEN_SKEYS
FDP_SDI.2 SF.SECAUDIT, SF.DATA_INT
FIA_AFL.1/MS SF.IA_KEY
FIA_AFL.1/TC SF.IA_KEY
FIA_AFL.1/Remote SF.IA_KEY
FIA_ATD.1//TC SF.IA_KEY
FIA_UAU.1/TC SF.IA_KEY
FIA_UAU.1/PIN SF.IA_KEY
FIA_UAU.2//MS SF.IA_KEY, SF.EX_INT
FIA_UAU.3/MS SF.IA_KEY
FIA_UAU.3/TC SF.IA_KEY
FIA_UAU.5//TC SF.IA_KEY
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 99 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
PP and ST Security Functional
Requirements (SFR)
TOE Security Functionality (TSF)
FIA_UAU.6/MS SF.IA_KEY, SF.EX_INT
FIA_UAU.6/TC SF.IA_KEY
FIA_UID.2/MS SF.IA_KEY, SF.EX_INT
FIA_UID.2/TC SF.IA_KEY
FMT_MSA.1 SF.ACS, SF.IA_KEY
FMT_MSA.3/FUN SF.IA_KEY, SF.ACS
FMT_MSA.3/FIL SF.ACS
FMT_MSA.3/DAT SF.ACS
FMT_MSA.3/IS SF.IA_KEY, SF.ACS
FMT_MSA.3/UDE SF.ACS
FMT_MOF.1 SF.SELFTEST
FMT_SMF.1/PP SF.ACS
FMT_SMF.1/SW-Upgrade SF.UPDATE
FMT_SMR.1//TC SF.IA_KEY
FPR_UNO.1 SF.ACS
FPT_FLS.1 SF.SELFTEST, SF.FAIL_PROT
FPT_PHP.2//Power_Deviation SF.FAIL_PROT
FPT_PHP.3 SF.FAIL_PROT
FPT_STM.1 SF.ACS, SF.SECAUDIT
FPT_TDC.1/IS SF.ACS
FPT_TDC.1/SW-Upgrade SF.UPDATE
FPT_TST.1 SF.SELFTEST
FRU_PRS.1 SF.ACS
Table 11: Coverage of Security Functional Requirements by TOE Security Functionality
In the following, for each SFR of the TOE it will be explained why and how the Security
Functions listed in the preceding tables meet the respective SFR.
FAU_GEN.1
SF.ACS contributes audit data through logging of events which deviate from the
admissible FDP_ACC.1, SF.EX_INT contributes audit data through logging of data
integrity faults, SF.IA_KEY contributes audit data through logging of authentication
events, SF.FAIL_PROT contributes audit data through logging of assumed tampering
events, SF.SELFTEST contributes audit data through logging of self-test failures.
The SF.SECAUDIT meets FAU_GEN.1 as it implements the SFR. In particular
SF.SECAUDIT generates audit records as specified by the SFR.
SF.DATA_INT supports the SFR, it cares for the preservation of integrity of stored audit
data.
FAU_SAR.1
SF.SECAUDIT meets FAU_SAR.1 as it implements the SFR. In particular
SF.SECAUDIT allows for printing, displaying and downloading audit records.
FAU_STG.1
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 100 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
SF.ACS supports FAU_STG.1 as it denies unauthorised writing/deletion access to
stored audit data records, in combination with SF.DATA_INT which contributes to the
detection of modified or deleted audit records it implements the SFR.
FAU_STG.4
SF.SECAUDIT meets FAU_STG.4 as it implements the SFR.
FCO_NRO.1
SF.EX_INT implements the SFR FCO_NRO.1.
SF.GEN_DIGSIG allows for the generation of digital signatures as proof of origin.
FCS_CKM.1
SF.GEN_SKEYS directly implements FCS_CKM.1.
FCS_CKM.2
SF.IA_KEY and SF.GEN_SKEYS directly implement FCS_CKM.2.
FCS_CKM.3
SF.ACS as it denies unauthorised access to stored data. Authorised access takes place
by the functions SF.GEN_DIGSIG, SF.VER_DIGSIG.
SF.INF_PROT as it explicitly erases security relevant material.
FCS_CKM.4
SF.GEN_SKEYS as it allows for implicit key destruction as soon as adequate.
SF.INF_PROT erases the temporarily needed and used keys.
FCS_COP.1/TDES
TDES algorithm is implemented and used by the functions SF.EX_INT, SF.EX_CONF
and SF.IA_KEY in accordance with specified protocols and referenced standards.
FCS_COP.1/AES
AES algorithm is implemented and used by the function SF.DATA_INT, SF.EX_INT,
SF.EX_CONF, SF.UPDATE in accordance with specified protocols and referenced
standards.
FCS_COP.1/RSA
SF.EX_INT and SF.IA_KEY implement FCS_COP.1/RSA for tachograph card
communication (see [GST] CSM_020), relying on SF.GEN_DIGSIG, SF.VER_DIGSIG,
while SF.EX_INT and SF.GEN_DIGSIG fulfil [GST] CSM_032.
FDP_ACC.1/FIL
SF.ACS directly implements FDP_ACC.1/FIL
FDP_ACC.1/FUN
SF.ACS directly implements FDP_ACC.1/FUN.
FDP_ACC.1/DAT
SF.ACS directly implements FDP_ACC.1/DAT.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 101 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
FDP_ACC.1/UDE
SF.ACS directly implements FDP_ACC.1/UDE.
FDP_ACC.1/IS
SF.ACS directly implements FDP_ACC.1/IS.
FDP_ACC.1/SW-Upgrade
SF.ACS and SF.UPDATE directly implement FDP_ACC.1/SW-Upgrade.
FDP_ACF.1/FIL
SF.ACS directly implements FDP_ACF.1/FIL.
FDP_ACF.1/FUN
SF.ACS directly implements FDP_ACF.1/FUN.
FDP_ACF.1/DAT
SF.ACS directly implements FDP_ACF.1/DAT.
FDP_ACF.1/UDE
SF.ACS directly implements FDP_ACF.1/UDE.
FDP_ACF.1/IS
SF.ACS directly implements FDP_ACF.1/IS.
FDP_ACF.1/SW-Upgrade
SF.ACS and SF.UPDATE directly implement FDP_ACF.1/SW-Upgrade.
FDP_ETC.2
SF.IA_KEY is used for preserving the validity of the authenticity proof, SF.EX_INT is
used for securing the exported data against unauthorised change, SF.SECAUDIT
provides everybody with the capability to read recorded information possibly secured as
required in FDP_ETC.2.
FDP_ITC.1
SF.ACS directly implements FDP_ITC.1.
FDP_ITC.2/IS
SF.ACS directly implements the access control aspect of FDP_ITC.2/IS.
SF.EX_INT ensures that imported user data is authenticated towards the TOE.
FDP_ITC.2/SW-Upgrade
SF.EX_INT and SF.EX_CONF directly implement the FDP_ITC.2/SW-Upgrade.
FDP_RIP.1
SF.INF_PROT and SF.GEN_SKEYS directly implement FDP_RIP.1.
FDP_SDI.2
SF.SECAUDIT implements the audit record generation while SF.DATA_INT detects
possible integrity violations.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 102 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
FIA_AFL.1/MS
SF.IA_KEY directly implements FIA_AFL.1/MS.
FIA_AFL.1/TC
SF.IA_KEY directly implements FIA_AFL.1/TC.
FIA_AFL.1/Remote
SF.IA_KEY directly implements FIA_AFL.1/Remote
FIA_ATD.1//TC
SF.IA_KEY directly implements FIA_ ATD.1//TC.
FIA_UAU.1/TC
SF.IA_KEY directly implements FIA_UAU.1/TC.
FIA_UAU.1/PIN
SF.IA_KEY directly implements FIA_ UAU.1/PIN.
FIA_UAU.2//MS
SF.IA_KEY directly implements FIA_UAU.2//MS.
SF.EX_INT checks the integrity-association between data and originator.
FIA_UAU.3/MS
SF.IA_KEY directly implements FIA_UAU.3/MS.
FIA_UAU.3/TC
SF.IA_KEY directly implements FIA_UAU.3/TC.
FIA_UAU.5//TC
SF.IA_KEY directly implements FIA_UAU.5//TC.
FIA_UAU.6/MS
SF.IA_KEY directly implements FIA_UAU.6/MS
SF.EX_INT checks the integrity-association between data and originator.
FIA_UAU.6/TC
SF.IA_KEY directly implements FIA_UAU.6/TC
FIA_UID.2/MS
SF.IA_KEY directly implements FIA_UID.2/MS
SF.EX_INT checks the integrity-association between data and originator.
FIA_UID.2/TC
SF.IA_KEY directly implements FIA_UID.2/TC
FMT_MSA.1
SF.IA_KEY directly implements FMT_MSA.1
SF.ACS denies access to the stored data to everybody.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 103 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
FMT_MSA.3/FUN
SF.IA_KEY directly implements FMT_MSA.3/FUN.
SF.ACS denies access to the stored data to everybody.
FMT_MSA.3/FIL
SF.ACS directly implements FMT_MSA.3/FIL
FMT_MSA.3/DAT
SF.ACS directly implements FMT_MSA.3/DAT
FMT_MSA.3/IS
SF.IA_KEY and SF.ACS directly implement FMT_MSA.3/IS
FMT_MSA.3/UDE
SF.ACS directly implements FMT_MSA.3/UDE
FMT_MOF.1
SF.SELFTEST directly implements FMT_MOF.1
FMT_SMF.1/PP
SF.ACS directly implements FMT_SMF.1/PP.
FMT_SMF.1/SW-Upgrade
SF.UPDATE directly implements FMT_SMF.1/SW-Upgrade.
FMT_SMR.1//TC
SF.IA_KEY relates authentication data to IDs and associated roles and thus fulfils
FMT_SMR.1//TC.
FPR_UNO.1
SF.ACS directly implements FPR_UNO.1.
FPT_FLS.1
SF.SELFTEST preserves the secure state on internal faults ([GST] RLB_203).
SF.FAIL_PROT preserves the secure state on deviations of specific values for power
supply or even interruptions ([GST] RLB_210, RLB_210).
FPT_PHP.2//Power_Deviation
SF.FAIL_PROT directly implements FPT_PHP.2//Power_Deviation
FPT_PHP.3
SF.FAIL_PROT directly implements FPT_PHP.3
FPT_STM.1
SF.ACS ensures that user data (here time information) may only be processed from the
right input sources – VU’s real time clock. SF.SECAUDIT is able to provide reliable time
stamps.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 104 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
FPT_TDC.1/IS
SF.ACS directly implements FPT_TDC.1/IS.
FPT_TDC.1/SW-Upgrade
SF.UPDATE directly implements FPT_TDC.1/SW-Upgrade.
FPT_TST.1
SF.SELFTEST directly implements FPT_TST.1.
FRU_PRS.1
SF.ACS directly implements FRU_PRS.1.
9.3.2 Assurance Measures Rationale
The assurance measures of the developer as referred in sections 8.2 and 9.2 are
suitable and sufficient to meet the CC assurance level EAL4 augmented by AVA_VAN.5
and ATE_DPT.2 as claimed in section 8.2. In particular, the deliverables listed in
chapter 9.2 are suitable and sufficient to document that the assurance requirements are
met.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 105 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
10 Statement of Compatibility
This is a statement of compatibility between this Composite Security Target and the
Security Target of the INFINEON Security Controller M7801 A12 [SCST].
It is made in strict accordance with [AIS36].
10.1 Relevance of Security Controller TSF
The following table shows the relevance of the Security Controller security functions for
the composite Security Target:
Security Controller TSF Relevant Not Relevant
SF_DPM: Device Phase Management X
SF_PS: Protection against Snooping X
SF_PMA: Protection against Modifying Attacks X
SF_PLA: Protection against Logical Attacks X
SF_CS: Cryptographic Support X
Table 12: Relevance of Security Controller TSF for Composite ST
Cryptographic support includes Triple-DES (relevant), AES (relevant), RSA (relevant), EC (not
relevant), SHA-2 (SHA-256 and SHA512 – both not relevant), TRNG (relevant) and PRNG (not
relevant).
10.2 Security Requirements
10.2.1 Security Functional Requirements
Security Functional Requirements of the TOE
The following SFRs are definitely Tachograph specific and have no conflicts with the
SFRs of the Security Controller but could not be traced or mapped to the SFRs of the
Security Controller:
FAU_GEN.1
FAU_SAR.1
FAU_STG.4
FCS_CKM.2
FCS_CKM.3
FCS_CKM.4
FDP_ETC.2
FDP_ITC.1
FDP_ITC.2/IS
FDP_ITC.2/SW-Upgrade
FIA_AFL.1/MS
FIA_AFL.1/TC
FIA_AFL.1/Remote
FIA_ATD.1//TC
FIA_UAU.1/TC
FIA_UAU.1/PIN
FIA_UAU.2//MS
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 106 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
FIA_UAU.3/MS
FIA_UAU.3/TC
FIA_UAU.5/TC
FIA_UAU.6/MS
FIA_UAU.6/TC
FIA_UID.2/MS
FIA_UID.2/TC
FMT_MOF.1
FMT_SMF.1/PP
FMT_SMF.1/SW-Upgrade
FMT_SMR.1//TC
FPT_STM.1
FPT_TDC.1/IS
FPT_TDC.1/SW-Upgrade
FRU_PRS.1
Security Functional Requirements of the Security Controller
FAU_SAS.1 not relevant, because not applicable, no conflict
FCS_RNG.1 covered by FCS_CKM.1
FCS_COP.1/DES covered by FCS_COP.1/TDES
FCS_COP.1/AES covered by FCS_COP.1/AES
FCS_COP.1/RSA covered by FCS_COP.1/RSA
FCS_COP.1/ECDSA not relevant, because not used, no conflict
FCS_COP.1/EC not relevant, because not used, no conflict
FCS_COP.1/ECDH not relevant, because not used, no conflict
FCS_COP.1/SHA not relevant, because not used, no conflict
FCS_CKM.1/RSA not relevant, because not used, no conflict
FCS_CKM.1/EC not relevant, because not used, no conflict
FDP_ACC.1 covered by FDP_ACC.1/* (see table below)
FDP_ACF.1 covered by FDP_ACF.1/* (see table below)
FDP_IFC.1 covered by FDP_RIP.1, FPR_UNO.1
FDP_ITT.1 covered by FDP_RIP.1, FPR_UNO.1
FDP_SDI.1 covered by FDP_SDI.2, FAU_STG.1
FDP_SDI.2 covered by FDP_SDI.2, FAU_STG.1
FMT_LIM.1 covered by FDP_RIP.1, FPR_UNO.1
FMT_LIM.2 covered by FDP_RIP.1, FPR_UNO.1
FMT_MSA.1 covered by FMT_MSA.1
FMT_MSA.3 covered by FMT_MSA.3/* (see table below)
FMT_SMF.1 covered by FDP_ACC.1/*, FDP_ACF.1/* (see table below)
FPT_FLS.1 covered by FPT_FLS.1
FPT_ITT.1 covered by FDP_RIP.1, FPR_UNO.1
FPT_PHP.3 covered by FPT_PHP.2//Power_Deviation, FPT_PHP.3
FPT_TST.2 covered by FPT_TST.1
FRU_FLT.2 covered by FPT_FLS.1
Tracing of Security Controller SFRs to TOE SFRs
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 107 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Security
Controller
SFRs
TOE SFRs
FCS_RNG.1
FCS_COP.1/DES
FCS_COP.1/AES
FCS_COP.1/RSA
FDP_ACC.1
FDP_ACF.1
FDP_IFC.1
FDP_ITT.1
FDP_SDI.1
FDP_SDI.2
FMT_LIM.1
FMT_LIM.2
FMT_MSA.1
FMT_MSA.3
FMT_SMF.1
FPT_FLS.1
FPT_ITT.1
FPT_PHP.3
FPT_TST.2
FRU_FLT.2
FAU_STG.1 X X
FCS_CKM.1 X
FCS_COP.1/TDES X
FCS_COP.1/AES X
FCS_COP.1/RSA X
FDP_ACC.1/FIL X X
FDP_ACC.1/FUN X X
FDP_ACC.1/DAT X X
FDP_ACC.1/UDE X X
FDP_ACC.1/IS X X
FDP_ACC.1/SW-
Upgrade
X X
FDP_ACF.1/FIL X X
FDP_ACF.1/FUN X X
FDP_ACF.1/DAT X X
FDP_ACF.1/UDE X X
FDP_ACF.1/IS X X
FDP_ACF.1/SW-
Upgrade
X X
FDP_RIP.1 X X X X X
FDP_SDI.2 X X
FMT_MSA.1 X
FMT_MSA.3/FUN X
FMT_MSA.3/FIL X
FMT_MSA.3/DAT X
FMT_MSA.3/IS X
FMT_MSA.3/UDE X
FMT_MSA.3/SW-
Upgrade
X
FPR_UNO.1 X X X X X
FPT_FLS.1 X X
FPT_PHP.2//Powe
r_Deviation
X
FPT_PHP.3 X
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 108 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Security
Controller
SFRs
TOE SFRs
FCS_RNG.1
FCS_COP.1/DES
FCS_COP.1/AES
FCS_COP.1/RSA
FDP_ACC.1
FDP_ACF.1
FDP_IFC.1
FDP_ITT.1
FDP_SDI.1
FDP_SDI.2
FMT_LIM.1
FMT_LIM.2
FMT_MSA.1
FMT_MSA.3
FMT_SMF.1
FPT_FLS.1
FPT_ITT.1
FPT_PHP.3
FPT_TST.2
FRU_FLT.2
FPT_TST.1 X
10.2.2 Security Assurance Requirements
The level of assurance of the TOE given in chapter 4 is EAL4 augmented with the
components ATE_DPT.2 and AVA VAN.5.
The level of assurance of the Security Controller is EAL 5 augmented with the
components ALC_DVS.2 and AVA_VAN.5 according to [SCST].
This shows that the Security Assurance Requirements of the TOE matches the Security
Assurance Requirements of the hardware.
10.3 Security Objectives
Security Objectives for the Security Controller
O.Phys-Manipulation Protection against Physical Manipulation: No conflict.
O.Phys-Probing Protection against Physical Probing: No conflict.
O.Malfunction Protection against Malfunction due to Environmental Stress: No conflict.
O.Leak-Inherent Protection against Inherent Information Leakage: No conflict.
O.Leak-Forced Protection against Forced Information Leakage: No conflict.
O.Abuse-Func Protection against Abuse of Functionality: No conflict.
O.Identification TOE Identification: No conflict.
O.RND Random Numbers: No conflict.
O.Add-Functions Additional specific security functionality: No conflict.
O.Mem-Access Area based Memory Access Control: No conflict.
Security Objectives for the Security Controller Environment
OE.Process-Sec-IC Protection during composite product manufacturing: No conflict
OE.Plat-Appl Usage of Hardware Platform: No conflict
OE.Resp-Appl Treatment of User Data: No conflict
Security Objectives of the TOE
O.Access: No conflict.
O.Accountability: No conflict.
O.Audit: No conflict.
O.Authentication: No conflict.
O.Integrity: No conflict.
O.Output: No conflict.
O.Processing: No conflict.
O.Reliability: No conflict.
O.Secured_Data_Exchange: No conflict.
O.Software_Analysis: No conflict.
O.Software_Upgrade: No conflict.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 109 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Security Objectives of the TOE Environment
(only objectives of the design and manufacturing environment are relevant)
OE.Development No conflict.
OE.Manufacturing No conflict.
OE.Sec_Data_Generation No conflict.
OE.Sec_Data_Transport No conflict.
OE.Delivery No conflict.
OE.Software_Upgrade No conflict.
OE.Sec_Data_Strong No conflict.
OE.Test_Points No conflict.
Tracing of Security Controller objectives to TOE objectives
Objectives for the TOE
Objectives for the
Security Controller
hardware
O.Access
O.Accountability
O.Audit
O.Authentication
O.Integrity
O.Output
O.Processing
O.Reliability
O.Secured_Data_Exchange
O.Software_Analysis
O.Software_Upgrade
O.Phys-Manipulation X X X X X
O.Phys-Probing X X X X
O.Malfunction X X X X X
O.Leak-Inherent X X X X X
O.Leak-Forced X X X X X X
O.Abuse-Func X X X X X X X X
O.RND X X X X X X X X X
O.Add-Functions X X
O.Mem-Access X X X X X X
Table 13: Mapping of Security Controller objectives to TOE objectives
The security objectives of the design and manufacturing environment of the TOE
include in general meaning parts of the security objectives of the Security Controller.
Other parts are covered by the security objectives of the TOE (O.Access,
O.Authenticate, O.Integrity, O.Processing, O.Secured_Data_Exchange,
O.Software_Analysis, O.Software_Upgrade), see assumption section 10.4.1.
The security objective of the Security Controller O.Identification can not be mapped
because it is related to the production life cycle phase only.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 110 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
10.4 Compatibility: TOE security environment
10.4.1 Assumptions
The following list shows that neither assumption of the TOE nor of the Security
Controller has any conflicts between each other. They are covered by appropriate
Security Objectives.
Assumptions of the Security Controller hardware
A.Process-Sec-IC Protection during Packaging, Finishing and Personalisation: No conflict
A.Plat-Appl Usage of Hardware Platform: No conflict
A.Resp-Appl Treatment of User Data: No conflict
A.Key-Function Usage of Key-dependent Functions: No conflict
Assumptions of the TOE
A.Activation Activation of the TOE: No conflict
A.Approved_Workshop Approved workshops: No conflict
A.Card_Availability Availability of Tachograph Cards: No conflict
A.Card_Tracebility Tracebility of delivered Tachograph Cards: No conflict
A.Controls Law conformance controls: No conflict
A.Driver_Card_Uniqueness Uniqueness of the driver card: No conflict
A.Faithful_Calibration Faithful calibration: No conflict
A.Faithful_Drivers Faithful drivers: No conflict
A.Regular_Inspections Regular inspection and calibration: No conflict
The assumptions do not have conflicts because it is obviously that the assumptions are
made for different levels - controller level without respect to an application and
Tachograph application level.
Tracing of Security Controller assumptions to Security Objectives
Assumptions for the
Security Controller
Security Objectives of the TOE and environment covering them
A.Process-Sec-IC OE.Development, OE.Manufacturing, OE.Sec_Data_Transport
A.Plat-Appl OE.Development, OE.Manufacturing, OE.Sec_Data_Transport
A.Resp-Appl OE.Development, OE.Manufacturing, OE.Test_Points, O.Access,
O.Authenticate, O.Integrity, O.Processing, O.Secured_Data_Exchange,
O.Software_Analysis, O.Software_Upgrade
A.Key-Function OE.Development, OE.Manufacturing, OE.Sec_Data_Transport,
OE.Test_Points, O.Access, O.Authenticate, O.Integrity,
O.Secured_Data_Exchange, O.Software_Analysis, O.Software_Upgrade
Table 14: Mapping of Security Controller assumptions to TOE objectives
10.4.2 Threats
The threats of the TOE and the Security Controller have no conflicts between each
other. They are shown in the following.
Threats of the Security Controller
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 111 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
T.Phys-Manipulation Physical Manipulation: No conflict
T.Phys-Probing Physical Probing: No conflict
T.Malfunction Malfunction due to Environmental Stress: No conflict
T.Leak-Inherent Inherent Information Leakage: No conflict
T.Leak-Forced Forced Information Leakage: No conflict
T.Abuse-Func Abuse of Functionality: No conflict
T.RND Deficiency of Random Numbers: No conflict
T.Mem-Access Memory Access Violation: No conflict
Threats of the TOE
T.Card_Data_Exchange: No conflict
T.Faults: No conflict
T.Output_Data: No conflict
T.Access: No conflict
T.Calibration_Parameters: No conflict
T.Clock: No conflict
T.Design: No conflict
T.Environment: No conflict
T.Fake_Device: No conflict
T.Hardware: No conflict
T.Identification: No conflict
T.Motion_Data: No conflict
T.Power_Supply: No conflict
T.Security_Data: No conflict
T.Software: No conflict
T.Stored_Data: No conflict
T.Tests: No conflict
T.Non_Activated: No conflict
Tracing of Security Controller threats to TOE threats
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 112 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
Threats for the TOE
Threats for the
Security Controller
hardware
T.Card_Data_Exchange
T.Faults
T.Output_Data
T.Access
T.Calibration_Parameters
T.Clock
T.Design
T.Environment
T.Fake_Device
T.Hardware
T.Identification
T.Motion_Data
T.Power_Supply
T.Security_Data
T.Software
T.Stored_Data
T.Tests
T.Non_Activated
T.Phys-Manipulation X X X X X X X X X X X X X X X X X
T.Phys-Probing X X X X X X X X X X X X X X X
T.Malfunction X X X X X X X X X X X X X X X X
T.Leak-Inherent X X X X X X X X X X X X X X X X
T.Leak-Forced X X X X X X X X X X X X X X X
T.Abuse-Func X X X X X X X X X X X X X X X
T.RND X X X X X X X X X X X X X X X
T.Mem-Access X X X X X X X X X X X X X X X
Table 15: Mapping of Security Controller threats to TOE threats
The results are not unexpected, because all security features of the Security Controller
are important for and used by the TOE. The whole security of the TOE is based on the
security of the Controller. If the Security Controller would not be able to counter one of
its threats nearly all threats could not be countered by the TOE.
10.4.3 Organisational Security Policies
The Organisational Security Policies of the TOE and the Security Controller have no
conflicts between each other. They are shown in the following list.
Organisational Security Policies of the Security Controller
P.Process-TOE Protection during TOE Development and Production: No conflict.
P.Add-Functions Additional Specific Security Functionality: No conflict.
Organisational Security Policies of the TOE
OSP.Accountability: No conflict.
OSP.Audit: No conflict.
OSP.Processing: No conflict.
OSP.Test_Points: No conflict.
OSP.Type_Approved_MS: No conflict.
OSP.SW_Upgrade: No conflict.
OSP.PKI: No conflict.
OSP.MS_Keys: No conflict.
Tracing of Security Controller objectives to TOE objectives
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 113 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
OSPs for the TOE
OSPs for the
Security Controller
OSP.Accountability
OSP.Audit
OSP.Processing
OSP.Test_Points
OSP.Type_Approved_MS
OSP.SW_Upgrade
OSP.PKI
OSP.MS_Keys
Not
applicable
P.Process-TOE (Protection
during TOE Development
and Production)
X
P.Add-Functions (Additional
Specific Security
Functionality)
X
Not applicable X X X X X X X
Table 16: Mapping of Security Controller OSPs to TOE OSPs
10.5 Conclusion
Overall no contradictions between the Security Targets of the TOE and the Security
Controller hardware are found.
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 114 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
11 Annex
11.1 Glossary and list of acronyms
A.x Assumption
CA Certification Authority
AES Advanced Encryption Standard
CBC Cipher Block Chaining
CC Common Criteria
CCMB Common Criteria Management Board
DES Data Encryption Standard
EAL Evaluation Assurance Level (a pre-defined package in CC)
ECB Electronic Code Book (an operation mode of a block cipher; here of TDES)
EEPROM Multiple programmable ROM
EQTj.C Equipment Certificate
EQTj.PK Equipment Public Key
EQTj.SK Equipment Private Key
ERCA European Root Certification Authority (see Administrative Agreement
17398-00-12 (DG-TREN))
EUR.PK European Public Key
SF.x Security Function
Flash Multiple programmable ROM memory with sector erase.
GST Generic Security Target for VU as defined in [GST]
ITSEC Information Technology Security Evaluation Criteria
ISO International Standardisation Organisation
JIL Joint Interpretation Library
KID Identification key, will manage the pairing between a motion sensor and the
vehicle unit
Km Master key, will manage the pairing between a motion sensor and the
vehicle unit
KmVU Part of the Master key stored in the VU, will manage the pairing between a
motion sensor and the vehicle unit
KmWC Part of the Master key stored in the workshop card, will manage the pairing
between a motion sensor and the vehicle unit
KP Pairing key, will manage the pairing between a motion sensor and the
vehicle unit
KSM Session key between motion sensor and vehicle unit
KST Session key between tachograph cards and vehicle unit
LED Light Emitting Diode
MAC Message Authentication Code
MC Main Controller
MD Management Device as defined in [GST]
MS Motion Sensor
MSA Member State Authority
MSCA Member State Certification Authority (see Administrative Agreement
17398-00-12 (DG-TREN))
MSi.C Member State certificate
NCA National Certification Authority
O.x Security Objective of the TOE
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 115 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
OE.x Security Objective of the Environment
OS Operating System
OSP Organisational security policy
PIN Personal Identification Number
PKI Public Key Infrastructure
PP Protection Profile
RAD Reference Authentication Data
RAM Random Access Memory (loses data if detached from a power supply)
REQxxx A requirement from [EU], where ‘xxx’ represents the requirement number.
ROM Read Only Memory (stores data independent of a power supply)
RSA Rivest-Shamir-Adleman Algorithm
SAR Security Assurance Requirement
RTC Real time clock
SC Security Controller
SEF Security Enforcing Function
SF Security Function
SFP Security Function Policy (see CC part 2)
SFR Security Functional Requirement
ST Security Target
TC Tachograph Card
TDES Triple-DES (see FIPS PUB 46-3)
TOE Target of Evaluation
ToSS TOE Security Service
TSF TOE Security Functionality
T.x Threat
UDI.PK public key of the update issuer
UDI.SK private key of the update issuer
VAD Verification Authentication Data
VU Vehicle Unit
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 116 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
11.2 Bibliography
[CC1] Common Criteria, Part 1: Common Criteria for Information Technology
Security Evaluation,
Part 1: Introduction and general model, Version 3.1, July 2009
[CC2] Common Criteria, Part 2: Common Criteria for Information Technology
Security Evaluation,
Part 2: Security functional components, Version 3.1, July 2009
[CC3] Common Criteria, Part 3: Common Criteria for Information Technology
Security Evaluation,
Part 3: Security assurance components, Version 3.1, July 2009
[CM] Common Methodology for Information Technology Security Evaluation,
Evaluation methodology, Version 3.1, Revision 3, July 2009
[AIS36] Anwendungshinweise und Interpretationen zum Schema, AIS36, Version 3,
19.10.2010, Bundesamt für Sicherheit in der Informationstechnik
[CSM] Appendix 11 of Annex I B of Commission Regulation (EEC) No. 1360/2002
– Common Security Mechanisms
[EU] Annex 1B of Commission Regulation (EC) No.1360/2002 on recording
equipment in road transport: Requirements for Construction, Testing,
Installation and Inspection (in: Official Journal of the European
Communities, L 207 / 1 ff.), Commission of the European Communities,
05.08.2002.
corrected by
Corrigendum in Official Journal of the European Communities L 77,
13.3.2004, p.71–86 (EN):
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).
corrected 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
corrected by
COMMISSION REGULATION (EC) No 68/2009 of 23 January 2009
adapting for the ninth time to technical progress Council Regulation (EEC)
No 3821/85 on recording equipment in road transport.
corrected by
COMMISSION REGULATION (EU) No 1266/2009 of 16 December 2009
adapting for the tenth time to technical progress Council Regulation (EEC)
No 3821/85 on recording equipment in road transport (Text with EEA
relevance)
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 117 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
[EU1B] Annex I B of Commission Regulation (EC) No. 1360/2002 ‘Requirements for
construction, testing, installation and inspection’, 05.08.2002 and last
amended by CR (EC) No. 432/2004 and corrigendum dated as of
13.03.2004 (OJ L 77)
[GST] Appendix 10 of Annex I B of Commission Regulation (EEC) No. 1360/2002
– Generic Security Targets
[SCST] Security Target M7801 A12 including optional Software Libraries RSA - EC
– SHA-2, Version 0.6, 2011-04-15, Hans-Ulrich Buchmüller
[ISO9001] ISO 9001:2008, First edition: 2000
http://www.iso.org/iso/rss.xml?csnumber=46486&rss=detail
[ISO7816] ISO/IEC 7816-2 Information technology . Identification cards . Integrated
circuit(s) cards with contacts . Part 2:Dimensions and location of the
contacts. First edition: 1999.
ISO/IEC 7816-3 Information technology . Identification cards . Integrated
circuit(s) cards with contacts . Part 3: Electronic signals and transmission
protocol. Edition 2: 1997.
ISO/IEC 7816-4 Information technology . Identification cards . Integrated
circuit(s) cards with contacts . Part 4: Interindustry commands for
interexchange. First edition: 1995 + Amendment 1: 1997.
ISO/IEC 7816-6 Information technology . Identification cards . Integrated
circuit(s) cards with contacts . Part 6: Interindustry data elements. First
Edition: 1996 + Cor 1: 1998.
ISO/IEC 7816-8 Information technology . Identification cards . Integrated
circuit(s) cards with contacts . Part 8: Security related interindustry
commands. First Edition: 1999.
[ISO9796] ISO/IEC 9796-2 Information Technology . Security techniques . Digital
signature schemes giving message recovery . Part 2: Mechanisms using a
hash function. First edition: 1997
[ISO16844] ISO 16844-3 Road vehicles . Tachograph systems . Motion Sensor
Interface. WD 3-20/05/99.
[JIL] JIL Security Evaluation and Certification of Digital Tachographs, Version
1.12, JIL Working Group (BSI, CESG, DCSSI, NLNCSA), June 2003.
[PPT] Protection Profile ‘Digital Tachograph – Vehicle Unit (VU PP)’, BSI-CC-PP-
0057, version 1.0 as of 13th July 2010
[TR-02102] Kryptographische Verfahren: Empfehlungen und Schlüssellängen, BSI-
Technische Richtlinie, Version 1.0, 20.06.2008
[FIPS 197] Federal Information Processing Standards Publication 197 (FIPS PUB 197).
Advances Encryption Standard (AES), 2001
[NIST SP800-38A] NIST. Recommendation for Block Cipher Modes of Operation:
Methods and Techniques, Special Publication SP800-38A, National Institute
of Standards and Technology, Technology Administration, U.S. Department
of Commerce, 2001
EFAS-4
Security Target EFAS-4.0
document number version last change author status page
1030-100-SEC-EN18 18 2011-11-10 Dr. Horst Kießling released 118 of 118
Important
notice:
This
document
is
the
property
of
intellic
Germany
GmbH
and
should
not
be
copied
or
distributed
without
permission.
[NIST SP800-38B] NIST. Recommendation for Block Cipher Modes of Operation: The
CMAC Mode for Authentication, Special Publication SP800-38B, National
Institute of Standards and Technology, Technology Administration, U.S.
Department of Commerce, 2001