Common Criteria Protection Profile
Machine-Readable Electronic Documents based on BSI TR-03110 for Official
Use [MR.ED-PP]
BSI-CC-PP-0087
Document history
Version 1.01, May 20th, 2015
Federal Office for Information Security
Post Box 20 03 63
D-53133 Bonn
Phone: +49 22899 9582-0
E-Mail: eid@bsi.bund.de
Internet: https://www.bsi.bund.de
© Federal Office for Information Security 2015
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Table of Contents
Table of Contents
Document history.............................................................................................................................................................................. 2
1 PP Introduction................................................................................................................................................................................... 5
1.1 PP Reference.................................................................................................................................................................................. 5
1.2 TOE Overview............................................................................................................................................................................... 5
1.2.1 TOE Definition and Operational Usage......................................................................................................................5
1.2.2 TOE major Security Features for Operational Use................................................................................................7
1.2.3 TOE Type................................................................................................................................................................................... 7
1.2.4 TOE Life Cycle........................................................................................................................................................................ 8
1.2.5 Non-TOE Hardware/Software/Firmware..................................................................................................................9
1.2.6 Recommended TOE Design...........................................................................................................................................10
1.3 Guidance for using this Protection Profile....................................................................................................................11
1.3.1 Motivation............................................................................................................................................................................. 11
1.3.2 Usage........................................................................................................................................................................................ 12
1.3.3 TOE Functionality versus TSF......................................................................................................................................13
1.3.4 Security Targets, Strict Conformance, and Evaluation......................................................................................13
2 Conformance Claims...................................................................................................................................................................... 15
2.1 CC Conformance Claim......................................................................................................................................................... 15
2.2 PP Claim........................................................................................................................................................................................ 15
2.3 Package Claim............................................................................................................................................................................. 16
2.4 Conformance Rationale.........................................................................................................................................................16
2.5 Conformance Statement........................................................................................................................................................ 16
3 Security Problem Definition....................................................................................................................................................... 17
3.1 Introduction................................................................................................................................................................................ 17
3.1.1 Assets........................................................................................................................................................................................ 17
3.1.2 Subjects.................................................................................................................................................................................... 19
3.2 Threats............................................................................................................................................................................................ 20
3.2.1 Threats from [EAC1PP]....................................................................................................................................................21
3.2.2 Threats from [EAC2PP]....................................................................................................................................................21
3.2.3 Threats from [PACEPP].................................................................................................................................................... 21
3.2.4 Threats from [SSCDPP].................................................................................................................................................... 21
3.3 Organizational Security Policies........................................................................................................................................22
3.3.1 OSPs from [EAC1PP]......................................................................................................................................................... 22
3.3.2 OSPs from [EAC2PP]......................................................................................................................................................... 22
3.3.3 OSPs from [PACEPP].........................................................................................................................................................22
3.3.4 OSPs from [SSCDPP].........................................................................................................................................................22
3.3.5 Additional OSPs.................................................................................................................................................................. 23
3.4 Assumptions................................................................................................................................................................................ 23
3.4.1 Assumptions from [EAC1PP]........................................................................................................................................23
3.4.2 Assumptions from [EAC2PP]........................................................................................................................................23
3.4.3 Assumptions from [PACEPP]........................................................................................................................................23
3.4.4 Assumptions from [SSCDPP]........................................................................................................................................24
4 Security Objectives.......................................................................................................................................................................... 25
4.1 Security Objectives for the TOE..........................................................................................................................................25
4.1.1 Security Objectives for the TOE from [EAC1PP]..................................................................................................25
4.1.2 Security Objectives for the TOE from [EAC2PP]..................................................................................................25
Federal Office for Information Security 3
Table of Contents BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
4.1.3 Security Objectives for the TOE from [PACEPP]..................................................................................................25
4.1.4 Security objectives for the TOE from [SSCDPP]...................................................................................................26
4.1.5 Additional Security Objectives for the TOE...........................................................................................................26
4.2 Security Objectives for the Operational Environment............................................................................................27
4.2.1 Security objectives from [EAC1PP].............................................................................................................................27
4.2.2 Security Objectives from [EAC2PP]............................................................................................................................27
4.2.3 Security Objectives from [PACEPP]............................................................................................................................27
4.2.4 Security Objectives from [SSCDPP]............................................................................................................................27
4.2.5 Additional Security Objectives for the Environment........................................................................................28
4.3 Security Objective Rationale................................................................................................................................................28
5 Extended Components Definition...........................................................................................................................................30
6 Security Requirements.................................................................................................................................................................. 31
6.1 Security Functional Requirements...................................................................................................................................31
6.1.1 Class FCS................................................................................................................................................................................. 32
6.1.2 Class FIA.................................................................................................................................................................................. 33
6.1.3 Class FDP................................................................................................................................................................................ 35
6.1.4 Class FTP................................................................................................................................................................................. 38
6.1.5 Class FAU................................................................................................................................................................................ 39
6.1.6 Class FMT............................................................................................................................................................................... 39
6.1.7 Class FPT................................................................................................................................................................................. 42
6.2 Security Assurance Requirements for the TOE...........................................................................................................43
6.3 Security Requirements Rationale......................................................................................................................................43
6.3.1 Security Functional Requirements Rationale.......................................................................................................43
6.3.2 Rationale for SFR’s Dependencies..............................................................................................................................44
6.3.3 Security Assurance Requirements Rationale.........................................................................................................44
6.3.4 Security Requirements – Internal Consistency....................................................................................................45
Glossary and Abbreviations......................................................................................................................................................... 47
Glossary.......................................................................................................................................................................................... 47
Abbreviations.............................................................................................................................................................................. 49
Reference Documentation........................................................................................................................................................... 51
Figures
Figure 1: Claims of this PP. A claim is represented by a directed arrow...............................................................................12
Figure 2: Overview of TOE and TSF...................................................................................................................................................... 12
Tables
Table 1: Overview of identifiers of this and claimed PPs...............................................................................................................5
Table 2: Security Objective Rationale...................................................................................................................................................29
Table 3: Overview of authentication and identification SFRs..................................................................................................33
Table 4: Coverage of Security Objectives for the TOE by SFRs.................................................................................................43
4 Bundesamt für Sicherheit in der Informationstechnik
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) PP Introduction 1
1 PP Introduction
This section provides document management and overview information required to register the protection
profile and to enable a potential user of the PP to determine, whether the PP is of interest.
1.1 PP Reference
Title: Common Criteria Protection Profile 'Machine-Readable Electronic Documents based on
BSI TR-03110 for Official Use [MR.ED-PP]'
Editor/Sponsor: Bundesamt für Sicherheit in der Informationstechnik (BSI)
CC Version: 3.1 (Revision 4)
Assurance Level: Minimum assurance level for this PP is EAL4 augmented.
General Status: final
Version Number: Version 1.01 as of May 20th, 2015
Registration: BSI-CC-PP-0087
Keywords: ICAO, PACE, EAC, Extended Access Control, ID-Card, electronic document, smart card,
TR-03110
1.2 TOE Overview
This PP claims strict conformance to [PACEPP], [EAC1PP] and [EAC2PP]. There, slightly different
terminology is used. For the ease of understanding, Table 1 gives a brief translation for the used terminology.
Compound words that contain terminology of the table should be replaced accordingly.
This PP PACE PP EAC1PP EAC2PP
electronic document travel document travel document electronic document
electronic document
presenter
traveler traveller electronic document
presenter
EAC1 protected data - sensitive (user) data -
EAC2 protected data - - sensitive user data
common user data user data user data common user data
PACE terminal BIS-PACE BIS-PACE PACE terminal
EAC1 terminal - Extended Inspection System -
EAC2 terminal - - EAC2 terminal
Table 1: Overview of identifiers of this and claimed PPs.
1.2.1 TOE Definition and Operational Usage
The Target of Evaluation (TOE) is a smartcard programmed according to [TR03110-1] and [TR03110-2]. The
smartcard contains multiple applications (at least one). The programmed smartcard is called an electronic
Federal Office for Information Security 5
5
10
15
1 PP Introduction BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
document as a whole. Here, an application is a collection of data(groups) and their access conditions. We
mainly distinguish between common user data, and sensitive user-data. Depending on the protection
mechanisms involved, these user data can further be distinguished as follows:
1. EAC1-protected data: Sensitive user data protected by EAC1 (cf. [TR03110-1]),
2. EAC2-protected data: Sensitive user data protected by EAC2 (cf. [TR03110-2]), and
3. all other (common) user data. Other user data are protected by Password Authenticated Connection
Establishment (PACE, cf. also [TR03110-2]). Note that EAC1 recommends, and EAC2 requires prior
execution of PACE.
Application Note 1: Due to migration periods, some developers have to implement products that function-
ally support both PACE and Basic Access Control (BAC), i.e. Supplemental Access Control (SAC) [ICAO9303].
However, any product using BAC is not conformant to the current PP; i.e. the TOE may functionally support
BAC, but, while performing BAC, it is acting outside of the security policy defined by the current PP.
In addition to the above user data, there are also data required for TOE security functionality (TSF). Such data
is needed to execute the access control protocols, to verify integrity and authenticity of user data, or to
generate cryptographic signatures.
Applications considered in [TR03110-1] and [TR03110-2] are
1. an electronic passport (ePass) application,
2. an electronic identity (eID) application, and
3. a signature (eSign) application.
This protection profile however does not make any assumptions on what kind of applications, and how
many applications are included. Chapter 1.3 provides guidance on how this protection profile is intended to
be used for product development and certification, and Chapter 1.2.6 gives recommendations for a TOE
design w.r.t. applications and data groups.
The combination of different applications for a product corresponds to loading different data into the
EEPROM or flash memory of a smart card. Such a configuration of data groups yields a specific electronic
document.
Applications, that is configurations of data groups, are loaded during manufacturing. Requirements on the
loader are adapted from the CC-Package: Package 1: Loader dedicated for usage in secured environment only
from [ICPP]. If needed, additional requirements should be defined by the ST-writer.
As mentioned, access to common and sensitive user data is protected by PACE, EAC1, and/or EAC2 (see
below). Thus the electronic document holder can control access to her user data either by consciously
presenting her electronic document, and/or by consciously entering a secret personal identification number
(PIN).
A data group should be defined by the ST-Writer as either sensitive user data protected by EAC1, sensitive
user data protected by EAC2, or common user data. Obviously, if a data group is for example defined as
sensitive user data protected by EAC1, but is at the same time defined as common user data and thus
accessible by just PACE alone, this defeats the whole purpose of protecting it with the advanced security
mechanism EAC1 in the first place. However, to ensure compatibility with standards set by the International
Civil Aviation Organization (ICAO) for electronic passports, exceptions are acceptable for certain
applications. See also Chapter 1.2.6 for details.
The TOE shall comprise at least
1. the circuitry of the chip, including all integrated circuit (IC) dedicated software that is active in the
operational phase of the TOE,
2. the IC embedded software, i.e. the operating system,
3. all access mechanisms, associated protocols and corresponding data,
6 Federal Office for Information Security
20
25
30
35
40
45
50
55
60
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) PP Introduction 1
4. one or several applications, and
5. the associated guidance documentation.
Application Note 2: Since contactless interface parts (e.g. the antenna) may impact specific aspects of vulnera-
bility assessment and are thus relevant for security, such parts might be considered as a part of the TOE.
The decision upon this is up to the certification body in charge that defines the evaluation methodology
for the assessment of the contactless interface.
1.2.2 TOE major Security Features for Operational Use
The following TOE security features are the most significant for its operational use: The TOE ensures that
• only authenticated terminals can get access to the user data stored on the TOE and use security
functionality of the electronic document according to the access rights of the terminal,
• the electronic document holder can control access by consciously presenting his electronic document
and/or by entering his secret PIN,
• authenticity and integrity of user data can be verified,
• confidentiality of user data in the communication channel between the TOE and the connected
terminal is provided,
• inconspicuous tracing of the electronic document is averted,
• its security functionality and the data stored inside are self-protected, and
• digital signatures can be created, if the TOE contains an eSign application.
1.2.3 TOE Type
The TOE type addressed by the current protection profile is a smartcard programmed according to
[TR03110-1] and [TR03110-2]. The smartcard contains multiple applications (at least one). The programmed
smartcard is called an electronic document as a whole.
Justification: TOE type definitions of the claimed PPs ([EAC1PP], [EAC2PP], [SSCDPP]) differ slightly. We
argue that these differences do not violate consistency:
The TOE type defined both in [EAC1PP] and [EAC2PP] is a smartcard. Whereas [EAC1PP] references
[TR03110-1] (and also [ICAO9303] and related ICAO specifications, however [TR03110-1] is fully compatible
with those ICAO specifications, and they are mostly listed there for the sake of completeness and the context
of use) w.r.t. programming of the card, [TR03110-2] is given as a reference in [EAC2PP]. Reference
[TR03110-1] defines the EAC1 protocol, whereas EAC2 is defined in [TR03110-2]. Thus this difference in
reference is introduced just due to different applications on the card, that do not contradict each other. The
term 'travel document' of [EAC1PP] is here understood in a more broader sense (cf. also Table 1), since the
document can also be used in contexts other than just traveling.
The TOE type definition given in [SSCDPP] is “a combination of hardware and software configured to securely
create, use and manage signature-creation data (SCD)”. The definition of hardware and software in this PP is
more specific by explicitly mentioning a smartcard and the software on the card. However the very
fundamental purpose of a smartcard is to store data on it in a protected way. Hence, the TOE type definition
of this PP is also not inconsistent with the one of [SSCDPP].
The typical life cycle phases for the current TOE type are development, manufacturing, card issuing and
operational use. The life cycle phase development includes development of the IC itself and IC embedded
software. Manufacturing includes IC manufacturing and smart card manufacturing, and installation of a
Federal Office for Information Security 7
65
70
75
80
85
90
95
100
1 PP Introduction BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
card operating system. Card issuing includes installation of the smart card applications and their electronic
personalization, i. e. tying the application data up to the electronic document holder.
Operational use of the TOE is explicitly in the focus of current PP. Nevertheless, some TOE functionality
might not be directly accessible to the end-user during operational use. Some single properties of the
manufacturing and the card issuing life cycle phases that are significant for the security of the TOE in its
operational phase are also considered by the current PP. Conformance with this PP requires that all life cycle
phases are considered to the extent that is required by the assurance package chosen here for the TOE; c.f.
also Chapter 6.2.
1.2.4 TOE Life Cycle
The TOE life cycle is described in terms of the above mentioned four life cycle phases. Akin to [ICPP], the
TOE life-cycle is additionally subdivided into seven steps.
Phase 1: Development
Step 1
The TOE is developed in phase 1. The IC developer develops the integrated circuit, the IC dedicated software
and the guidance documentation associated with these TOE components.
Step 2
The software developer uses the guidance documentation for the integrated circuit and the guidance
documentation for relevant parts of the IC dedicated software, and develops the IC embedded software
(operating system), the electronic document application(s) and the guidance documentation associated with
these TOE components.
The manufacturing documentation of the IC including the IC dedicated software and the embedded
software in the non-volatile non-programmable memories is securely delivered to the IC manufacturer. The
IC embedded software in the non-volatile programmable memories, the application(s), and the guidance
documentation is securely delivered to the electronic document manufacturer.
Phase 2: Manufacturing
Step 3
In a first step, the TOE integrated circuit is produced. The circuit contains the electronic document's chip
dedicated software, and the parts of the electronic document's chip embedded software in the non-volatile
non-programmable memory (ROM). The IC manufacturer writes IC identification data onto the chip in
order to track and control the IC as dedicated electronic document material during IC manufacturing, and
during delivery to the electronic document manufacturer. The IC is securely delivered from the IC
manufacturer to the electronic document manufacturer. If necessary, the IC manufacturer adds parts of the
IC embedded software in the non-volatile programmable memory, e. g. EEPROM.
Step 4 (optional)
If the electronic document manufacturer delivers a packaged component, the IC is combined with hardware
for the contact based or contactless interface.
Step 5
The electronic document manufacturer
1. if necessary, adds the IC embedded software, or parts of it in the non-volatile programmable
memories, e. g. EEPROM or FLASH,
2. creates the application(s), and
3. equips the electronic document's chip with pre-personalization data.
8 Federal Office for Information Security
105
110
115
120
125
130
135
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) PP Introduction 1
Creation of the application(s) implies the creation of the master file (MF), dedicated files (DFs), and
elementary files (EFs) according to [ISO7816-4]. How this process is handled internally depends on the IC and
IC embedded software.
The pre-personalized electronic document together with the IC identifier is securely delivered from the
electronic document manufacturer to the personalization agent. The electronic document manufacturer
also provides the relevant parts of the guidance documentation to the personalization agent.
Phase 3: Personalization of the Electronic Document
Step 6
The personalization of the electronic document includes
1. the survey of the electronic document holder’s biographical data,
2. the enrollment of the electronic document holder's biometric reference data, such as a digitized
portrait or other biometric reference data,
3. printing the visual readable data onto the physical part of the electronic document, and
4. configuration of the TSF, if necessary.
Configuration of the TSF is performed by the personalization agent and includes, but is not limited to, the
creation of the digitized version of the textual, printed data, the digitized version of e.g. a portrait, or a
cryptographic signature of a cryptographic hash of the data that are stored on the chip. The personalized
electronic document, if required together with appropriate guidance for TOE use, is handed over to the
electronic document holder for operational use.
Application Note 3: TSF data are data for the operation of the TOE upon which the enforcement of the SFRs
relies [CC1]. Here TSF data include, but are not limited to, the personalization agent's authentication
key(s).
Phase 4: Operational Use
Step 7
The chip of the TOE is used by the electronic document and terminals that verify the chip's data during the
phase operational use. The user data can be read and modified according to the security policy of the issuer.
Application Note 4: This PP considers at least the first phase and parts of the second phase, i.e. Step 1 up to
Step 3, as part of the evaluation. Therefore the TOE delivery is defined to occur, according to CC, after
Step 3. Since specific production steps of the second phase are of minor security relevance (e.g. plastic
card or booklet manufacturing and antenna integration) these are not part of the CC evaluation under
ALC. Nevertheless the decision about this has to be taken by the certification body resp. the national
body of the issuer or organization. In this case the national body of the issuer is responsible for these
specific production steps.
Note that the personalization process and its environment may depend on specific security needs of the
issuer. All production, generation and installation procedures after TOE delivery up to the phase opera-
tional use have to be considered in the product evaluation process under assurance class AGD. Therefore,
the security target has to outline how to split up P.Manufact, P.Personalisation and related security ob-
jectives into aspects relevant before vs. those relevant after TOE delivery.
Some production steps, e. g. Step 4 in Phase 2 may also take place in the Phase 3.
1.2.5 Non-TOE Hardware/Software/Firmware
In order to be powered up and to communicate with the external world, the TOE needs a terminal (card
reader) supporting the communication according to [ISO7816-4] and [ISO14443]; the latter only if the card
Federal Office for Information Security 9
140
145
150
155
160
165
170
1 PP Introduction BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
has a contactless interface. Akin to [TR03110-1] and [TR03110-2] the TOE shall be able to recognize the
following terminal types:
– PACE terminal. A PACE terminal is a basic inspection system according to [TR03110-1], [TR03110-2]
resp. It performs the standard inspection procedure, i.e PACE followed by Passive Authentication,
cf. [TR03110-1]. Afterwards user data are read by the terminal. A PACE terminal is allowed to read only
common user data.
– EAC1 terminal. An EAC1 terminal is an extended inspection system according to [TR03110-1]. It
performs the advanced inspection procedure ([TR03110-1]) using EAC1, i.e. PACE, then Chip
Authentication 1 followed by Passive Authentication, and finally Terminal Authentication 1.
Afterwards user data are read by the terminal. An EAC1 terminal is allowed to read both EAC1
protected data, and common user data.
– EAC2 terminal. An EAC2 terminal is an extended inspection system performing the general
authentication procedure according to [TR03110-2] using EAC2, i.e. PACE, then Terminal
Authentication 2 followed by Passive Authentication, and finally Chip Authentication 2. Depending on
its authorization level, an EAC2 terminal is allowed to read out some or all EAC2 protected sensitive
user data, and common user data.
In general, the authorization level of a terminal is determined by the effective terminal authorization. The
authorization is calculated from the certificate chain presented by the terminal to the TOE. It is based on the
Certificate Holder Authorization Template (CHAT). A CHAT is calculated as an AND-operation from the
certificate chain of the terminal and the electronic document presenter's restricting input at the terminal.
The final CHAT reflects the effective authorization level and is then sent to the TOE [TR03110-3]. For the
access rights, cf. also the SFR component FDP_ACF.1/TRM in Chapter 6.1.3.
All necessary certificates of the related public key infrastructure – Country Verifying Certification Authority
(CVCA) Link Certificates, Document Verifiers Certificates and Terminal Certificates – must be available in the
card verifiable format defined in [TR03110-3].
The term terminal within this PP usually refers to any kind of terminal, if not explicitly mentioned
otherwise. If this PP is claimed for a security target, the ST-Writer shall give an overview of which of the
above terminals are related to what application, and which data group is accessible. Chapter 1.2.6 must be
taken into account.
Other terminals than the above are out of scope of this PP. In particular, terminals using Basic Access
Control (BAC) may be functionally supported by the electronic document, but if the TOE is operated using
BAC, it is not in a certified mode.
1.2.6 Recommended TOE Design
The electronic document may contain one of the following combinations of applications and protocols:
• ePassport-only: user data stored in an ICAO-compliant ePass application protected by PACE and EAC1.
Here, EAC1 is used only for data groups 3 and 4.
• eResidence permit combination: user data stored in an ICAO-compliant ePass application protected by
PACE and EAC1/EAC2. Additional user data are stored in [TR03110-2] conformant eID and eSign
applications, and are protected by EAC2.
• electronic document combination: user data contained in [TR03110-2]-conformant ePass, eID, and
eSign applications. All user data are protected by PACE/EAC2.
The purpose and usage of the above mentioned different applications is as follows:
10 Federal Office for Information Security
175
180
185
190
195
200
205
210
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) PP Introduction 1
• An ePassport application, as defined in [ICAO9303], is intended to be used by authorities as a machine
readable travel document (MRTD). For the ePassport application, the electronic document holder can
control access to his user data by consciously presenting his electronic document to authorities1
.
• An eID application, as defined in [TR03110-2], including related user data and data needed for
authentication, is intended to be used for accessing official and commercial services which require
access to user data stored in the application. For an eID application, the electronic document holder
can control access to his user data by inputting his secret PIN (eID-PIN) or by consciously presenting
his electronic document to authorities2
;
• An eSign application, as defined in [TR03110-2], is intended to generate qualified electronic
signatures. The main specific property distinguishing qualified electronic signatures from other, i.e.
advanced electronic signatures, is that they are based on qualified certificates and created by secure
signature creation devices (SSCD). An eSign application, if implemented, can optionally be activated on
the electronic document by a Certification Service Provider, or on his behalf. For an eSign application,
the electronic document holder can control access to the digital signature functionality by consciously
presenting his electronic document to an EAC2 terminal and inputting his secret PIN (eSign-PIN) for
this application3
.
Each application contains its own set of user data, composed according to its requirements.
Application note 5: While it is technically possible to grant access to the electronic signature functionality by
inputting only the CAN (see [TR03110-2]), this technical option shall not be allowed by the security pol-
icy defined for the eSign application; see the related conformance claim in section 2.2. This is due to the
fact that solely the signatory – which is here the electronic document holder – shall be able to generate
an electronic signature on his own behalf.
Application note 6: Requiring the document holder to use a separate eSign-PIN to generate qualified signa-
tures represents a manifestation of his declaration of intent bound to this secret PIN. In order to reflect
this fact, it should be considered to provide the eID and the eSign applications with organizationally
different values of the respective secret PINs (eID-PIN and eSign-PIN). This is especially important, if the
eSign application is intended to generate qualified electronic signatures.
1.3 Guidance for using this Protection Profile
1.3.1 Motivation
Electronic document manufacturers often create multiple documents for different purposes. Examples are
electronic identity cards, electronic passports, or electronic residence permits. If one protection profile for
each electronic document exists, several evaluations are required. Due to that, one chip that has been
certified to be used for example for an electronic residence permit, cannot be used for an electronic passport.
This is even though the security and functional mechanisms in an electronic residence permit card are a
superset of those in an electronic passport. This protection profile intends to address that problem. It is on
top of a hierarchy of claimed protection profiles, and thus all potentially required security functionality and
mechanisms are included.
1 CAN or MRZ user authentication, see [TR03110-1]
2 eID-PIN or CAN user authentication, see [TR03110-2]
3 CAN and eSign-PIN user authentication, see [TR03110-2]
Federal Office for Information Security 11
215
220
225
230
235
240
245
1 PP Introduction BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
1.3.2 Usage
The intended usage is that the manufacturer during the development phase and/or at the beginning of the
manufacturing phase (Step 3) develops an IC-chip with integrated software that includes all security
functionality and mechanisms described within this PP. However prior to personalization (i.e. Step 5 during
manufacturing), only those applications (datagroups) required for the intended final document and their
access rights are created. Creation of the applications (i.e. the ISO7816-4 conforming file structure) including
datagroups and their access rights) is subject to a limited availability and limited capability policy defined in
the family FMT_LIM. In particular, the loader must ensure that creation or alteration of the filesystem is not
possible after the manufacturing phase (this excludes populating datagroups with values, as is done in the
personalization phase). In summary, this allows manufacturers to use a single IC for all kinds of electronic
documents.
12 Federal Office for Information Security
Figure 1: Claims of this PP. A claim is represented by a directed arrow.
EAC1-PP
THIS PP
PACE-PP
SSCD-PP
EAC2-PP
Protocols
Figure 2: Overview of TOE and TSF
250
255
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) PP Introduction 1
1.3.3 TOE Functionality versus TSF
An abstract description of the TOE is depicted in Figure 2. The TOE's main components are the card
operating system (either a native OS, or in the case of JavaCard a combination of OS and applet), and the
file-system. Note that file-system denotes here an abstract structure conformant to [ISO7816-4] to store
datagroups, and the internal implementation of the file-system on the TOE can be completely different.
The TOE provides certain security functionality (TSF). This security functionality consists here mainly of
algorithms and protocols that control access to, generation of, and modification of data stored in the
file-system. Common Criteria [CC1] defines TSF as
combined functionality of all hardware, software, and firmware of a TOE that must be relied upon
for the correct enforcement of the SFRs.
From this definition it is clear, that only those combined functionality of the TOE that is related to the
enforcement of the SFRs is the TSF, but that the TSF does not correspond to the TOE's functionality in
general. The TOE as a whole usually also provides functionality to (end-)users. To provide this functionality,
the TOE often makes use of it's security functionality. As an example, the TSF might functionally provide an
algorithm that employs random numbers to the user. To ensure correctness and security of this algorithm,
the TSF might have methods for self-protection, or internal tests to ensure that random numbers are
generated w.r.t. a certain metric. Such TSF is usually not directly accessible and does not belong to the TOE's
general functionality provided to users. Therefore, the TOE's security functionality and the TOE's
functionality in general need not to always coincide and must be viewed as separate. SFRs within this PP
define requirements on the TSF, but usually not on the TOE's functionality in general. This fact is important
to note for using this PP and for evaluation.
1.3.4 Security Targets, Strict Conformance, and Evaluation
The intended use of this PP is as follows:
Step 1:
In a first step, one security target should be written that claims strict conformance to this protection profile.
Since all SFRs within this protection profile are then included in that security target and thus are subject to
evaluation, and since the filesystem is part of the TOE, a filesystem with applications, i.e. (test) datagroups,
has to be created. This allows thorough evaluation w.r.t. this protection profile including all SFRs; this in
particular includes all access control mechanisms and cryptographic functions.
Step 2:
Such a TOE however will likely not coincide with a finished product as intended for end-users. Each such
product will have a different filesystem. In a second step, for each such product a separate security target
should be created. Such a security target should claim strict conformance to this protection profile, and, in
addition precisely define the respective filesystem.
Each of these security targets is subject to evaluation. Note that these security targets' only difference to the
one of Step 1 is the filesystem: Depending on the product, the filesystem may not contain all applications, i.e.
not all files compared to the TOE of Step 1. However whereas not all datagroups will be present, in order to
achieve strict conformity with this protection profile, all mechanisms, i.e. TSF such as access controls, and
cryptographic operations described in the SFRs of this PP must be implemented in the TOE and available in
the CardOS.
Concerning the evaluation, on a superficial level this looks like a duplication of work, as for each product yet
another evaluation w.r.t. each of these security targets has to be conducted. In order to assess the fulfillment
of all SFRs however, evaluation results of Step 1 should be reused to the highest extend possible to assess
conformity. This in particular includes assessing conformity to those SFRs that require for evaluation the
presence of certain datagroups that might not be present in the respective filesystem for the given product.
Federal Office for Information Security 13
265
270
275
280
285
290
295
1 PP Introduction BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
Conformity w.r.t. those SFRs is still given, since the mechanisms are still available and implemented; it is only
the lack of corresponding files that potentially creates a hurdle during evaluation, and this is addressed by
applying the evaluation results of Step 1.
Some SFRs explicitly require the TSF to provide certain functionality. Formulations usually include “The TSF
shall allow...”, “The TSF shall be capable...”., or “The TSF shall provide...”. This is to be understood in the sense
that, as mentioned above, the TOE provides these TSF, and these TSF are subject to evaluation, but whether
they are accessible as general functionality in the life cycle after personalization, i.e. to (end) users, depends
on the filesystem. For example for a TOE where no EAC1-protected data are stored and thus no application is
present, the EAC1 protocol might not be accessible to end-users, since the file-system does not include any
CA1 keys. This is even though the TOE is technically capable of performing EAC1, i.e. the functionality is
present in the chip OS.
Affected SFRs in particular include those from the families FIA and FMT.
Note that this is in no contradiction to strict conformance to this protection profile, since not only is the
evaluated TSF still included in the TSF, but also limiting outside access to functionality that allows to gather
user data does never decrease security.
14 Federal Office for Information Security
300
305
310
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Conformance Claims 2
2 Conformance Claims
2.1 CC Conformance Claim
This protection profile claims conformance to
• Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general
model; CCMB-2012-09-001, Version 3.1, Revision 4, September 2012, [CC1]
• Common Criteria for Information Technology Security Evaluation, Part 2: Security functional
components; CCMB-2012-09-002, Version 3.1, Revision 4, September 2012, [CC2]
• Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance
components; CCMB-2012-09-003, Version 3.1, Revision 4, September 2012, [CC3]
as follows
Part 2 extended,
Part 3 conformant.
The
• Common Methodology for Information Technology Security Evaluation, Evaluation methodology;
CCMB-2012-09-004, Version 3.1, Revision 4, September 2012, [CC4]
has to be taken into account.
2.2 PP Claim
This PP claims strict conformance to
• Common Criteria Protection Profiles for Secure Signature Creation Device – Part 2: Device with key
generation, prEN 14169-2:2012 ver. 2.01, 2012-01, BSI-CC-PP-0059-2009-MA-01, [SSCDPP]
Application note 7: This conformance claim covers the part of the security policy for the eSign
application of the TOE corresponding to the security policy defined in [SSCDPP], and hence is
applicable, if the eSign application is operational. In addition to [SSCDPP], the current PP specifies
authentication and communication protocols (at least PACE) that have to be used for the eSign
application of the TOE. These protocols contribute to secure Signature Verification Data (SVD) export,
Data To Be Signed (DTBS) import, and Verification Authentication Data (VAD) import functionality.
• Common Criteria Protection Profile — Machine Readable Travel Document with “ICAO Application”,
Extended Access Control with PACE (EAC PP), BSI-CC-PP-0056-V2-2012-MA-02, [EAC1PP]
• Common Criteria Protection Profile — Electronic document implementing Extended Access Control
Version 2 (EAC2) based on BSI TR-03110 (EAC2_PP), BSI-CC-PP-0086, [EAC2PP]
Since the last two above claim strict conformance to [PACEPP], this PP implicitly also claims strict
conformance to
• Common Criteria Protection Profile — Machine Readable Travel Document using Standard
Inspection Procedure with PACE, BSI-CC-PP-0068-V2-2011-MA-01, [PACEPP].
However since [EAC1PP] and [EAC2PP] already claim strict conformance to [PACEPP], this implicit
conformance claim is formally mostly ignored within this PP for the sake of presentation; but if
necessary to yield a better overview however, references to [PACEPP] are given or the relation with
[PACEPP] is explained.
Federal Office for Information Security 15
315
320
325
330
335
340
345
2 Conformance Claims BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
2.3 Package Claim
The current PP is conformant to the following packages:
1. Assurance package EAL4 augmented with ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5 as defined in [CC3].
2.4 Conformance Rationale
This PP conforms to the PPs [EAC1PP], [EAC2PP] and [SSCDPP].This implies for this PP:
1. The TOE type of this PP is the same4
as the TOE type of the claimed PPs: The Target of Evaluation (TOE) is
an electronic document implemented as a smart card programmed according to [TR03110-1]
and [TR03110-2], and additionally representing a combination of hardware and software configured to
securely create, use and manage signature-creation data , for the eSign application.
2. The security problem definition (SPD) of this PP contains the SPD of the claimed PPs. The SPD contains
all threats, organizational security policies and assumptions of the claimed PPs and identifies additional
threats T.InconsistentSec and T.Interfere.
3. The security objectives for the TOE in this PP include all the security objectives for the TOE of the
claimed PPs, and add the security objective OT.Non_Interfere. This objective does not weaken the security
objectives of the claimed PPs.
4. The security objectives for the operational environment in this PP include all security objectives for the
operational environment of the claimed PPs.
5. The SFRs specified in this PP include all security functional requirements (SFRs) specified in the claimed
PPs. We especially point to the following three refined SFRs within this PP:
The SFR FIA_UAU.1/SSCDPP is redefined from [SSCDPP] by additional assignments. Note that this does
not violate strict conformance to [SSCDPP].
Multiple iterations of FDP_ACF.1 and FMT_SMR.1 exist from imported PPs to define the access control
SFPs and security roles for (common) user data, EAC1-protected user data, and EAC2-protected user data.
These access control SFPs and security roles are unified to FDP_ACF.1/TRM and FMT_SMR.1.
6. The SARs specified in this PP are the same as specified in the claimed PPs or extend them.
2.5 Conformance Statement
This PP requires strict conformance of any ST or PP claiming conformance to it.
4 see also the justification in Chapter 1.2.3.
16 Federal Office for Information Security
350
355
360
365
370
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Problem Definition 3
3 Security Problem Definition
3.1 Introduction
3.1.1 Assets
3.1.1.1 Primary Assets
As long as they are in the scope of the TOE, the primary assets to be protected by the TOE are listed below.
For a definition of terms used, but not defined here, see the Glossary.
Authenticity of the Electronic Document’s Chip
The authenticity of the electronic document’s chip personalized by the issuing state or organization for the
electronic document holder, is used by the electronic document presenter to prove his possession of a
genuine electronic document.
Generic Security Property: Authenticity
This asset is equal to the one(s) of [EAC1PP] and [EAC2PP], which itself stem from [PACEPP].
Electronic Document Tracing Data
Technical information about the current and previous locations of the electronic document gathered
unnoticeable by the electronic document holder recognizing the TOE not knowing any PACE password. TOE
tracing data can be provided / gathered.
Generic Security Property: Unavailability
This asset is equal to the one(s) of [EAC1PP] and [EAC2PP], which itself stem from [PACEPP]. Note that
unavailability here is required for anonymity of the electronic document holder.
Sensitive User Data
User data, which have been classified as sensitive data by the electronic document issuer, e. g. sensitive
biometric data. Sensitive user data are a subset of all user data, and are protected by EAC1, EAC2, or both.
Generic Security Properties: Confidentiality, Integrity, Authenticity
User Data stored on the TOE
All data, with the exception of authentication data, that are stored in the context of the application(s) on the
electronic document. These data are allowed to be read out, used or modified either by a PACE terminal, or, in
the case of sensitive data, by an EAC1 terminal or an EAC2 terminal with appropriate authorization level.
Generic Security Properties: Confidentiality, Integrity, Authenticity
This asset is included from [EAC1PP], [EAC2PP] respectively. In these protection profiles it is an extension of
the asset defined in [PACEPP]. This asset also includes ”SVD” (Integrity and Authenticity only), “SCD” of
[SSCDPP].
User Data transferred between the TOE and the Terminal
All data, with the exception of authentication data, that are transferred (both directions) during usage of the
application(s) of the electronic document between the TOE and authenticated terminals.
Federal Office for Information Security 17
375
380
385
390
395
3 Security Problem Definition BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
Generic Security Properties: Confidentiality, Integrity, Authenticity
This asset is included from [EAC1PP], [EAC2PP] respectively. In these protection profiles it is an extension of
the asset defined in [PACEPP]. As for confidentiality, note that even though not each data element being
transferred represents a secret, [TR03110-1], [TR03110-2] resp. require confidentiality of all transferred data
by secure messaging in encrypt-then-authenticate mode. This asset also includes “DTBS” of [SSCDPP].
3.1.1.2 Secondary Assets
In order to achieve a sufficient protection of the primary assets listed above, the following secondary assets
also have to be protected by the TOE.
Accessibility to the TOE Functions and Data only for Authorized Subjects
Property of the TOE to restrict access to TSF and TSF-Data stored in the TOE to authorized subjects only.
Generic Security Property: Availability
Genuineness of the TOE
Property of the TOE to be authentic in order to provide claimed security functionality in a proper way.
Generic Security Property: Availability
Electronic Document Communication Establishment Authorization Data
Restricted-revealable authorization information for a human user being used for verification of the
authorization attempts as an authorized user (PACE password). These data are stored in the TOE, and are not
send to it.
Restricted-revealable here refers to the fact that if necessary, the electronic document holder may reveal her
verification values of CAN and MRZ to an authorized person, or to a device that acts according to respective
regulations and is considered trustworthy.
Generic Security Properties: Confidentiality, Integrity
Secret Electronic Document Holder Authentication Data
Secret authentication information for the electronic document holder being used for verification of the
authentication attempts as authorized electronic document holder (PACE passwords).
Generic Security Properties: Confidentiality, Integrity
TOE internal Non-Secret Cryptographic Material
Permanently or temporarily stored non-secret cryptographic (public) keys and other non-secret material
used by the TOE in order to enforce its security functionality.
Generic Security Properties: Integrity, Authenticity
TOE internal Secret Cryptographic Keys
Permanently or temporarily stored secret cryptographic material used by the TOE in order to enforce its
security functionality.
Generic Security Properties: Confidentiality, Integrity
Application Note 8: The above secondary assets represent TSF and TSF-Data in the sense of CC.
18 Federal Office for Information Security
400
405
410
415
420
425
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Problem Definition 3
3.1.2 Subjects
This protection profile considers the following external entities and subjects:
Attacker
A threat agent (a person or a process acting on his behalf) trying to undermine the security policy defined by
the current PP, especially to change properties of the assets that have to be maintained. The attacker is
assumed to possess at most high attack potential. Note that the attacker might capture any subject role
recognized by the TOE.
Country Signing Certification Authority (CSCA)
An organization enforcing the policy of the electronic document issuer, i. e. confirming correctness of user
and TSF data that are stored within the electronic document. The CSCA represents the country specific root
of the public key infrastructure (PKI) for the electronic document, and creates Document Signer Certificates
within this PKI. The CSCA also issues a self-signed CSCA certificate that has to be distributed to other
countries by secure diplomatic means, see [ICAO9303].
CountryVerifying Certification Authority (CVCA)
The Country Verifying Certification Authority (CVCA) enforces the privacy policy of the issuing state or
organization, i. e. enforcing protection of sensitive user data that are stored in the electronic document. The
CVCA represents the country specific root of the PKI of EAC1 terminals, EAC2 terminals respectively, and
creates Document Verifier Certificates within this PKI. Updates of the public key of the CVCA are distributed
as CVCA Link-Certificates.
Document Signer (DS)
An organization enforcing the policy of the CSCA. A DS signs the Document Security Object that is stored on
the electronic document for Passive Authentication. A Document Signer is authorized by the national CSCA
that issues Document Signer Certificate , see [ICAO9303]. Note that this role is usually delegated to a
Personalization Agent.
Document Verifier (DV)
An organization issuing terminal certificates as a Certificate Authority, authorized by the corresponding
CVCA to issue certificates for EAC1 terminals, EAC2 terminals respectively, see [TR03110-3].
Electronic Document Holder
A person the electronic document issuer has personalized the electronic document for. Personalization here
refers to associating a person uniquely with a specific electronic electronic document. This subject includes
“Signatory” as defined [SSCDPP].
Electronic Document Presenter
A person presenting the electronic document to a terminal and claiming the identity of the electronic
document holder. Note that an electronic document presenter can also be an attacker. Moreover, this subject
includes “user” as defined in [SSCDPP].
Manufacturer
Generic term comprising both the IC manufacturer that produces the integrated circuit, and the electronic
document manufacturer that creates the electronic document and attaches the IC to it. The manufacturer is
the default user of the TOE during the manufacturing life cycle phase. When referring to the role
manufacturer, the TOE itself does not distinguish between the IC manufacturer and the electronic
document manufacturer.
Federal Office for Information Security 19
430
435
440
445
450
455
3 Security Problem Definition BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
PACE Terminal
A technical system verifying correspondence between the password stored in the electronic document and
the related value presented to the terminal by the electronic document presenter. A PACE terminal
implements the terminal part of the PACE protocol and authenticates itself to the electronic document
using a shared password (CAN, eID-PIN, eID-PUK or MRZ). A PACE terminal is not allowed reading sensitive
user data.
Personalization Agent
An organization acting on behalf of the electronic document issuer that personalizes the electronic
document for the electronic document holder. Personalization includes some or all of the following
activities: (i) establishing the identity of the electronic document holder for the biographic data in the
electronic document, (ii) enrolling the biometric reference data of the electronic document holder, (iii)
writing a subset of these data on the physical electronic document (optical personalization) and storing
them within the electronic document's chip (electronic personalization), (iv) writing document meta data
(i. e. document type, issuing country, expiry date, etc.) (v) writing the initial TSF data, and (vi) signing the
Document Security Object, and the elementary files EF.CardSecurity and the EF.ChipSecurity (if applicable
[ICAO9303], [TR03110-3]) in the role DS. Note that the role personalization agent may be distributed among
several institutions according to the operational policy of the electronic document issuer. This subject
includes “Administrator” as defined in [SSCDPP].
EAC1 Terminal / EAC2 Terminal
A terminal that has successfully passed the Terminal Authentication protocol (TA) version 1 is an EAC1
terminal, while an EAC2 terminal needs to have successfully passed TA version 2. Both are authorized by the
electronic document issuer through the Document Verifier of the receiving branch (by issuing terminal
certificates) to access a subset or all of the data stored on the electronic document.
Terminal
A terminal is any technical system communicating with the TOE through the contactless or contact-based
interface. The role terminal is the default role for any terminal being recognized by the TOE as neither being
authenticated as a PACE terminal nor an EAC1 terminal nor an EAC2 terminal.
3.2 Threats
This section describes the threats to be averted by the TOE independently or in collaboration with its IT
environment. These threats result from the assets protected by the TOE and the method of the TOE's use in
the operational environment.
T.InconsistentSec Inconsistency of security measures
Adverse action: An attacker gains read or write access to user data or TOE data without being allowed to, due
to an ambiguous/unintended configuration of the TOE's internal access conditions of user
or TSF data. This may lead to a forged electronic document or misuse of user data.
Threat agent: having high attack potential, being in possession of one or more legitimate electronic
documents
Asset: authenticity, integrity and confidentiality of user data stored on the TOE
T.Interfere Interference of security protocols
Adverse action: An attacker uses an unintended interference of implemented security protocols to gain
access to user data.
20 Federal Office for Information Security
460
465
470
475
480
485
490
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Problem Definition 3
Threat agent: having high attack potential, being in possession of one or more legitimate electronic
documents
Asset: authenticity, integrity and confidentiality of user data stored on the TOE
3.2.1 Threats from [EAC1PP]
This PP includes the following threats from [EAC1PP]. They concern EAC1-protected data.
• T.Counterfeit
• T.Read_Sensitive_Data
Due to identical definitions and names they are not repeated here. For the remaining threats from [EAC1PP],
cf. Chapter 3.2.3.
3.2.2 Threats from [EAC2PP]
This PP includes the following threats from the [EAC2PP]. They concern EAC2-protected data.
• T.Counterfeit/EAC2
• T.Sensitive_Data
Due to identical definitions and names, they are not repeated here.
3.2.3 Threats from [PACEPP]
Both [EAC1PP] and [EAC2PP] claim [PACEPP], and thus include the threats formulated in [PACEPP]. We list
each threat only once here. Due to identical definitions and names, their definitions are not repeated here.
• T.Abuse-Func
• T.Eavesdropping
• T.Forgery
• T.Information_Leakage
• T.Malfunction
• T.Phys-Tamper
• T.Skimming
• T.Tracing
3.2.4 Threats from [SSCDPP]
The current PP also includes all threats of [SSCDPP]. These items are applicable if the eSign application is
operational.
• T.DTBS_Forgery
• T.Hack_Phys
• T.SCD_Derive
• T.SCD_Divulge
Federal Office for Information Security 21
495
500
505
510
515
3 Security Problem Definition BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
• T.Sig_Forgery
• T.SigF_Misuse
• T.SVD_Forgery
Due to identical definitions and names, their definitions are not repeated here.
3.3 Organizational Security Policies
The TOE shall comply with the following Organizational Security Policies (OSP) as security rules, procedures,
practices, or guidelines imposed by an organization upon its operations (see CC part 1, sec. 3.2). This PP
includes the OSPs from the claimed protection profiles as listed below and provides no further OSPs.
3.3.1 OSPs from [EAC1PP]
This PP includes the following OSPs from [EAC1PP], if the TOE contains EAC1-protected data.
• P.Personalisation
• P.Sensitive_Data
Due to identical definitions and names, they are not repeated here. For the remaining OSPs from [EAC1PP],
see the next sections.
3.3.2 OSPs from [EAC2PP]
This PP includes the following OSPs from [EAC2PP]. They mainly concern EAC2-protected data.
• P.EAC2_Terminal
• P.RestrictedIdentity
• P.Terminal_PKI
Due to identical definitions and names, their definitions are not repeated here. For the remaining OSPs
from [EAC2PP], cf. the next section.
3.3.3 OSPs from [PACEPP]
This PP includes the following OSPs from [PACEPP], since both [EAC1PP] and [EAC2PP] claim [PACEPP]. We
list each OSP only once here. Due to identical definitions and names, their definitions are not repeated here
as well.
• P.Card_PKI
• P.Manufact
• P.Pre-Operational
• P.Terminal
• P.Trustworthy_PKI
3.3.4 OSPs from [SSCDPP]
The current PP also includes all OSPs of [SSCDPP]. They are applicable, if the eSign application is included.
22 Federal Office for Information Security
520
525
530
535
540
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Problem Definition 3
• P.CSP_QCert
• P.QSign
• P.Sig_Non-Repud
• P.Sigy_SSCD
Due to identical definitions and names, their definitions are not repeated here.
3.3.5 Additional OSPs
The next OSP addresses the need of a policy for the document manufacturer. It is formulated akin to [ICPP].
P.Lim_Block_Loader
The composite manufacturer uses the Loader for loading of Security IC Embedded Software, user data of the
Composite Product or IC Dedicated Support Software in charge of the IC Manufacturer. She limits the
capability and blocks the availability of the Loader in order to protect stored data from disclosure and
manipulation.
3.4 Assumptions
The assumptions describe the security aspects of the environment in which the TOE will be used or is
intended to be used. This PP includes the assumptions from the claimed protection profiles as listed below
and defines no further assumptions.
3.4.1 Assumptions from [EAC1PP]
This PP includes the following assumptions from the [EAC1PP]. They concern EAC1-protected data.
• A.Auth_PKI
• A.Insp_Sys
Due to identical definitions and names, their definitions are not repeated here. For the remaining
assumptions from [EAC1PP], see the next sections.
3.4.2 Assumptions from [EAC2PP]
[EAC2PP] only includes the assumption from [PACEPP] (see below) and defines no other assumption.
3.4.3 Assumptions from [PACEPP]
This PP includes the following assumptions from [PACEPP], since both [EAC1PP] and [EAC2PP]
claim [PACEPP].
• A.Passive_Auth
Due to an identical definition and name, its definition is not repeated here as well.
Federal Office for Information Security 23
545
550
555
560
3 Security Problem Definition BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
3.4.4 Assumptions from [SSCDPP]
The current PP also includes all assumptions of [SSCDPP]. These items are applicable, if the eSign application
is included.
• A.CGA
• A.SCA
Due to identical definitions and names their definitions are not repeated here.
24 Federal Office for Information Security
565
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Objectives 4
4 Security Objectives
This chapter describes the security objectives for the TOE and for the TOE environment. The security
objectives for the TOE environment are separated into security objectives for the development, and
production environment and security objectives for the operational environment.
4.1 Security Objectives for the TOE
This section describes the security objectives for the TOE, addressing the aspects of identified threats to be
countered by the TOE, and organizational security policies to be met by the TOE.
OT.Non_Interfere No interference of Access Control Mechanisms
The various implemented access control mechanisms must be consistent. Their implementation must not
allow to circumvent an access control mechanism by exploiting an unintended implementational
interference of one access control mechanism with another one.
4.1.1 Security Objectives for the TOE from [EAC1PP]
This PP includes the following additional security objectives for the TOE from [EAC1PP] that are not
included in [PACEPP]. They concern EAC1-protected data.
• OT.Chip_Auth_Proof
• OT.Sens_Data_Conf
Due to identical definitions and names, their definitions are not repeated here. For the remaining security
objectives from [EAC1PP], see the next sections.
4.1.2 Security Objectives for the TOE from [EAC2PP]
This PP includes the following additional security objectives for the TOE from [EAC2PP] that are not
included in [PACEPP]. They concern EAC2-protected data.
• OT.AC_Pers_EAC2
• OT.CA2
• OT.RI_EAC2
• OT.Sens_Data_EAC2
Due to identical definitions and names, their definitions are not repeated here. For the remaining security
objectives from [EAC2PP], see the next sections.
4.1.3 Security Objectives for the TOE from [PACEPP]
Both [EAC1PP] and [EAC2PP] claim [PACEPP]. Therefore the following security objectives are included as
well. We list them only once here.
• OT.AC_Pers
• OT.Data_Authenticity
• OT.Data_Confidentiality
• OT.Data_Integrity
Federal Office for Information Security 25
570
575
580
585
590
4 Security Objectives BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
• OT.Identification
• OT.Prot_Abuse-Func
• OT.Prot_Inf_Leak
• OT.Prot_Malfunction
• OT.Prot_Phys-Tamper
• OT.Tracing
Due to identical definitions and names, their definitions are not repeated here.
4.1.4 Security objectives for the TOE from [SSCDPP]
The current PP also includes all security objectives for the TOE of [SSCDPP]. These items are applicable, if an
eSign application is included.
• OT.DTBS_Integrity_TOE
• OT.EMSEC_Design
• OT.Lifecycle_Security
• OT.SCD_Secrecy
• OT.SCD_SVD_Corresp
• OT.SCD_Unique
• OT.SCD/SVD_Gen
• OT.Sig_Secure
• OT.Sigy_SigF
• OT.Tamper_ID
• OT.Tamper_Resistance
Due to identical definitions and names, their definitions are not repeated here as well. Note that all are
formally included here, but careful analysis reveals that OT.SCD_Secrecy, OT.DTBS_Integrity_TOE,
OT.EMSEC_Design, OT.Tamper_ID, and OT.Tamper_Resistance are actually fully or partly covered by security
objectives included from [PACEPP].
4.1.5 Additional Security Objectives for the TOE
A loader is a part of the chip operating system that allows to load data, i.e. the file-system/applet containing
(sensitive) user data, TSF data etc. into the Flash or EEPROM memory after delivery of the smartcard to the
document manufacturer.
The following objective for the TOE addresses limiting the availability of the loader, and is formulated akin
to [ICPP].
OT.Cap_Avail_Loader
The TSF provides limited capability of the Loader functionality of the TOE embedded software and
irreversible termination of the Loader in order to protect user data from disclosure and manipulation.
26 Federal Office for Information Security
595
600
605
610
615
620
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Objectives 4
4.2 Security Objectives for the Operational Environment
4.2.1 Security objectives from [EAC1PP]
This PP includes the following security objectives for the TOE from the [EAC1PP]. They mainly concern
EAC1-protected data.
• OE.Auth_Key_Travel_Document
• OE.Authoriz_Sens_Data
• OE.Exam_Travel_Document
• OE.Ext_Insp_Systems
• OE.Prot_Logical_Travel_Document
Due to identical definitions and names, their definitions are not repeated here. For the remaining ones, see
the next sections.
4.2.2 Security Objectives from [EAC2PP]
This PP includes the following security objectives for the TOE from the [EAC2PP]. They mainly concern
EAC2-protected data.
• OE.Chip_Auth_Key
• OE.RestrictedIdentity
• OE.Terminal_Authentication
Due to identical definitions and names, their definitions are not repeated here. For the remaining ones, see
the next section.
4.2.3 Security Objectives from [PACEPP]
Both [EAC1PP] and [EAC2PP] claim [PACEPP]. Therefore the following security objectives on the operational
environment are included as well. We repeat them only once here.
• OE.Legislative_Compliance
• OE.Passive_Auth_Sign
• OE.Personalisation
• OE.Terminal
• OE.Travel_Document_Holder
Due to identical definitions and names, they are not repeated here as well.
4.2.4 Security Objectives from [SSCDPP]
The current PP also includes all security objectives for the TOE of [SSCDPP]. These items are applicable, if an
eSign application is included.
• OE.CGA_QCert
Federal Office for Information Security 27
625
630
635
640
645
4 Security Objectives BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
• OE.DTBS_Intend
• OE.DTBS_Protect
• OE.HID_VAD
• OE.Signatory
• OE.SSCD_Prov_Service
• OE.SVD_Auth
Due to identical definitions and names, their definitions are not repeated here.
4.2.5 Additional Security Objectives for the Environment
The following objective on the environment is defined akin to the objective from [ICPP].
OE.Lim_Block_Loader
The manufacturer will protect the Loader functionality against misuse, limit the capability of the Loader and
terminate irreversibly the Loader after intended usage of the Loader.
Justification: This security objective directly addresses the threat OT.Non_Interfere. This threat concerns
the potential interference of different access control mechanisms, which could occur as a result of
combining different applications on a smartcard. Such combination does not occur in one of the claimed
PPs. Hence, this security objective for the environment does
– neither mitigate a threat of one of the claimed PPs that was addressed by security objectives of that PP,
– nor does it fulfill any organizational security policy of one of the claimed PPs that was meant to be
addressed by security objectives of the TOE of that PP.
4.3 Security Objective Rationale
Table 2 provides an overview of the security objectives' coverage. According to [CC1], the tracing between
security objectives and the security problem definition must ensure that 1) each security objective traces to at
least one threat, OSP and assumption, 2) each threat, OSP and assumption has at least one security objective
tracing to it, and 3) the tracing is correct (i.e. the main point being that security objectives for the TOE do not
trace back to assumptions).
This is illustrated in the following way:
1. can be inferred for security objectives from claimed PPs by looking up the security objective rationale of
the claimed PPs and for newly introduced security objectives (i.e. OE.Lim_Block_Loader and
OT.Cap_Avail_Loader) by checking the columns of Table 2,
2. can be inferred for threats, OSPs and assumptions from the claimed PPs by looking up the security
objective rationale of the claimed PPs and for newly introduced threats, OSPs and assumptions by
checking the rows of Table 2, and
3. simply by checking the columns of Table 2 and the security objective rationales from the claimed PPs.
28 Federal Office for Information Security
650
655
660
665
670
675
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Objectives 4
OT.AC_Pers
OT.AC_Pers_EAC2
OT.Cap_Avail_Loader
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Data_Integrity
OT.Non_Interfere
OT.Sens_Data_Conf
(EAC1PP)
OT.Sens_Data_EAC2
OE.Lim_Block_Loader
T.InconsistentSec x x x x x x x x x x
T.Interfere x
P.Lim_Block_Loader x x x
Table 2: Security Objective Rationale
The threat T.InconsistentSec addresses attacks on the confidentiality and the integrity of user data stored on
the TOE, facilitated by the data not being protected as intended.
OT.AC_Pers and OT.AC_Pers_EAC2 define the restriction on writing or modifying data;
OT.Data_Authenticity, OT.Data_Confidentiality, OT.Data_Integrity, OT.Sens_Data_Conf (from [EAC1PP]), and
OT.Sens_Data_EAC2 require the security of stored user data as well as user data that are transferred between
the TOE and a terminal to be secure w.r.t. authenticity, integrity and confidentiality.
OT.Non_Interfere requires the TOE's access control mechanisms to be implemented consistently and their
implementations not to allow to circumvent an access control mechanism by exploiting an unintended
implementational interference of one access control mechanism with another one.
OT.Cap_Avail_Loader requires the TOE to provide limited capability of the loader functionality and
irreversible termination of the loader in order to protect stored user data.
OE.Lim_Block_Loader requires the manufacturer to protect the loader functionality against misuse, limit the
capability of the loader, and terminate irreversibly the loader after intended usage of the loader.
The combination of these security objectives cover the threat posed by T.InconsistentSec.The threat
T.Interfere addresses the attack on user data by exploiting the unintended interference of security protocols.
This is directly countered by OT.Non_Interfere, requiring the TOE's access control mechanisms to be
implemented consistently, and their implementations to not allow to circumvent an access control
mechanism by exploiting an unintended implementational interference of one access control mechanism
with another one.
The OSP P.Lim_Block_Loader addresses limiting the capability and blocking the availability of the Loader
in order to protect stored data from disclosure and manipulation. This is addressed by OT.Cap_Avail_Loader,
which requires the TOE to provide a limited capability of the loader functionality and irreversible
termination of the loader in order to protect stored user data; by OT.Non_Interfere, which requires the TOE's
access control mechanisms to be implemented consistently and their implementations not to allow to
circumvent an access control mechanism by exploiting an unintended implementational interference of
one access control mechanism with another one; and by OE.Lim_Block_Loader, which requires the
manufacturer to protect the Loader functionality against misuse, limit the capability of the Loader and
terminate irreversibly the Loader after intended usage of the Loader.
Federal Office for Information Security 29
680
685
690
695
700
705
5 Extended Components Definition BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
5 Extended Components Definition
This PP includes all extended components from the claimed PPs. This includes
– FAU_SAS.1 from the family FAU_SAS from [PACEPP]
– FCS_RND.1 from the family FCS_RND from [PACEPP]
– FMT_LIM.1 and FMT_LIM.2 from the family FMT_LIM from [PACEPP]
– FPT_EMS.1 from the family FPT_EMS from [PACEPP]
– FIA_API.1 from the family FIA_API from [EAC2PP]
For precise definitions we refer to [PACEPP] and [EAC2PP].
30 Federal Office for Information Security
710
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Requirements 6
6 Security Requirements
This part defines 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 must
satisfy in order to meet the security objectives for the TOE.
Common Criteria allows several operations to be performed on security requirements on the component
level: refinement, selection, assignment and iteration, cf. sec. 8.1 of [CC1]. Each of these operations is used in
this PP.
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
removed words are crossed out.
The selection operation is used to select one or more options provided by CC in stating a requirement.
Selections that have been made by the PP author are denoted as underlined text. Selections to be filled in by
the ST author appear in square brackets with an indication that a selection has to be made, [selection:], and
are italicized.
The assignment operation is used to assign a specific value to an unspecified parameter, such as the length
of a password. Assignments that have been made by the PP author are denoted as underlined text.
Assignments to be filled in by the ST author appear in square brackets with an indication that an assignment
has to be made [assignment:], and are italicized. In some cases the assignment made by the PP authors
defines a selection to be performed by the ST author. Thus this text is underlined and italicized like this.
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. For the sake of better
readability, the iteration operation may also be applied to a non-repeated single component in order to
indicate that such component belongs to a certain functional cluster. In such a case, the iteration operation
is applied to only one single component.
In order to distinguish between SFRs defined here and SFRs that are taken over from PPs to which this PP
claims strict conformance, the latter are iterated resp. renamed in the following way:
/EAC1PP or /XXX_EAC1PP [EAC1PP],
/EAC2PP or /XXX_EAC2PP for [EAC2PP],
and /SSCDPP or /XXX_SSCDPP for [SSCDPP].
6.1 Security Functional Requirements
The statements of security requirements must be internally consistent. As several different PPs with similar
SFRs are claimed, great care must be taken to ensure that these several iterated SFRs do not lead to
inconsistency.
Both [EAC1PP] and [EAC2PP] claim strict conformance to [PACEPP]. Thus they include all SFRs from
[PACEPP]. On the other hand, due to strict conformance to [EAC1PP] and [EAC2PP], this PP includes all SFRs
from [EAC1PP] and [EAC2PP]. Hence all SFRs from [PACEPP] appear in this PP twice as SFRs from
[EAC1PP] and [EAC2PP], and thus SFRs from [PACEPP] are not listed in this PP. In other words, despite
claiming strict conformance to [PACEPP], SFRs can be safely ignored during evaluation and certification
as long as [EAC1PP] and [EAC2PP] are taken into account.
One must remember that each of these iterated SFRs mostly concerns different (groups of) user and TSF data
for each protocol (i.e. PACE, EAC1 and EAC2). We distinguish three cases:
Federal Office for Information Security 31
715
720
725
730
735
740
745
750
6 Security Requirements BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
1. The SFRs apply to different data that are accessible by executing different protocols. Hence, they are
completely separate. An example is FCS_CKM.1/DH_PACE from [EAC1PP] and [EAC2PP]. No remark is
added in such case in the text below.
2. The SFRs are equivalent. Then we list them all for the sake of completeness. Hence, it suffices to consider
only one iteration. For such SFRs, we explicitly give a remark. An example is FIA_AFL.1/PACE from
[EAC1PP] and [EAC2PP].
3. The SFRs do not apply to different data or protocols, but are also not completely equivalent. Then these
multiple SFRs are refined in such a way, that one common component is reached that subsumes all
iterations that stem from the inclusions of the claimed PPs. An example is FDP_ACF.1, which is combined
here from [EAC1PP] and [EAC2PP]. Such a case is also explicitly mentioned in the text.
Thus internal consistency is not violated.
6.1.1 Class FCS
The following SFRs are imported due to claiming [EAC2PP]. They concern cryptographic support for
applications that contain EAC2-protected data groups.
• FCS_CKM.1/DH_PACE_EAC2PP
• FCS_COP.1/SHA_EAC2PP
• FCS_COP.1/SIG_VER_EAC2PP
• FCS_COP.1/PACE_ENC_EAC2PP
• FCS_COP.1/PACE_MAC_EAC2PP
• FCS_CKM.4/EAC2PP
• FCS_RND.1/EAC2PP
The following SFRs are imported due to claiming [EAC1PP]. They concern cryptographic support for
applications that contain EAC1-protected data groups.
• FCS_CKM.1/DH_PACE_EAC1PP
• FCS_CKM.4/EAC1_PP
(equivalent to FCS_CKM.4/EAC2PP, but listed here for the sake of completeness)
• FCS_COP.1/PACE_ENC_EAC1PP
• FCS_COP.1/PACE_MAC_EAC1PP
Application note 9: Note that national regulations w.r.t. key sizes and algorithms may further restrict the
choice of algorithms and key sizes defined in the above two SFRs.
• FCS_RND.1/EAC1PP
(equivalent to FCS_RND.1/EAC2PP, but listed here for the sake of completeness)
• FCS_CKM.1/CA_EAC1PP
• FCS_COP.1/CA_ENC_EAC1PP
• FCS_COP.1/SIG_VER_EAC1PP
• FCS_COP.1/CA_MAC_EAC1PP
The following SFRs are imported due to claiming [SSCDPP]. They only concern the cryptographic support
for an eSign application.
• FCS_CKM.1/SSCDPP
32 Federal Office for Information Security
755
760
765
770
775
780
785
790
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Requirements 6
• FCS_CKM.4/SSCDPP
• FCS_COP.1/SSCDPP
6.1.2 Class FIA
Table 3 provides an overview of the authentication and identification mechanisms used.
Name SFR for the TOE
PACE protocol FIA_UAU.1/PACE_EAC2PP
FIA_UAU.5/PACE_EAC2PP
FIA_AFL.1/Suspend_PIN_EAC2PP
FIA_AFL.1/Block_PIN_EAC2PP
FIA_AFL.1/PACE_EAC2PP
FIA_AFL.1/PACE_EAC1PP
Terminal Authentication Protocol version 2 FIA_UAU.1/EAC2_Terminal_EAC2PP
FIA_UAU.5/PACE_EAC2PP
Chip Authentication Protocol version 2 FIA_API.1/CA_EAC2PP
FIA_UAU.5/PACE_EAC2PP
FIA_UAU.6/PACE_EAC2PP
Terminal Authentication Protocol version 1 FIA_UAU.1/PACE_EAC1PP
FIA_UAU.5/PACE_EAC1PP
Chip Authentication Protocol version 1 FIA_API.1/EAC1PP
FIA_UAU.5/PACE_EAC1PP
FIA_UAU.6/EAC_EAC1PP
Restricted Identification FIA_API.1/RI_EAC2PP
eSign-PIN FIA_UAU.1/SSCDPP
Table 3: Overview of authentication and identification SFRs
6.1.2.1 SFRs for EAC2-protected Data
The following SFRs are imported due to claiming [EAC2PP]. They mainly concern authentication
mechanisms related to applications with EAC2-protected data.
• FIA_AFL.1/Suspend_PIN_EAC2PP
• FIA_AFL.1/Block_PIN_EAC2PP
• FIA_API.1/CA_EAC2PP
• FIA_API.1/RI_EAC2PP
• FIA_UID.1/PACE_EAC2PP
• FIA_UID.1/EAC2_Terminal_EAC2PP
Application note 10: The user identified after a successfully performed TA2 protocol is an EAC2 terminal.
Note that TA1 is covered by FIA_UID.1/PACE_EAC1PP. In that case, the terminal identified is in addition
also an EAC1 terminal.
• FIA_UAU.1/PACE_EAC2PP
• FIA_UAU.1/EAC2_Terminal_EAC2PP
Federal Office for Information Security 33
795
800
805
6 Security Requirements BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
• FIA_UAU.4/PACE_EAC2PP
• FIA_UAU.5/PACE_EAC2PP
• FIA_UAU.6/CA_EAC2PP
• FIA_AFL.1/PACE_EAC2PP
• FIA_UAU.6/PACE_EAC2PP
6.1.2.2 SFRs for EAC1-protected data
The following SFRs are imported due to claiming [EAC1PP]. They mainly concern authentication
mechanisms for applications with EAC1-protected data.
• FIA_UID.1/PACE_EAC1PP
• FIA_UAU.1/PACE_EAC1PP
• FIA_UAU.4/PACE_EAC1PP
• FIA_UAU.5/PACE_EAC1PP
• FIA_UAU.6/PACE_EAC1PP
(equivalent to FIA_UAU.6/PACE_EAC2PP, but listed here for the sake of completeness)
• FIA_UAU.6/EAC_EAC1PP
• FIA_API.1/EAC1PP
• FIA_AFL.1/PACE_EAC1PP
(equivalent to FIA_AFL.1/PACE_EAC2PP, but listed here for the sake of completeness)
The following SFRs are imported due to claiming [SSCDPP]. They concern access mechanisms for an eSign
application, if available.
• FIA_UID.1/SSCDPP
• FIA_AFL.1/SSCDPP
6.1.2.3 SFRs concerning eSign-applications
The next claimed SFR is refined from [SSCDPP] by additional assignments. Note that this does not violate
strict conformance to [SSCDPP].
FIA_UAU.1/SSCDPP
Hierarchical to:
No other components.
Dependencies:
FIA_UID.1 Timing of identification:
fulfilled by FIA_UID.1/SSCD
FIA_UAU.1.1/SSCDPP
The TSF shall allow
1. self test according to FPT_TST.1/SSCDPP,
2. identification of the user by means of TSF required by FIA_UID.1/SSCD,
34 Federal Office for Information Security
810
815
820
825
830
835
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Requirements 6
3. establishing a trusted channel between CGA and the TOE by means of TSF required by
FTP_ITC.1/CA_EAC2,
4. establishing a trusted channel between HID and the TOE by means of TSF required by
FTP_ITC.1/CA_EAC2,
5. [assignment: list of additional TSF-mediated actions]
on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2/SSCDPP
The TSF shall require each user to be successfully authenticated before allowing any other
TSF-mediated actions on behalf of that user.
6.1.3 Class FDP
Multiple iterations of FDP_ACF.1 exist from imported PPs to define the access control SFPs for (common)
user data, EAC1-protected user data, and EAC2-protected user data. The access control SFPs defined in
FDP_ACF.1/EAC1PP from [EAC1PP] and FDP_ACF.1/EAC2PP from [EAC2PP] are here unified to one single
FDP_ACF.1/TRM, whereas the several iterations of FDP_ACF.1 from [SSCDPP] stand separate. Here we take
FDP_ACF.1/EAC2PP as a base definition of functional elements, and it is refined in a way that it is compatible
with FDP_ACF.1/EAC1PP. Hence highlighting refers to changes w.r.t. to FDP_ACF.1/EAC2PP. In the
application note below, we explain how FDP_ACF.1/EAC1PP is covered as well.
Concerning FDP_ACF.1/TRM here and the several iterations FDP_ACF.1 from [SSCDPP], we remark that
FDP_ACF.1/TRM also concerns data and objects for signature generation. Note however, that
FDP_ACF.1/TRM requires that prior to granting access to the signature application, in which the access
controls defined in [SSCDPP] apply, an EAC2 terminal and the electronic document holder need to be
authenticated. Hence, no inconsistency exist.
FDP_ACF.1/TRM Security attribute based access control –Terminal Access
Hierarchical to:
No other components.
Dependencies:
FDP_ACC.1 Subset access control
fulfilled by FDP_ACC.1/TRM_EAC1PP and FDP_ACC.1/TRM_EAC2PP
FMT_MSA.3 Static attribute initialization
not fulfilled, but justified:
The access control TSF according to FDP_ACF.1/TRM uses security attributes having been defined
during the personalization and fixed over the whole life time of the TOE. No management of these
security attributes (i.e. SFR FMT_MSA.1 and FMT_MSA.3) is necessary here.
FDP_ACF.1.1/TRM
The TSF shall enforce the Access Control SFP5
to objects based on the following:
1) Subjects:
a) Terminal,
b) PACE terminal,
c) EAC2 terminal [assignment: list of EAC2 terminal types],
5 [assignment: access control SFP]
Federal Office for Information Security 35
840
845
850
855
860
865
6 Security Requirements BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
d) EAC1 terminal6
;
2) Objects:
a) all user data stored in the TOE; including sensitive EAC1-protected user data, and
sensitive EAC2-protected user data.
b) all TOE intrinsic secret (cryptographic) data
3) Security attributes:
a) Terminal Authorization Level (access rights)
b) Authentication status of the electronic document holder as a signatory (if an eSign
application is included)78
.
FDP_ACF.1.2/TRM
The TSF shall enforce the following rules to determine if an operation among controlled subjects and
controlled objects is allowed:
A PACE terminal is allowed to read data objects from FDP_ACF.1/TRM after successful PACE
authentication according to [TR03110-2] and/or [ICAO-SAC], as required by FIA_UAU.1/PACE.9
FDP_ACF.1.3/TRM
The TSF shall explicitly authorize access of subjects to objects based on the following additional rules:
none.10
FDP_ACF.1.4/TRM
The TSF shall explicitly deny access of subjects to objects based on the following additional rules:
1. Any terminal not being authenticated as a PACE terminal or an EAC2 terminal or an EAC1 terminal is
not allowed to read, to write, to modify, or to use any user data stored on the electronic document.11
2. Terminals not using secure messaging are not allowed to read, write, modify, or use any data stored on
the electronic document.
3. No subject is allowed to read ‘Communication Establishment Authorization Data’ stored on the
electronic document
4. No subject is allowed to write or modify ‘secret electronic document holder authentication data’
stored on the electronic document, except for PACE terminals or EAC2 terminals executing PIN
management based on the following rules:
[assignment: list of rules for PIN management chosen from[TR03110-2]].
5. No subject is allowed to read, write, modify, or use the private Restricted Identification key(s) and Chip
Authentication key(s) stored on the electronic document.
6. Reading, modifying, writing, or using sensitive user data that are protected only by EAC2, is allowed
only to EAC2 terminals using the following mechanism:
6 [assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-relevant security attributes,
or name groups of SFP-relevant security attributes] (added using open assignment of [EAC2PP])
7 [assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-relevant security attributes,
or name groups of SFP-relevant security attributes] (added using open assignment of [EAC2PP])
8 [assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-relevant security attributes,
or name groups of SFP-relevant security attributes] (all bullets in FDP_ACF.1.1/TRM w.r.t. [CC2])
9 [assignment: rules governing access among controlled subjects and controlled objects using controlled operations on
controlled objects]
10 [assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
11 note that authentication of an EAC1 or EAC2 terminal to a TOE in certified mode implies a prior run of PACE.
36 Federal Office for Information Security
870
875
880
885
890
895
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Requirements 6
The TOE applies the EAC2 protocol (cf. FIA_UAU.5) to determine access rights of the terminal according
to [TR03110-2]. To determine the effective authorization of a terminal, the chip must calculate a bitwise
Boolean ’and’ of the relative authorization contained in the CHAT of the Terminal Certificate, the
referenced DV Certificate, and the referenced CVCA Certificate, and additionally the confined
authorization sent as part of PACE. Based on that effective authorization and the terminal type drawn
from the CHAT of the Terminal Certificate, the TOE shall grant the right to read, modify or write
sensitive user data, or perform operations using these sensitive user data.
7. No subject is allowed to read, write, modify or use the data objects 2b) of FDP_ACF.1.1/TRM.
8. No subject is allowed to read sensitive user data that are protected only by EAC1, except an EAC1
terminal (OID inspection system) after EAC1, cf. FIA_UAU.1/EAC1, that has a corresponding relative
authorization level. This includes in particular EAC1-protected user data DG3 and DG4 from an
ICAO-compliant ePass application, cf. [TR03110-1] and [ICAO9303].
9. If sensitive user data is protected both by EAC1 and EAC2, no subject is allowed to read those data
except EAC1 terminals or EAC2 terminals that access these data according to rule 6 or rule 8 above.
10. Nobody is allowed to read the private signature key(s).12
Application note 11: The above definition is based on FDP_ACF.1/TRM_EAC2PP. We argue that it covers
FDP_ACF.1/TRM_EAC1PP as well. Subject 1b and 1d are renamed here from FDP_ACF.1.1/TRM_EAC1PP
according to Table 1. Objects in 2), in particular the term EAC1-protected user data, subsume all those ex-
plicitly enumerated in FDP_ACF.1.1/TRM_EAC1PP. Also the security attribute 3a) Terminal Authoriza-
tion Level here subsumes the explicitly enumerated attributes 3a) and 3b) of FDP_ACF.1.1/TRM_EAC1PP,
but are semantically the same. Since in addition EAC2 protected data are stored in the TOE of this PP,
additional subjects, objects and security attributes are listed here. However since they apply to data with
a different protection mechanism (EAC2), strict conformance is not violated.
FDP_ACF.1.2/TRM uses the renaming of Table 1, and references in addition [TR03110-2]. However the
references are compatible as justified in [EAC2PP], yet both are mentioned here since [TR03110-2] is the
primary norm for an eID application, whereas [ICAO-SAC] is normative for an ICAO compliant ePass
application. Investigating the references reveals that access to data objects defined in FDP_ACF.1.1/TRM
must be granted if these data are neither EAC1-protected, nor EAC2-protected.
FDP_ACF.1.3/TRM is the same as in FDP_ACF.1.3/TRM_EAC2PP.
References are changed in FDP_ACF.1.2/TRM_EAC1PP. It is already justified in [EAC2PP] that defini-
tions in [TR03110-2] and [ICAO9303] are compatible.
FDP_ACF.1.3/TRM is taken over from [EAC1PP] and [EAC2PP] (same formulation in both).
Rules 1 and 2 of FDP_ACF.1.4/TRM_EAC1PP in [EAC1PP] are covered by their counterparts rule 1 and
rule 2 here. Rules 3 and 4, and rule 6 of FDP_ACF.1.4/TRM_EAC1PP in [EAC1PP] are combined here to
rule 8, where terminals need the corresponding CHAT to read data groups. Rule 5 of [EAC1PP] is here
equivalent to rule 7. None of this conflicts with strict conformance to [EAC1PP]. Note that adding addi-
tional rules compared to FDP_ACF.1.4/TRM_EAC1PP here can never violate strict conformance, as these
are rules that explicitly deny access of subjects to objects. Hence security is always increased.
The above definition also covers FDP_ACF.1.1/TRM_EAC2PP and extends it by additional subjects and
objects. Sensitive user data in the definition of FDP_ACF.1.1/TRM_EAC2PP are here EAC2-protected
sensitive user data. EAC1-protected data are added here by refinement. Since the protection level and
mechanisms w.r.t. to EAC2-protected data do not change, strict conformance is not violated.
FDP_ACF.1.2/TRM_EAC2PP and FDP_ACF.1.3/TRM_EAC2PP are equivalent to the current definition.
Rules 8, 9 and 10 are added here by open assignment from [EAC2PP]. None of this conflicts with strict
conformance.
The dependency of this SFR is met by FDP_ACC.1/TRM_EAC1PP and FDP_ACC.1/TRM_EAC2PP. Note
that the SFR in [EAC1PP] applies the assignment operation, whereas in [EAC2PP] (by referencing
[PACEPP]) the assignment is left open. Hence they are compatible. We remark that in order to restrict
the access to user data as defined in the SFR FDP_ACC.1/TRM_EAC1PP, clearly access to objects 2b) of
12 [assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
Federal Office for Information Security 37
900
905
910
915
920
925
930
935
940
945
6 Security Requirements BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
FDP_ACF.1.1/TRM must be restricted as well according to the SFP, otherwise access to user data is im-
possible to enforce.
The following SFRs are imported due to claiming [EAC2PP]. They concern access control mechanisms
related to EAC2-protected data.
• FDP_ACC.1/TRM_EAC2PP
This SFR is equivalent to/covered by FDP_ACC.1/TRM_EAC1PP; cf. the application note above.
• FDP_ACF.1/TRM_EAC2PP
This SFR is equivalent to/covered by FDP_ACF.1/TRM
• FDP_RIP.1/EAC2PP
• FDP_UCT.1/TRM_EAC2PP
• FDP_UIT.1/TRM_EAC2PP
The following SFRs are imported due to claiming [EAC1PP]. They concern access control mechanisms
related to EAC1-protected data.
• FDP_ACC.1/TRM_EAC1PP
The above is equivalent to FDP_ACC.1/TRM_EAC2PP, since EF.SOD (cf. FDP_ACC.1/TRM in [EAC1PP])
can be considered user data.; cf. also the application note below FDP_ACF.1/TRM.
• FDP_ACF.1/TRM_EAC1PP
The above is covered by FDP_ACF.1/TRM; cf. Application Note there.
• FDP_RIP.1/EAC1PP
• FDP_UCT.1/TRM_EAC1PP
(equivalent to FDP_UCT.1/TRM_EAC2PP, but listed here for the sake of completeness)
• FDP_UIT.1/TRM_EAC1PP
(equivalent to FDP_UIT.1/TRM_EAC2PP, but listed here for the sake of completeness)
The following SFRs are imported due to claiming [SSCDPP]. They concern access control mechanisms of an
eSign application.
• FDP_ACC.1/SCD/SVD_Generation_SSCDPP
• FDP_ACF.1/SCD/SVD_Generation_SSCDPP
• FDP_ACC.1/SVD_Transfer_SSCDPP
• FDP_ACF.1/SVD_Transfer_SSCDPP
• FDP_ACC.1/Signature-creation_SSCDPP
• FDP_ACF.1/Signature-creation_SSCDPP
• FDP_RIP.1/SSCDPP
• FDP_SDI.2/Persistent_SSCDPP
• FDP_SDI.2/DTBS_SSCDPP
6.1.4 Class FTP
The following SFRs are imported from [EAC2PP].
• FTP_ITC.1/PACE_EAC2PP
38 Federal Office for Information Security
950
955
960
965
970
975
980
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Requirements 6
• FTP_ITC.1/CA_EAC2PP
The following SFR is imported due to claiming [EAC1PP]. It concerns applications with EAC1-protected data.
• FTP_ITC.1/PACE_EAC1PP
6.1.5 Class FAU
The following SFR is imported due to claiming [EAC2PP]. It concerns applications with EAC2-protected data.
• FAU_SAS.1/EAC2PP
The following SFR is imported due to claiming [EAC1PP]. It concerns applications with EAC1-protected data.
• FAU_SAS.1/EAC1PP
(equivalent to FAU_SAS.1/EAC2PP, but listed here for the sake of completeness)
6.1.6 Class FMT
FMT_SMR.1 Security roles
Hierarchical to:
No other components.
Dependencies:
FIA_UID.1 Timing of identification:
fulfilled by FIA_UID.1/PACE_EAC1PP, FIA_UID.1/PACE_EAC2PP, FIA_UID.1/EAC2_Terminal_EAC2PP,
see also the Application Note below.
FMT_SMR.1.1
The TSF shall maintain the roles
1. Manufacturer,
2. Personalization Agent,
3. Country Verifying Certification Authority,
4. Document Verifier,
5. Terminal,
6. PACE terminal,
7. EAC2 terminal, if the eID, ePassport and/or eSign application are active,
8. EAC1 terminal, if the ePassport application is active
9. Electronic document holder.13
FMT_SMR.1.2
The TSF shall be able to associate users with roles.
The next SFRs are imported from [EAC2PP]. They concern mainly applications with EAC2-protected data.
• FMT_MTD.1/CVCA_INI_EAC2PP
13 [assignment: the authorized identified roles]
Federal Office for Information Security 39
985
990
995
1000
1005
6 Security Requirements BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
• FMT_MTD.1/CVCA_UPD_EAC2PP
• FMT_SMF.1/EAC2PP
• FMT_SMR.1/PACE_EAC2PP
This SFR is combined with MT_SMR.1/PACE_EAC1PP into to by FMT_SMR.1.
• FMT_MTD.1/DATE_EAC2PP
• FMT_MTD.1/PA_EAC2PP
• FMT_MTD.1/SK_PICC_EAC2PP
• FMT_MTD.1/KEY_READ_EAC2PP
• FMT_MTD.1/Initialize_PIN_EAC2PP
• FMT_MTD.1/Change_PIN_EAC2PP
• FMT_MTD.1/Resume_PIN_EAC2PP
• FMT_MTD.1/Unblock_PIN_EAC2PP
• FMT_MTD.1/Activate_PIN_EAC2PP
• FMT_MTD.3/EAC2PP
• FMT_LIM.1/EAC2PP
Application note 12: The above SFR concerns the whole TOE, not just applications with EAC2-protected
data.
• FMT_LIM.2/EAC2PP
Application note 13: The above SFR concerns the whole TOE, not just applications with EAC2-protected
data.
• FMT_MTD.1/INI_ENA_EAC2PP
• FMT_MTD.1/INI_DIS_EAC2PP
The following SFRs are imported due to claiming [EAC1PP]. They mainly concern applications with
EAC1-protected data.
• FMT_SMF.1/EAC1PP
• FMT_SMR.1/PACE_EAC1PP
This SFR is combined with FMT_SMR.1/PACE_EAC2PP into FMT_SMR.1
• FMT_LIM.1/EAC1PP
This SFR is equivalent to FMT_LIM.1/EAC2PP, but listed here for the sake of completeness.
• FMT_LIM.2/EAC1PP
This SFR is equivalent to FMT_LIM.2/EAC2PP, but listed here for the sake of completeness.
• FMT_MTD.1/INI_ENA_EAC1PP
(equivalent to FDP_MTD.1/INI_ENA_EAC2PP, but listed here for the sake of completeness)
• FMT_MTD.1/INI_DIS_EAC1PP
(equivalent to FDP_MTD.1/INI_DIS_EAC2PP, but listed here for the sake of completeness)
• FMT_MTD.1/CVCA_INI_EAC1PP
• FMT_MTD.1/CVCA_UPD_EAC1PP
40 Federal Office for Information Security
1010
1015
1020
1025
1030
1035
1040
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Requirements 6
• FMT_MTD.1/DATE_EAC1PP
This SFR is equivalent to FMT_MTD.1/DATE_EAC2PP . Note that FMT_MTD.1/DATE_EAC2PP generalizes
the notion of Domestic Extended Inspection System to EAC1 terminals with appropriate authorization
level. This does not violate strict conformance to [EAC1PP].
• FMT_MTD.1/CAPK_EAC1PP
• FMT_MTD.1/PA_EAC1PP
• FMT_MTD.1/KEY_READ_EAC1PP
• FMT_MTD.3/EAC1PP
The following SFRs are imported due to claiming [SSCDPP]. They mostly concern the security management
of an eSign application.
• FMT_SMR.1/SSCDPP
• FMT_SMF.1/SSCDPP
• FMT_MOF.1/SSCDPP
• FMT_MSA.1/Admin_SSCDPP
• FMT_MSA.1/Signatory_SSCDPP
• FMT_MSA.2/SSCDPP
• FMT_MSA.3/SSCDPP
• FMT_MSA.4/SSCDPP
• FMT_MTD.1/Admin_SSCDPP
• FMT_MTD.1/Signatory_SSCDPP
The following SFRs are defined here. The concern loading applications onto the IC during manufacturing
and relate directly to OT.Cap_Avail_Loader.
FMT_LIM.1/Loader Limited Capabilities
Hierarchical to:
No other components
Dependencies:
FMT_LIM.2/Loader Limited availability
FMT_LIM.1.1/Loader
The TSF shall be designed and implemented in a manner that limits their capabilities so that in
conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced: Deploying Loader
functionality after [assignment: action] does not allow stored user data to be disclosed or manipulated
by unauthorized users.14
Application note 14: FMT_LIM.1/Loader supplements FMT_LIM.2/Loader allowing for non-overlapping
loading of user data and protecting the TSF against misuses of the Loader for attacks against the TSF. The
TOE Loader may allow for correction of already loaded user data before the assigned action e.g. before
blocking the TOE Loader for TOE Delivery to the end-customer or any intermediate step on the life cycle of
the Security IC or the smartcard.
14 [assignment: Limited capability and availability policy]
Federal Office for Information Security 41
1045
1050
1055
1060
1065
1070
1075
6 Security Requirements BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
FMT_LIM.2/Loader Limited Availability
Hierarchical to:
No other components
Dependencies:
FMT_LIM.1/Loader Limited capabilities
FMT_LIM.2.1/Loader
The TSF shall be designed and implemented in a manner that limits their availability so that in
conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced: The TSF prevents
deploying the Loader functionality after [assignment: action].15
Application note 15: The Loader functionality relies on a secure boot loading procedure in a secure
environment before TOE delivery to the assigned user and preventing to deploy the Loader of the Security
IC after an assigned action, e.g. after blocking the Loader for TOE delivery to the end-user.
6.1.7 Class FPT
The following security functional requirements are imported from [EAC2PP], and address the protection
against forced illicit information leakage, including physical manipulation.
• FPT_EMS.1/EAC2PP
Application note 16: Note that related to Application Note 6, the PIN in the above SFR refers here to both
the PIN for an eID application, and also the PIN for an eSign application, if they exist on card.
• FPT_FLS.1/EAC2PP
• FPT_TST.1/EAC2PP
• FPT_PHP.3/EAC2PP
The following SFRs are imported due to claiming [EAC1PP]. They mostly concern the protection of security
functionality related to EAC1-protected data.
• FPT_TST.1/EAC1PP
(equivalent to FPT_TST.1/EAC2PP, but listed here for the sake of completeness)
• FPT_FLS.1/EAC1PP
(equivalent to FPT_FLS.1/EAC2PP, but listed here for the sake of completeness)
• FPT_PHP.3/EAC1PP
(equivalent to FPT_PHP.3/EAC2PP, but listed here for the sake of completeness)
• FPT_EMS.1/EAC1PP
The following SFRs are imported due to claiming [SSCDPP]. They mostly concern the protection of security
functionality related to eSign application (if available).
• FPT_EMS.1/SSCDPP
• FPT_FLS.1/SSCDPP
(subsumed by FPT_FLS.1/EAC2PP)
• FPT_PHP.1/SSCDPP
• FPT_PHP.3/SSCDPP
(subsumed by FPT_PHP.3/EAC2PP)
15 [assignment: Limited capability and availability policy]
42 Federal Office for Information Security
1080
1085
1090
1095
1100
1105
1110
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Requirements 6
• FPT_TST.1/SSCDPP
(subsumed by FPT_FPT_TST.1/EAC2PP)
6.2 Security Assurance Requirements for the TOE
The assurance requirements for the evaluation of the TOE, its development and operating environment are
to choose as the predefined assurance package EAL4 augmented by the following components:
– ALC_DVS.2 (Sufficiency of security measures),
– ATE_DPT.2 (Testing: security enforcing modules) and
– AVA_VAN.5 (Advanced methodical vulnerability analysis).
6.3 Security Requirements Rationale
6.3.1 Security Functional Requirements Rationale
The following table provides an overview for the coverage of the security functional requirements, and also
gives evidence for sufficiency and necessity of the chosen SFRs.
OT.Chip_Auth_Proof
(EAC1PP)
OT.Sens_Data_Conf
(EAC1PP)
OT.AC_Pers_EAC2
OT.Sens_Data_EAC2
OT.Data_Integrity
OT.Data_Authenticity
OT.Data_Confdentiality
OT.Identifcation
OT.AC_Pers
OT.Prot_Inf_Leak
OT.Non_Interfere
OT.SCD/SVD_Gen
(SSCDPP)
OT.Sigy_SigF
(SSCDPP)
OT.Cap_Avail_Loader
Class FIA
FIA_UAU.1/SSCDPP x x
Class FDP
FDP_ACF.1/TRM x x x x x x x
Class FMT
FMT_SMR.1 x x x x x x x x x
FMT_LIM.1/Loader x
FMT_LIM.2/Loader x
Class FPT
FPT_EMS.1/EAC1PP x x x
FPT_EMS.1/EAC2PP x x x
FPT_EMS.1/SSCDPP x
Table 4: Coverage of Security Objectives for the TOE by SFRs
According to [CC1], tracing between SFRs and security objectives must ensure that 1) each SFR traces back to
at least one security objective, and 2) that each security objective for the TOE has at least one SFR tracing to
it. This is illustrated for
1. SFRs that have been newly added or refined within this PP by checking the rows of Table 4, and for SFRs
that are merely iterated or simply included due to claims of other protection profiles by looking up the
rationale of that PP
Federal Office for Information Security 43
1115
1120
1125
6 Security Requirements BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
2. for newly introduced security objectives in this PP by checking the non-cursive columns of Table 4, and
for the other security objectives by looking up the rationale of that PP.
In other words, in Table 4, we list only:
– SFRs that have been newly added or refined within this PP. Mere iterations or simple inclusions due
to claims of other protection profiles are not listed however. For their coverage we refer to the
respective claimed PP.
– Security objectives that are newly introduced in this PP, and their related SFRs.
– Security objectives for the TOE that are affected by the above newly added or refined SFRs.
Analogously, we limit our justification to the above SFRs and security objectives. For other security
objectives, and for the justification of security objectives w.r.t. SFRs that are included or iterated from
claimed protection profiles, we refer to the detailed rationales in [EAC1PP], [EAC2PP] and [SSCDPP].
FIA_UAU.1/SSCDPP is refined here in a way that the TOE supports additionally EAC2 based access control
w.r.t. SSCD-related user data. This does not affect the discussion of the rationale of [SSCDPP].
FDP_ACF.1/TRM unifies the access control SFPs of FDP_ACF.1/TRM_EAC2PP and
FDP_ACF.1/TRM_EAC1PP. Both access control SFPs however are maintained w.r.t. sensitive EAC1-protected
data and EAC2-protected data. Thus the discussion of the rationale of [EAC1PP] and [EAC2PP] remains
unaffected.
FMT_SMR.1/EAC1PP and FMT_SMR.1/EAC2PP have been unified to FMT_SMR.1 by adding additional
roles. For all security objectives affected, FMT_SMR.1 supports related roles analogously as in the discussion
of the rationales of [EAC1PP] and [EAC2PP].
The security objective OT.Cap_Avail_Loader is directly covered by the SFRs FMT_LIM.1/Loader and
FMT_LIM.2/Loader, which limits the availability of the loader, as required by the objective.
FPT_EMS.1/EAC1PP and FPT_EMS.1/EAC2PP together define all protected data. Since all previous data are
included, the discussion of the rationales of [EAC1PP] and [EAC2PP] is not affected.
The objective OT.Non_Interfere aims to ensure that no security related interferences between the
implementations of the different access control mechanisms exist that allow unauthorized access of user or
TSF-Data. This objective is fulfilled by enforcing the access control SFPs, in particular FDP_ACF.1/TRM in
connection with FDP_ACC.1/TRM_EAC1PP. Related roles are supported by FMT_SMR.1. Interferences that
are observable by emissions from the TOE are prevented due to FPT_EMS.1/EAC1PP, FPT_EMS.1/EAC2PP,
and FPT_EMS.1/SSCDPP, where the set union of all defined data covers all relevant data.
6.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 analyzed, and non-dissolved dependencies are appropriately
explained.
The dependency analysis has directly been made within the description of each SFR in Section 6.1 above. All
dependencies being expected by [CC2] and by extended components definition in Chapter 5 are either
fulfilled, or their non-fulfillment is justified.
6.3.3 Security Assurance Requirements Rationale
The current assurance package was chosen based on the predefined 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,
44 Federal Office for Information Security
1130
1135
1140
1145
1150
1155
1160
1165
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Security Requirements 6
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 ALC_DVS.2 provides a higher assurance of the security of the electronic
document’s development and manufacturing, especially for the secure handling of sensitive material.
The selection of the component ATE_DPT.2 provides a higher assurance than the predefined 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 predefined EAL4 package,
namely requiring a vulnerability analysis to assess the resistance to penetration attacks performed by an
attacker possessing a high attack potential (see also Table 3, entry ‘Attacker’). This decision represents a part
of the conscious security policy for the electronic document required by the electronic document issuer and
reflected by the current PP.
The set of assurance requirements being part of EAL4 fulfills all dependencies a priori. The augmentation of
EAL4 chosen comprises the following assurance components: ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5. For
these additional assurance component, all dependencies are met or exceeded in the EAL4 assurance package.
Below we list only those assurance requirements that are additional to EAL4.
ALC_DVS.2
Dependencies:
None
ATE_DPT.2
Dependencies:
ADV_ARC.1, ADV_TDS.3, ATE_FUN.1
fulfilled by ADV_ARC.1, ADV_TDS.3, ATE_FUN.1
AVA_VAN.5
Dependencies:
ADV_ARC.1, ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, AGD_OPE.1, AGD_PRE.1, ATE_DPT.1
fulfilled by ADV_ARC.1, ADV_FSP.4, ADV_TDS.3, ADV_IMP.1, AGD_OPE.1, AGD_PRE.1, ATE_DPT.2
6.3.4 Security Requirements – Internal Consistency
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) are internally consistent. The analysis of the TOE´s security requirements with regard to their mutual
support and internal consistency demonstrates:
The dependency analysis in Section 6.3.2 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 analyzed and non-satisfied dependencies are appropriately justified.
All subjects and objects addressed by more than one SFR are also treated in a consistent way: the SFRs
impacting them do not require any contradictory property or behavior of these ‘shared’ items.
The assurance package EAL4 is a predefined set of internally consistent assurance requirements. The
dependency analysis for the sensitive assurance components in Section 6.3.3 shows that the assurance
requirements are internally consistent as all (additional) dependencies are satisfied and no inconsistency
appears.
Inconsistency between functional and assurance requirements can only arise due to functional-assurance
dependencies not being met. As shown in Section 6.3.2 and Section6.3.3,the chosen assurance components
Federal Office for Information Security 45
1170
1175
1180
1185
1190
1195
1200
1205
1210
6 Security Requirements BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
are adequate for the functionality of the TOE. Hence, there are no inconsistencies between the goals of these
two groups of security requirements.
46 Federal Office for Information Security
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Glossary and Abbreviations
Glossary and Abbreviations
Glossary
Accurate Terminal Certificate
A Terminal Certificate is accurate, if the issuing Document Verifier is trusted by the electronic
document’s chip to produce terminal certificates with the correct certificate effective date, see
[TR03110-3].
Card Access Number (CAN)
A short password that is printed or displayed on the document. The CAN is a non-blocking password.
The CAN may be static (printed on the electronic document), semi-static (e.g. printed on a label on the
electronic document) or dynamic (randomly chosen by the electronic electronic document and
displayed by it using e.g. ePaper, an OLED or similar technologies), cf. [TR03110-2].
Card Security Object (SOC)
An RFC3369 CMS signed data structure signed by the Document Signer. It is stored in the electronic
document (EF.CardSecurity, see [TR03110-3]) and carries the hash values of different data groups as
defined. It also carries the Document Signer Certificate [TR03110-3].
Certificate Chain
Hierarchical sequence of Terminal Certificate (lowest level), DV Certificate and CVCA Certificates
(highest level), where the certificate of a lower level is signed with the private key corresponding to
the public key in the certificate of the next higher level. The CVCA Certificate is signed with the
private key corresponding to the public key it contains (self-signed certificate).
CountryVerifying Certification Authority (CVCA)
An organization enforcing the privacy policy of the electronic document issuer with respect to
protection of sensitive user data that are stored in the electronic document. Practically, this policy is
enforced when a terminal tries to get access to these sensitive user data. The CVCA represents the
country specific root of the PKI for EAC1 terminals, EAC2 terminals resp. and creates DV certificates
within this PKI. Updates of the public key of the CVCA are distributed in form of CVCA
link-certificates, see [TR03110-3].
Current Date
The most recent certificate effective date contained in a valid CVCA link certificate, a DV certificate or
an accurate terminal certificate known to the TOE, see [TR03110-3].
CV Certificate
Card verifiable certificate according to [TR03110-3].
CVCA Link Certificate
Certificate of the new public key of the CVCA signed with the old public key of the CVCA where the
certificate effective date for the new key is before the certificate expiration date of the certificate for
the old key.
Document Security Object (SOD)
A RFC3369 CMS signed data structure, signed by the Document Signer. Carries the hash values of the
data groups. It is usually stored in an ICAO-conformant ePass application of an electronic document.
It may carry the document signer certificate; see [TR03110-3]and [ICAO9303].
Document Signer
An organization enforcing the policy of the CSCA and signing the electronic document security
object stored on the electronic document for passive authentication.
Federal Office for Information Security 47
1215
1220
1225
1230
1235
1240
1245
1250
Glossary and Abbreviations BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
A document signer is authorized by the national CSCA to issue document signer certificate,
cf. [TR03110-3] and [ICAO9303].
This role is usually delegated to the personalization agent.
Document Verifier (DV)
An organization issuing terminal certificates as a Certificate Authority, authorized by the
corresponding CVCA to issue certificates for EAC1 terminals, EAC2 terminals resp., see [TR03110-3].
Extended Access Control 1
A set of security protocols and mechanisms to ensure genuineness of the electronic document and to
allow a fine-grained access control to sensitive user data stored on an electronic
document [TR03110-1].
Extended Access Control 2
A set of security protocols and mechanisms to ensure genuineness of the electronic document and to
allow a fine-grained access control to sensitive user data stored on an electronic document
[TR03110-2].
IC Dedicated Software
Software developed and injected into the chip hardware by the IC manufacturer. Such software might
support special functionality of the IC hardware and be used, amongst other, for implementing
delivery procedures between different entities. The usage of parts of the IC dedicated software might
be restricted to certain life phases.
IC Embedded Software
Software embedded in an IC and not being designed by the IC developer. The IC embedded software
is designed in the design life phase and embedded into the IC in the manufacturing life phase of the
TOE.
Electronic Document (electronic part only)
A smart card integrated into a plastic, optical readable cover. An electronic electronic document
provides one or several application(s), such as an eID application, or an ePass application.
Initialization Data
Any data defined by the electronic document manufacturer and injected into the non-volatile
memory by the integrated circuit manufacturer. These data are, for instance, used for traceability and
for IC identification as IC_Card material (IC identification data).
Issuing State
The country issuing the electronic document; see [ICAO9303].
Machine Readable Zone (MRZ)
Fixed dimensional area located on the front of an ICAO-conformant electronic document. The MRZ
contains mandatory and optional data for machine reading using optical character recognition; see
[ICAO9303].
The MRZ-Password is a secret key that is derived from the machine readable zone and may be used
for PACE.
Meta-Data of a CV Certificate
Data within the certificate body as described in [TR03110-3]. The meta-data of a CV certificate
comprise the following elements:
• Certificate Profile Identifier,
• Certificate Authority Reference,
• Certificate Holder Reference,
48 Federal Office for Information Security
1255
1260
1265
1270
1275
1280
1285
1290
1295
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Glossary and Abbreviations
• Certificate Holder Authorization Template (CHAT),
• Certificate Effective Date,
• Certificate Expiration Date,
• Certificate Extensions (optional).
Passive Authentication
Security mechanism implementing (i) verification of the digital signature of the card (document)
security object and (ii) comparing the hash values of the read data fields with the hash values
contained in the card (document) security object. See [TR03110-3].
Password Authenticated Connection Establishment (PACE)
A communication establishment protocol defined in [TR03110-2] / [ICAO9303] resp.
PACE Password
A password needed for PACE authentication, e. g. CAN, MRZ, or a PIN.
Personal Identification Number (PIN)
A short secret password being only known to the electronic document holder. The PIN is a blocking
password, see [TR03110-2].
Personalization
The process by which data related to the electronic document holder (biographic and biometric data,
or key pair(s) for a potential signature application) are stored in and unambiguously, inseparably
associated with the electronic document.
PIN Unblock Key (PUK)
A long secret password being only known to the electronic document holder. The PUK is a
non-blocking password, see [TR03110-2].
Pre-personalization Data
Any data that is injected into the non-volatile memory of the TOE by the manufacturer for
traceability of the non-personalized electronic document and/or to secure shipment within or
between the life cycle phases manufacturing and card issuing.
Restricted Identification
Restricted Identification is a mechanism consisting of a security protocol for pseudo anonymization.
This is achieved by providing a temporary electronic document identifier specific for a terminal
sector and supporting related revocation features (see [TR03110-2]).
Secure Messaging
Secure messaging using encryption and message authentication code according to [ISO7816-4].
Abbreviations
CA Chip Authentication
CAN Card Access Number
CC Common Criteria
CHAT Certificate Holder Authorization Template
EAC Extended Access Control
MRZ Machine readable zone
Federal Office for Information Security 49
1300
1305
1310
1315
1320
1325
1330
1335
Glossary and Abbreviations BSI-CC-PP-0087 (Version 1.01, May 20th, 2015)
n.a. Not applicable
OSP Organizational security policy
PACE Password Authenticated Connection Establishment
PCD Proximity Coupling Device
PICC Proximity Integrated Circuit Chip
PIN Personal Identification Number
PP Protection Profile
PUK PIN Unblock Key
RF Radio Frequency
SAR Security assurance requirements
SFR Security functional requirement
TA Terminal Authentication
TOE Target of Evaluation
TSF TOE security functionality
TSP TOE Security Policy (defined by the current document)
VAD Verification Authentication Data, cf. [SSCDPP]
SVD Signature Verification Data, cf. [SSCDPP]. The public key to verify a signature.[ICAO-SAC]
50 Federal Office for Information Security
1340
1345
1350
BSI-CC-PP-0087 (Version 1.01, May 20th, 2015) Reference Documentation
Reference Documentation
CC1 Common Criteria for Information Technology Security Evaluation, Part 1: Introduction
and General Model; CCMB-2012-09-001, 3.1, Revision 4
CC2 Common Criteria for Information Technology Security Evaluation, Part 2: Security
Functional Components; CCMB-2012-09-002, 3.1, Revision 4
CC3 Common Criteria for Information Technology Security Evaluation, Part 3: Security
Assurance Requirements; CCMB-2012-09-003, 3.1, Revision 4
CC4 Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB-2012-09-004 , 3.1, Revision 4
EAC1PP BSI: Common Criteria Protection Profile - Machine Readable Travel Document with
„ICAO Application”, Extended Access Control with PACE (EAC PP),
BSI-CC-PP-0056-V2-2012 v1.3.2 (5. December 2012)
EAC2PP BSI: Common Criteria Protection Profile - ID-Card implementing Extended Access
Control 2 as defined in BSI TR-03110, BSI-CC-PP-0086-2015 v1.01 (May 20th, 2015)
ICAO-SAC ICAO: Technical Report: Supplemental Access Control for Machine Readable Travel
Documents, Version - 1.01, 11. November 2010.
ICAO9303 ICAO: ICAO Doc 9303, Part 1: Machine Readable Passports, Volume 2: Specifications for
Electronically Enabled Passports with Biometric Identification Capability, Sixth Edition -
2006
ICPP Inside Secure, Infineon Technologies AG, NXP Semiconductors Germany GmbH,
STMicroelectronics: Common Criteria Protection Profile - Security IC Platform
Protection Profile with Augmentation Packages, BSI-CC-PP-0084-2014, v1.0 (13.01.2014)
ISO14443 ISO/IEC 14443 Identification cards — Contactless integrated circuit cards,
ISO7816-4 ISO/IEC 7816-4:2013 Identification cards — Integrated circuit cards — Part 4:
Organization, security and commands for interchange,
PACEPP BSI: Common Criteria Protection Profile - Machine Readable Travel Document using
Standard Inspection Procedure with PACE (PACE PP), BSI-CC-PP-0068-V2-2011
SSCDPP CEN: Protection Profiles for Secure Signature Creation Device – Part 2: Device with key
generation, prEN 14169-2:2012, v2.01, 01-2012, BSI-CC-PP-0059-2009-MA-01
TR03110-1 BSI: TR-03110-1 - Advanced Security Mechanisms for Machine Readable Travel
Documents. Part 1 - eMRTDs with BAC/PACEv2 and EACv1, v2.10 (20. March 2012)
TR03110-2 BSI: TR-03110-2 - Advanced Security Mechanisms for Machine Readable Travel
Documents. Part 2 - Extended Access Control Version 2 (EACv2), Password Authenticated
Connection Establishment (PACE), and Restricted Identification (RI) v2.10 (20. March
2012)
TR03110-3 BSI: TR-03110-3 - Advanced Security Mechanisms for Machine Readable Travel
Documents. Part 3 - Common Specifications v2.10 (20. March 2012)
Federal Office for Information Security 51