Protection Profile
for ePassport IC
with SAC (PACE)
and Active Authentication
Version 2.10
January 24, 2022
Passport Division, Consular Affairs Bureau,
Ministry of Foreign Affairs of Japan
JBMIA
This document is a translation of the evaluated and certified protection profile written in Japanese.
Foreword
This Protection Profile (hereinafter "the PP") specifies security requirements for ePassport
IC conforming to the ePassport Standards [Doc 9303] provided by the International Civil
Aviation Organization (ICAO).
ePassport IC assumed in the PP applies to ePassports for supporting the Supplemental
Access Control (SAC) and Active Authentication (AA).
ePassport IC supporting the SAC is required to support both Basic Access Control (BAC)
and Password Authenticated Connection Establishment v2 (PACE v2). However, the BAC
may be disabled using the BAC disable function in phase 3 of the TOE lifecycle, as specified
in 1.2.3 of this PP.
Both BAC and PACE are the means of mutual authentication and Secure Messaging, and
the latter has increased security strength of the session key. In the future, PACE will become
a standard for mutual authentication and Secure Messaging. Note that an ePassport IC is
required to conform to the PP and "Protection Profile for ePassport IC with SAC (BAC+PACE)
and Active Authentication" (hereinafter "the BAC+PACE PP") when the chip, as a TOE, is
capable of BAC function and of disabling BAC function. In this case, BAC function and its
disabling function are evaluated based on the BAC+PACE PP, and the other security
functions are evaluated based on the ST that conforms to the PP. On the other hand, when
an ePassport IC without such functions is defined as a TOE, it is required to conform to only
the PP.
The Active Authentication is to prevent passport forgery that uses a faked ePassport IC by
verifying the authenticity of the unique private key stored in the ePassport IC.
The PP has been prepared based on the rules and formats of Common Criteria (CC) Version
3.1 Revision 5. The developer of ePassport IC that conform to the PP shall prepare a Security
Target (ST) that meets any and all requirements defined in the PP.
ePassport IC should meet overall technical specifications required for ePassport IC in
addition to fulfilling the security functions that meet the PP's requirements. Technical
specifications not involved in the security functions are not defined in the PP, and are
separately provided by the procurer.
Some requirements of the PP include references to standards and materials issued by ICAO
and BSI. These standards and materials are related to cryptographic algorithms and
authentication procedure, and are not included in the CC. The standards and materials are
required for the development of the Target of Evaluation (TOE) that meets the PP.
The PP has been prepared by the JBMIA under a commission from Passport Division,
Consular Affairs Bureau, Ministry of Foreign Affairs of Japan. All contents of the PP are
protected by the copyright of Passport Division, Consular Affairs Bureau, Ministry of Foreign
Affairs of Japan.
[Notes in the PP]
The PP provides various Notes to support preparation of the STs conforming to the PP.
Each Note is supplemental information for readers to properly understand the PP, and is
not intended to constitute provisions or requirements of the PP. However, some Notes are
useful for the readers of the ST, and therefore, the said Notes may be copied to the ST at
the discretion of the ST author. In such cases, the descriptions may be rewritten according
to the context of the ST.
Table of contents
1. PP Introduction......................................................................................................................1
1.1 PP Reference...................................................................................................................1
1.2 TOE Overview..................................................................................................................1
1.2.1 TOE Types..............................................................................................................1
1.2.2 TOE Usage and Main Security Functions..............................................................1
1.2.3 TOE Life Cycle........................................................................................................2
2. Conformance Claim ..............................................................................................................4
2.1 CC Conformance Claim...................................................................................................4
2.2 PP Claim ..........................................................................................................................4
2.3 Package Claim.................................................................................................................4
2.4 Conformance Rationales .................................................................................................4
2.5 Conformance Statement..................................................................................................4
3. Security Problem Definition...................................................................................................5
3.1 Threats .............................................................................................................................5
3.2 Organizational Security Policies ......................................................................................6
3.3 Assumptions.....................................................................................................................8
4. Security Objectives ...............................................................................................................9
4.1 Security Objectives for the TOE.......................................................................................9
4.2 Security Objectives for the Operational Environment....................................................10
4.3 Security Objectives Rationales ......................................................................................10
4.3.1 Correspondence between Security Problem Definition and Security
Objectives.............................................................................................................11
4.3.2 Security Objectives Rationale ..............................................................................11
5. Extended Components Definition .......................................................................................14
5.1 FCS_RND: Random number generation.......................................................................14
6. Security Requirements........................................................................................................15
6.1 Security Functional Requirements.................................................................................15
6.1.1 FCS_ CKM.1p Cryptographic key generation (PACE, session keys)..................16
6.1.2 FCS_CKM.1e Cryptographic key generation (PACE, ephemeral key
pairs).....................................................................................................................16
6.1.3 FCS_CKM.4 Cryptographic key destruction ........................................................16
6.1.4 FCS_COP.1a Cryptographic operation (Active Authentication,
signature generation) ...........................................................................................17
6.1.5 FCS_COP.1h Cryptographic operation (Active Authentication, hash
functions)..............................................................................................................17
6.1.6 FCS_COP.1n Cryptographic operation (Nonce encryption) ................................17
6.1.7 FCS_COP.1e Cryptographic operation (Key agreement) ....................................17
6.1.8 FCS_COP.1hp Cryptographic operation (PACE, hash functions)........................18
6.1.9 FCS_COP.1mp Cryptographic operation (PACE, mutual
authentication)......................................................................................................18
6.1.10 FCS_COP.1sp Cryptographic operation (PACE, Secure Messaging).................18
6.1.11 FCS_RND.1 Quality standards for random numbers ..........................................19
6.1.12 FDP_ACC.1a Subset access control (Issuance procedure)................................19
6.1.13 FDP_ACC.1p Subset access control (PACE)......................................................19
6.1.14 FDP_ACF.1a Security attribute based access control (Issuance
procedure) ............................................................................................................20
6.1.15 FDP_ACF.1p Security attribute based access control (PACE)............................20
6.1.16 FDP_ITC.1 Import of user data without security attributes..................................21
6.1.17 FDP_UCT.1p Basic data exchange confidentiality (PACE) .................................21
6.1.18 FDP_UIT.1p Data exchange integrity (PACE)......................................................21
6.1.19 FIA_AFL.1a Authentication failure handling (Active Authentication
Information Access Key) ......................................................................................21
6.1.20 FIA_AFL.1d Authentication failure handling (Transport key)...............................22
6.1.21 FIA_AFL.1r Authentication failure handling (Readout key)..................................22
6.1.22 FIA_UAU.1 Timing of authentication....................................................................22
6.1.23 FIA_UAU.4 Single-use authentication mechanisms............................................23
6.1.24 FIA_UAU.5 Multiple authentication mechanisms.................................................23
6.1.25 FIA_UID.1 Timing of identification........................................................................23
6.1.26 FMT_MTD.1 Management of TSF data...............................................................23
6.1.27 FMT_SMF.1 Specification of management functions ..........................................24
6.1.28 FMT_SMR.1 Security roles..................................................................................24
6.1.29 FPT_PHP.3 Resistance to physical attack...........................................................24
6.1.30 FTP_ITC.1 Inter-TSF trusted channel..................................................................24
6.2 Security Assurance Requirements.................................................................................25
6.3 Security Requirements Rationale ..................................................................................26
6.3.1 Security Functional Requirements Rationale.......................................................26
6.3.1.1 Tracing between Security Objectives and Security Functional
Requirements .............................................................................................26
6.3.1.2 Justification for the tracing..........................................................................27
6.3.1.3 Dependencies for Security Functional Requirements................................28
6.3.2 Security Assurance Requirements Rationale.......................................................30
7. Glossary ..............................................................................................................................31
7.1 CC Related.....................................................................................................................31
7.2 ePassport Related..........................................................................................................31
8. Reference............................................................................................................................33
1
1. PP Introduction
1.1 PP Reference
Title: Protection Profile for ePassport IC with SAC (PACE) and Active
Authentication
Version number: 2.10
Issue Date: January 24, 2022
Editor: JBMIA
Issuer: Passport Division, Consular Affairs Bureau, Ministry of Foreign Affairs of
Japan
Registration: JISEC C0737
1.2 TOE Overview
1.2.1 TOE Types
The TOE is ePassport IC (including necessary software). This ePassport IC is composed of
IC chip hardware with the contactless communication interface, and basic software (operating
system) and ePassport application program that are installed in the said hardware (hereinafter,
the term an "IC chip" shall mean an "ePassport IC"). An external antenna is connected to the
IC chip for contactless communication purpose, and the IC chip is embedded with the antenna
to constitute a portion of a passport booklet.
1.2.2 TOE Usage and Main Security Functions
A passport is an identification document issued by each country's government or equivalent
public organization, which certifies, for the purpose of international travel, the identity of its
holder, generally in a booklet form (passport booklet). The International Civil Aviation
Organization (ICAO), one of the specialized agencies of the United Nations has provided the
passport booklet specifications. In current passports, an IC chip containing personal
information with digital signature is incorporated in a passport booklet. Since valid digital
signature can be granted only by the official passport issuing authorities, a high level of forgery
prevention can be achieved. However, digital signature is not enough to counter forgery of
copying personal information with authorized signature to store such information on a different
IC chip.
This type of forgery attack can be countered by adding the Active Authentication function to
the IC chip and verifying the authenticity of the IC chip with the use of the said function.
2
The TOE is interfiled in a passport booklet. At immigration, the passport booklet is inspected
using a passport inspection terminal (hereinafter a "terminal"). The information printed on the
passport page (identification page) of the passport booklet, excluding the MRZ (Machine
Readable Zone), which is necessary for immigration inspection is encoded, and printed on the
MRZ using optical characters, which are read by the optical character reader of the terminal.
These information is digitized and stored in the IC chip, i.e., the TOE, with other digitized
information, including facial images. The digital data is read by the terminal through the
contactless communication interface of the TOE.
The antenna used for the TOE to perform contactless communication with the terminal is
connected to the TOE. The TOE operates using wireless signal power supplied from the
terminal.
The operation of the security functions applied to contactless communication with the terminal
shall comply with the PACE, and Active Authentication specifications defined by Part 11 of [Doc
9303].
Attacks on protected data in the TOE include those through the contactless communication
interface of the TOE and those attempting to disclose internal confidential information (Active
Authentication Private Key) through physical attacks on the TOE.
The TOE provides the main security functions, including:
• PACE function (mutual authentication and Secure Messaging);
• Active Authentication support function (prevention of copying the IC chip);
• Write protection function (protection on writing data after issuing a passport);
• Protection function in transport (protection against attacks during transport before
issuing the TOE); and
• Tamper resistance (protection against confidential information leak due to physical
attacks).
1.2.3 TOE Life Cycle
The TOE life cycle is described below to clarify the security requirements for the TOE. As for
the ePassport IC, the life cycle is divided into four phases.
• Phase 1 (Development): Development of IC chip hardware, basic software
(operating system), and application software
• Phase 2 (Manufacturing): Manufacturing of the IC chip (with software installed)
and embedding it together with antenna
• Phase 3 (Personalization): Manufacturing of a passport booklet and writing of
personal data
• Phase 4 (Operational Use): Use of the TOE by the passport holder in operational
environment
Phase 1
Phase 1 is a development phase. In phase 1, threats in the operational environment are not
considered, but proper development security shall be maintained to protect the confidentiality
and integrity of development data. Security related to the TOE in the development phase is
evaluated as the development security in assurance requirements. The TOE security functions
are still not validly operational in the development phase.
3
In Phase 1, the development of the hardware for the IC chip, of operating system, and of
application software for passport may be conducted by separate developers. If the
development of each component to constitute a TOE is conducted at multiple sites, secure
development environment is required for all of the components.
Phase 2
Phase 2 is a manufacturing phase. In Phase 2, the hardware for the IC chip is manufactured,
and operating system and application software for passport are installed in this hardware. A
file object necessary for an ePassport is created in the TOE and an IC chip serial number is
written into the file object. The functional tests of the internal circuit of the IC chip are conducted
on the IC chip itself. After that, it is connected to the antenna, and only the contactless
communication interface becomes available as an external interface. In this phase, threats
from the operational environment are not considered, but proper development security shall
be maintained to protect the confidentiality and integrity of the components of the IC chip.
The TOE in Phase 2 is configured with the transport key, readout key, and Active Authentication
Information Access Key, and delivered to the passport issuing authorities.
Phase 3
The TOE in Phase 3 is put under the control of the passport issuing authorities. Although no
explicit attack against the TOE is assumed under the control of the passport issuing authorities,
the TOE is required to have security functionalities that allows only authorized individuals to
process the TOE, as the organizational security policy. The TOE processes are writing and
reading files in the TOE, updating of the transport keys.
The TOE is interfiled in the ePassport booklet and information necessary for ePassport is
written therein. This information includes the personal information of the passport holder (e.g.
name, date of birth and so on) and the cryptographic key used by the security functions.
After the completion of personalization of all information, the ePassport is issued to the holder
thereof.
Phase 4
Phase 4 is a phase subsequent to the handover of the passport booklet to the end user, i.e.,
the holder thereof. The passport booklet is carried along with the holder thereof and used as
a means to certify the identity of the holder in various situations, including immigration
procedures.
In Phase 4, no information stored in the TOE is altered or deleted. The TOE security function
protects the information necessary for immigration procedures against illicit reading, unless
the information is read by a terminal that can perform the authorized procedures. The private
key for Active Authentication is only used for the internal processing of the TOE and will never
be readout to anywhere other than the TOE. The TOE security functions protect the information
in the TOE against external unauthorized access.
4
2. Conformance Claim
2.1 CC Conformance Claim
CC, to which the PP conforms, are identified. The PP conforms to the following CC Version
3.1 (in Japanese version released by JISEC):
• Part 1: Overview and the General Model; April 2017, Version 3.1 Revision 5 [Japanese
Version 1.0], CCMB-2017-04-001
• Part 2: Security Functional Components; April 2017, Version 3.1 Revision 5 [Japanese
Version 1.0], CCMB-2017-04-002
• Part 3: Security Assurance Components; April 2017, Version 3.1 Revision 5 [Japanese
Version 1.0], CCMB-2017-04-003
• Conformance to CC Part 2: CC part 2 extended
• Conformance to CC Part 3: CC part 3 conformant
2.2 PP Claim
The PP claims no conformance to other PP.
2.3 Package Claim
• In the PP, the assurance requirement package applicable to the TOE is EAL4 augmented.
• Assurance components augmented are ALC_DVS.2 and AVA_VAN.5.
2.4 Conformance Rationales
The PP claims no conformance to other PP and thereby provides no description of
conformance rationales.
2.5 Conformance Statement
Any and all protection profiles and security targets that claim conformance to the PP shall
claim strict conformance.
5
3. Security Problem Definition
This chapter defines security problems related to the TOE. The security problems are defined
from the three aspects: Threats (to be countered by the TOE and/or environment),
Organizational security policies (to be handled by the TOE and/or environment), and
Assumptions (to be met by the environment). The TOE and environment shall address these
security problems in a proper way.
The threats, organizational security policies, and assumptions are named using an identifier
with the prefix "T.", "P.", or "A.", respectively. [Note] is added to individual description as
required.
[Note] is provided for precise understanding of the contents of the PP when referring to it, and
shall not be included in the body of the security problem definition.
3.1 Threats
This section describes threats that a TOE shall counter. These threats shall be countered by
the TOE, its operational environment or combination of these two.
T.Copy
An attacker trying to forge an ePassport may do so by reading personal information along with
digital signature from the TOE and writing the copied data in an IC chip having the same
functionality as that of the TOE. This attack damages the credibility of the entire passport
booklet system including TOEs.
[Note 3-1] If information retrieved from the legitimate TOE is copied into an illicit IC chip, as
information stored in the TOE will be copied together with the associated digital signature,
forgery protection by means of digital signature verification becomes ineffective. Since the
original information can be protected against tampering by means of digital signature, passport
forgery may be detected by means of comparative verification of the facial image. However, it
is difficult to surely detect forged passport just by comparing the facial image.
T.Logical_Attack
In the operational environment after issuing a TOE embedded passport booklet, an attacker
who can read the MRZ data of the passport booklet may try to read confidential information
(Active Authentication Private Key) stored in the TOE through the contactless communication
interface of the TOE. It may also attempt to write to files in the TOE via the same interface.
[Note 3-2] If an attacker has physical access to a passport booklet, the attacker can visually
read personal information printed on the passport booklet and optically read the printed MRZ
data. Since the security functions of the TOE cannot prevent such sort of readings, the
information and data stated above is not included in the threat-related assets to be protected
by the TOE. In other words, the intended meaning of the threat here is an attack aimed to read
confidential information (Active Authentication Private Key) stored in the TOE and write to each
file by having access to the said TOE through the contactless communication interface using
data that the attacker has read from the MRZ.
T.Communication_Attack
6
In the operational environment after issuing a TOE embedded passport booklet, an attacker
who does not know about MRZ data may interfere with the communication between the TOE
and a terminal to disclose and/or alter communication data that should be concealed.
[Note 3-3] If an attacker has physical access to the passport booklet, it is possible to read the
data stored in the IC chip by knowing the MRZ data. Therefore, the attacker mentioned here
is assumed to be unaware of the MRZ data.
T.Physical_Attack
In the operational environment after issuing a TOE embedded passport booklet, an attacker
may attempt to disclose confidential information (Active Authentication Private Key) stored in
the TOE, unlock the state of the locked key, or reactivate a deactivated BAC function by
physical means. This physical means include both of nondestructive attacks made without
impairing the TOE functions and destructive attacks made by destroying part of the TOE to
have mechanical access to the inside of the TOE.
[Note 3-4] An attacker may attempt to read confidential information (Active Authentication
Private Key) or rewrite information stored in the TOE through physical access to the TOE.
Making such a physical attack may impair the security function operated by the TOE program
to provide the original functionality thereof, resulting in potential violation of SFR. The example
of nondestructive attacks includes measurements on leaked electromagnetic wave associated
with the TOE operation and induction of malfunctions in security functions by applying
environmental stress (e.g. changes in temperature, or application of high-energy
electromagnetic fields) to the TOE in operation. The example of destructive attacks shows
those collecting, analyzing, and then disclosing confidential information by probing the internal
circuit. Test pins and power supply pins left in the TOE may be used to make the said attacks.
The TOE that has been subject to a destructive attack may not be reused as an ePassport IC.
Even in such case, however, the disclosed private key may be abused to forge TOEs.
3.2 Organizational Security Policies
This section describes organizational security policies that apply to TOEs and operational
environment. In the PP, the organizational security policies include conformance to the
standards provided by ICAO and conditions required by the passport issuing authorities in
Japan.
P.PACE
In the operational environment after issuing a TOE embedded passport booklet, the TOE shall
allow a terminal to read a certain information from the TOE in accordance with the PACE
procedure defined by Part 11 of [Doc 9303]. This procedure includes mutual authentication
and Secure Messaging between the TOE and terminal devices. TOE files to be read are
EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15, EF.COM, and EF.SOD under the rules stated
above. As for any files under the same rules except the files stated above, the handling of such
files which are not listed in the PP is not defined.
P.Authority
7
In accordance with the passport issuing authorities' policies, the TOE under the control of the
passport issuing authorities shall allow only authorized users (persons who succeeded in
verification of readout key, transport key, or Active Authentication Information Access Key) to
have access to the internal data of the TOE, as shown in Table 1.
Table 1 Internal data of the TOE access control by passport issuing authorities
Authentication status∗1 File subject to access
control
Operation
permitted
Reference: Data to be operated
Successful
authentication with
readout key
EF.DG13∗2
Read
IC chip serial number (entered by TOE manufacturer)
Successful
authentication with
transport key
Transport key file
Write
Transport key data (update of old data)
Password key file Password key
EF.DG1
Read and
Write
MRZ data
EF.DG2 Facial image
EF.DG13∗2 Management data
(Passport number and Booklet management number)
EF.DG14
PACE v2 Security information
Active Authentication hash function information
EF.COM∗3
Common data
EF.SOD
Security data related to Passive Authentication defined by
Part 10 of [Doc 9303].
EF.CardAccess Write PACE v2 Security information
EF.DG15 Read Active Authentication Public Key
Successful
authentication with
Active Authentication
Information Access
Key
EF.DG15
Write
Active Authentication Public Key
Private key file Active Authentication Private Key
∗1
The readout key, transport key, and Active Authentication Information Access Key
are configured by the TOE manufacturer. The transport key can be changed
(updated) by an authorized user. With regard to the files subject to access control
included in this table and files storing the read key and Active Authentication
Information Access Key which may vary the authentication status, reading or writing
of file that is not stated in this table or Notes is prohibited. (The access controls to
information in the TOE from terminals after issuing a TOE embedded passport
booklet to the passport holder, i.e., PACE are separately specified.)
∗2
In EF.DG13, an IC chip serial number has been recorded by the TOE manufacturer,
and the management data is appended to the file by the passport issuing
authorities.
[Note 3-5] All files stated in the table above store user data or TSF data. The transport key file stores TSF
data, and all other files store user data (cryptographic keys are managed as user data). The TSF data file is
not included in files subject to access control stated in Chapter 6, Section "Security Functional Requirements,"
but treated in FMT_MTD.1.
P.Data_Lock
In accordance with the passport issuing authorities' policies, when the TOE detects a failure
in authentication with the transport key, readout key or Active Authentication Information
Access Key, it will permanently disable authentication related to each key, thereby prohibiting
reading or writing the file based on successful authentication thereof. Table 1 shows the
relationship between the key used for authentication and its corresponding file in the TOE.
8
3.3 Assumptions
This section describes assumptions to be addressed in the operational environment of TOEs.
These assumptions need to be true for TOEs' security functionality becomes effective.
A.Administrative_Env
The TOE that was delivered from the TOE manufacturer to the passport issuing authorities
and is under the control of the authorities shall be securely controlled and go through an
issuing process until it is finally issued to the passport holder.
A.PKI
The passport inspection authorities of the receiving states can verify the authenticity of the
information digitally signed by the passport issuer and stored in the TOE (including the public
key for active authentication).
9
4. Security Objectives
This chapter describes security objectives for TOEs and its environment for the security
problems described in Chapter 3. Section 4.1 describes the security objectives to be
addressed by the TOEs, while Section 4.2 describes those to be addressed by its environment.
In addition, Section 4.3 describes rationales for the appropriateness of the security objectives
for solving the security problems.
The security objectives for the TOEs and the security objectives for the operational
environment are represented by an identifier with the prefix "O." or "OE." respectively.
4.1 Security Objectives for the TOE
This section describes security objectives that TOEs should address to solve problems with
regard to the threats and organizational security policies that are defined as the security
problems.
O.AA
TOEs shall provide a means to verify the authenticity of the IC chip itself that composes the
TOE in order to prevent the copy of personal information including the digital signature on an
illicit IC chip and the forgery of the passport. This means shall be standardized so as to ensure
the global interoperability of ePassport and, for this purpose, shall support the Active
Authentication defined by Part 11 of [Doc 9303].
O.Logical_Attack
TOEs shall, under any circumstances, prevent confidential information in them (Active
Authentication Private Key) from being externally read through the contactless communication
interface of the TOE. In the operational environment after issuing the passport booklet, writing
to files in the TOE via the interface shall also be prohibited.
O.Physical_Attack
TOEs shall prevent the confidential information (Active Authentication Private Key) within the
TOEs from being disclosed or the information relating to the security from being tampered with
by the attackers using physical means. TOEs shall counter attacks applicable to TOEs
themselves out of known attacks against IC chips, considering physical means including both
nondestructive attacks and destructive attacks.
O.PACE
This security objective applies to the operational environment after issuing the passport
booklet. PACE procedure defined by Part 11 of [Doc 9303], if the terminals require, shall be
used to ensure the global interoperability of the ePassport. This procedure shall be used in the
mutual authentication and Secure Messaging between the TOE and terminals.
Information the terminal reads from the TOE is stored in the EF.DG1, EF.DG2, EF.DG13,
EF.DG14, EF.DG15, EF.COM, and EF.SOD files among the files contained in the rules stated
above. The TOE shall permit only the terminal that has succeeded in mutual authentication to
10
read the files stated above. As for any files under the same rules except the files stated above,
the handling of such files which are not listed in the PP is not defined.
O.Authority
The TOE shall limit users who can access the internal TOE data and their operations, in the
environment under the control of the passport issuing authorities according to Table 1
described in the organizational security policy P.Authority.
O.Data_Lock
The operation of the internal TOE data shall be available only to the authorized user (i.e.,
authorized personnel under the control of the passport issuing authorities or the terminal after
issuing the passport) to prevent illicit reading and writing by any users other than those stated
above. As a means for this purpose, if the TOE detects an authentication failure with the
readout key, transport key, or Active Authentication Information Access Key, it shall be
permanently prohibited to read and to write the internal TOE data permitted according to
authentication related to each of the said keys. This security objective shall also apply in the
event that the passport issuing authorities disable readout key, transport key, or Active
Authentication Information Access Key by causing an authentication failure intentionally before
the TOE is issued to the passport holder. The relationship between the readout key, transport
key, and Active Authentication Information Access Key and their corresponding internal TOE
data is as listed in Table 1 of the organizational security policy P.Authority. After the security
objective O.Data_Lock is achieved, only the access to TOE stated in the security objective
O.PACE is permitted.
4.2 Security Objectives for the Operational Environment
This section describes security objectives that TOEs should address in the operational
environment to solve problems with regard to the threats and organizational security policies
and assumptions defined as the security problems.
OE.Administrative_Env
The TOEs under the control of the passport issuing authorities are subjected to secure
management and treatment until each of these TOEs is delivered to the passport holder
through the issuing procedures.
OE.PKI
In order for the ePassport inspection authorities of the receiving state or organization to verify
the authenticity of information that has been digitally signed by the passport issuing state or
organization and stored in the TOE (i.e., information on the passport holder and the Active
Authentication Public Key), the PKI environment compliant with [Doc 9303] Part 12 shall be
established.
4.3 Security Objectives Rationales
11
This chapter describes rationales for the effectiveness of the security objectives stated above
for individual parameters of the security problem definition. Section 4.3.1 describes that each
of the security objective can be traced back to any of the security problems, while Section
4.3.2 describes that any of the security problems is effectively addressed by the corresponding
security objective.
4.3.1 Correspondence between Security Problem Definition and Security Objectives
Table 2 shows the correspondence between the security problem definition and the security
objectives. As shown in the table, all security objectives can be traced back to one (or more)
item(s) in the security problem definition.
Table 2 Correspondence between security problem definition and security objectives
4.3.2 Security Objectives Rationale
This section describes rationales for the security objectives for the TOE and the operational
environment to thoroughly counter all identified threats, implement organizational security
policies, and also properly meet the assumptions.
T.Copy
If an attacker copies the personal information (with digital signature) read from the TOE to the
IC chip having the same functionality as that of the TOE, the forged passport cannot be
detected through the verification of digital signature. To prevent this attack, the security
objective for the TOE: O.AA, achieves the active authentication that enables verifying the
authenticity of the IC chip itself. This enables the TOE to detect illicit IC chips and prevent the
forgery of passports, thus removing the threat of T.Copy.
Security
objective
O.AA
O.Logical_Attack
O.Physical_Attack
O.PACE
O.Authority
O.Data_Lock
OE.Administrative_Env
OE.PKI
Security problem definition
T.Copy x
T.Logical_Attack x
T.Communication_Attack x
T.Physical_Attack x
P.PACE x
P.Authority x
P.Data_Lock x
A.Administrative_Env x
A.PKI x
12
T.Logical_Attack
The security objective for the TOE: O.Logical_Attack makes it possible to prohibit reading
confidential information (Active Authentication Private Key) in the TOE through the contactless
communication interface of the TOE, under any circumstances. In the operational environment
after issuing the passport booklet, writing to files in the TOE via the interface is also prohibited.
Thus the threat of T.Logical_Attack is removed.
T.Communication_Attack
The security objectives for the TOE: O.PACE makes it possible to use a secure communication
path for the communication between the terminals and the TOE. Thus the threat of disclosure
and alteration of the communication data of T.Communication_Attack can be diminished to an
adequate level for the practical use.
T.Physical_Attack
The security objective for the TOE: O.Physical_Attack makes it possible to counter an attack
to disclose confidential information (Active Authentication Private Key) in the TOE or tamper
security-related information not via the contactless communication interface of the TOE but
physical means. Regarding the physical means, both nondestructive attacks and destructive
attacks are considered, and countermeasures shall be implemented so that the TOE can
counter known attacks against the IC chip. Thus the threat can be diminished to an adequate
level for the practical use.
P.PACE
The security objective for the TOE: O.PACE allows only the authorized personnel (terminal) to
read the internal TOE data through a secure communication path by applying PACE procedure
defined by Part 11 of [Doc 9303]. O.PACE includes all contents of P.PACE, thus the
organizational security policy P.PACE is properly implemented.
P.Authority
The security objective for the TOE: O.Authority provides the contents to directly implement the
organizational security policy P.Authority.
P.Data_Lock
The security objective for the TOE: O.Data_Lock includes the contents required by the
organizational security policy P.Data_Lock and properly implements P.Data_Lock.
A.Administrative_Env
The security objective for the operational environment: OE.Administrative_Env directly
corresponds to the assumption A.Administrative_Env, thus this assumption is met.
13
A.PKI
The security objective for the operational environment: OE.PKI directly corresponds to the
assumption A.PKI, thus this assumption is met.
14
5. Extended Components Definition
The PP defines the following extended components.
5.1 FCS_RND: Random number generation
Family Behaviour
This family defines quality requirements for the generation of random numbers to be used for
cryptographic purposes.
Component levelling
FCS_RND: Random number generation 1
FCS_RND.1 Random number generation requires the random numbers to meet defined
quality standards.
Management: FCS_RND.1
There is no management activity foreseen.
Audit: FCS_RND.1
There is no auditable event foreseen.
FCS_RND.1 Quality standards for random numbers
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_RND.1.1 The TSF shall provide a random number generation mechanism that meets
[assignment: defined quality standard].
15
6. Security Requirements
6.1 Security Functional Requirements
Table 3 shows the list of the security functional requirements (SFRs) defined by the PP.
Table 3 List of SFRs
Chapter No. Identifier name
6.1.1 FCS_CKM.1p Cryptographic key generation (PACE, session keys)
6.1.2 FCS_CKM.1e Cryptographic key generation (PACE, ephemeral key pairs)
6.1.3 FCS_CKM.4 Cryptographic key destruction
6.1.4 FCS_COP.1a Cryptographic operation (Active Authentication, signature generation)
6.1.5 FCS_COP.1h Cryptographic operation (Active Authentication, hash functions)
6.1.6 FCS_COP.1n Cryptographic operation (Nonce encryption)
6.1.7 FCS_COP.1e Cryptographic operation (Key agreement)
6.1.8 FCS_COP.1hp Cryptographic operation (PACE, hash functions)
6.1.9 FCS_COP.1mp Cryptographic operation (PACE, mutual authentication)
6.1.10 FCS_COP.1sp Cryptographic operation (PACE, Secure Messaging)
6.1.11 FCS_RND.1 Quality standards for random numbers
6.1.12 FDP_ACC.1a Subset access control (Issuance procedure)
6.1.13 FDP_ACC.1p Subset access control (PACE)
6.1.14 FDP_ACF.1a Security attribute based access control (Issuance procedure)
6.1.15 FDP_ACF.1p Security attribute based access control (PACE)
6.1.16 FDP_ITC.1 Import of user data without security attributes
6.1.17 FDP_UCT.1p Basic data exchange confidentiality (PACE)
6.1.18 FDP_UIT.1p Data exchange integrity (PACE)
6.1.19 FIA_AFL.1a Authentication failure handling (Active Authentication Information Access Key)
6.1.20 FIA_AFL.1d Authentication failure handling (Transport key)
6.1.21 FIA_AFL.1r Authentication failure handling (Readout key)
6.1.22 FIA_UAU.1 Timing of authentication
6.1.23 FIA_UAU.4 Single-use authentication mechanism
6.1.24 FIA_UAU.5 Multiple authentication mechanisms
6.1.25 FIA_UID.1 Timing of identification
6.1.26 FMT_MTD.1 Management of TSF data
6.1.27 FMT_SMF.1 Specification of management functions
6.1.28 FMT_SMR.1 Security roles
6.1.29 FPT_PHP.3 Resistance to physical attack
6.1.30 FTP_ITC.1 Inter-TSF trusted channel
SFR is defined by performing as-needed operation on the security functional component
defined by CC Part 2. The operation is denoted for each SFR by the following method:
• SFR subject to iteration operation is identified by adding a low-case alphabetic character
such as "a" and a parenthesized brief description showing the purpose of SFR (e.g. "Active
Authentication") after the corresponding component identifier. Note that only one each of
FDP_UCT.1 and FDP_UIT.1 are defined, and are not subject to iteration operations, but
16
exceptionally, "p" is added to the end to match the BAC+PACE PP method.
• The point of assignment or selection operation is shown as [assignment: XXX (italicized)]
or [selection: XXX (italicized)].
• The PP is not refined.
• For the selection operation, items not subject to selection are shown by strike-through
(Strikethrough).
• The PP has some uncompleted operations, which are shown as [assignment: XXX
(Italicized and underlined)]. The ST author shall complete these uncompleted operations.
The following section describes SFRs defined by the PP.
6.1.1 FCS_ CKM.1p Cryptographic key generation (PACE, session keys)
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1p The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [assignment: session key generation
algorithm in PACE specified by Part 11 of [Doc 9303] and [TR-03111]] and specified
cryptographic key sizes [assignment: 256 bits] that meet the following: [assignment:
Standards for session key generation in PACE specified by Part 11 of [Doc 9303]
and [TR-03111]].
6.1.2 FCS_CKM.1e Cryptographic key generation (PACE, ephemeral key pairs)
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1e The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [assignment: Elliptic Curve Key Pair
Generation] and specified cryptographic key sizes [assignment: 384 bits] that meet
the following: [assignment: Standards for the key pair generation specified by [TR-
03111]].
6.1.3 FCS_CKM.4 Cryptographic key destruction
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method [assignment: [selection: method for erasing
cryptographic keys on volatile memory by shutting down power supply, overwriting
with new cryptographic key data, and [assignment: other cryptographic key
destruction method]]] that meets the following: [assignment: none].
[Note 6-1] To meet requirements of 9.8.3 Session Termination in Part 11 of [Doc
9303], the ST author shall repeatedly define this requirement as
17
necessary.
6.1.4 FCS_COP.1a Cryptographic operation (Active Authentication, signature generation)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1a The TSF shall perform [assignment: generation of digital signature for Active
Authentication data] in accordance with a specified cryptographic algorithm
[assignment: ECDSA] and cryptographic key sizes [assignment: 384 bits, 512bits
and 521bits] that meet the following: [assignment: the Digital Signature Standards
specified by [TR-03111]].
[Note 6-2] Only the combination of 384 bits and SHA-384 or that of 512 bits or 521
bit and SHA-512 is permitted as the key sizes for this requirement and
the hash algorithm of FCS_COP.1h.
[Note 6-3] The key length of 384 bits and 521 bits in this requirement assumes
the use of NIST curve, and 512 bits assumes the use of Brainpool curve.
6.1.5 FCS_COP.1h Cryptographic operation (Active Authentication, hash functions)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1h The TSF shall perform [assignment: generation of data for Active Authentication] in
accordance with a specified cryptographic algorithm [assignment: SHA-384 and
SHA-512] and cryptographic key sizes [assignment: none] that meet the following:
[assignment: the Digital Signature Standards specified by [TR-03111]].
6.1.6 FCS_COP.1n Cryptographic operation (Nonce encryption)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1n The TSF shall perform [assignment: nonce encryption] in accordance with a
specified cryptographic algorithm [assignment: AES-CBC] and cryptographic key
sizes [assignment: 256 bits] that meet the following: [assignment: Standards for the
PACE procedure specified by Part 11 of [Doc 9303]].
6.1.7 FCS_COP.1e Cryptographic operation (Key agreement)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
18
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1e The TSF shall perform [assignment: key agreement] in accordance with a specified
cryptographic algorithm [assignment: ECDH] and cryptographic key sizes
[assignment: 384 bits] that meet the following: [assignment: Standards for the PACE
procedure specified by Part 11 of [Doc 9303]].
6.1.8 FCS_COP.1hp Cryptographic operation (PACE, hash functions)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1hp The TSF shall perform [assignment: generation of session keys for PACE] in
accordance with a specified cryptographic algorithm [assignment: SHA-256] and
cryptographic key sizes [assignment: none] that meet the following: [assignment:
Standards for session key generation in PACE specified by Part 11 of [Doc 9303]].
6.1.9 FCS_COP.1mp Cryptographic operation (PACE, mutual authentication)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1mp The TSF shall perform [assignment: authentication token generation and
verification] in accordance with a specified cryptographic algorithm [assignment:
AES-CMAC] and cryptographic key sizes [assignment: 256 bits] that meet the
following: [assignment: Standards for mutual authentication included in PACE
specified by Part 11 of [Doc 9303]].
6.1.10 FCS_COP.1sp Cryptographic operation (PACE, Secure Messaging)
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes or
FDP_ITC.2 Import of user data with security attributes or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1sp The TSF shall perform [assignment: cryptographic operation shown in Table 4] in
accordance with a specified cryptographic algorithm [assignment: cryptographic
algorithm shown in Table 4] and cryptographic key sizes [assignment: cryptographic
key sizes shown in Table 4] that meet the following: [assignment: Standards for
Secure Messaging included in PACE specified by [Doc 9303]].
19
Table 4 Cryptographic mechanisms in Secure Messaging (PACE)
Cryptographic algorithm Cryptographic key sizes Cryptographic operation
AES in CBC mode 256 bits Message encryption and decryption
AES-CMAC 256 bits
Generation and verification of
Message Authentication Code
[Note 6-4] Whether Secure Messaging is permitted or not depends on the type of
commands. Therefore, data encryption and message authentication
codes are not necessarily applied to all commands and responses.
6.1.11 FCS_RND.1 Quality standards for random numbers
Hierarchical to: No other components.
Dependencies: No dependencies
FCS_RND.1.1 The TSF shall provide a random number generation mechanism that meets the
following: [assignment: defined quality standard].
[Note 6-5] See documents such as BSI AIS20, BSI AIS31, NIST SP800-90,
ISO/IEC 18031 for information on quality standards for random
numbers.
[Note 6-6] When implementing ECDSA calculation defined by FCS_COP.1a with
high-level software, the ST author shall iterate this requirement for the
quality of random numbers generated in the calculation process.
6.1.12 FDP_ACC.1a Subset access control (Issuance procedure)
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1a The TSF shall enforce the [assignment: Issuance procedure access control SFP]
on [assignment: Subject [User process], Objects [Files shown in Table 1 of
Organizational security policy P.Authority] and List of operations among subjects
and objects addressed by SFP [Data Input/Output operation to/from object]].
6.1.13 FDP_ACC.1p Subset access control (PACE)
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1p The TSF shall enforce the [assignment: PACE SFP] on [assignment: Subject
[Process on behalf of terminal], Objects [Files EF.DG1, EF.DG2, EF.DG13, EF.DG14,
EF.DG15, EF.COM, EF.SOD, password key file, basic access key file, transport key
file, and private key file] and list of operations among subjects and objects
addressed by SFP [Reading data from object]].
[Note 6-7] Files other than those listed above are also defined by [Doc 9303].
When a procurer in any country other than Japan uses the PP, the said
files may need to be added. Even when the PP or ST author adds the
files to objects to make a change to SFR of the PP, strict conformance
to the PP will be maintained as far as the SFRs of the PP are met.
20
However, to add any object and its operation for ST preparation, the
need for the agreement of the Procurer of TOE should be considered
even if the strict conformance to the PP is maintained.
[Note 6-8] PACE SFP is the access control policy applied after succeeding in
mutual authentication based on PACE.
6.1.14 FDP_ACF.1a Security attribute based access control (Issuance procedure)
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1a The TSF shall enforce the [assignment: Issuance procedure access control SFP] to
objects based on the following: [assignment: Subject controlled under the indicated
SFP [User process], objects [Files shown in Table 1 of the organizational security
policy P.Authority], and, the SFP-relevant security attributes [Authentication status
shown in Table 1 of the organizational security policy P.Authority] according to each].
FDP_ACF.1.2a The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [assignment: When the
authentication status shown in Table 1 of the organizational security policy
P.Authority is met, an operation to the file associated with the said authentication
status is allowed].
FDP_ACF.1.3a The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [assignment: none].
FDP_ACF.1.4a The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: [assignment: Access to files that are not listed in Table 1 of the
organizational security policy P.Authority is prohibited.].
6.1.15 FDP_ACF.1p Security attribute based access control (PACE)
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialisation
FDP_ACF.1.1p The TSF shall enforce the [assignment: PACE SFP] to objects based on the
following: [assignment: Subject controlled under the indicated SFP [Process on
behalf of terminal], objects [Files EF.DG1, EF.DG2, EF.DG13, EF.DG14, EF.DG15,
EF.COM, EF.SOD basic access key file, transport key file, and private key file], and
the SFP-related security attributes [Authentication status of terminal based on
mutual authentication]].
FDP_ACF.1.2p The TSF shall enforce the following rules to determine if an operation among
controlled subjects and controlled objects is allowed: [assignment: Where the
authentication status of terminal has been successful, subjects are allowed to read
data from objects].
FDP_ACF.1.3p The TSF shall explicitly authorise access of subjects to objects based on the
following additional rules: [assignment: none].
FDP_ACF.1.4p The TSF shall explicitly deny access of subjects to objects based on the following
additional rules: [assignment: Subjects are prohibited to write data to or read data
21
from the transport key file, basic access key file, password key file, and private key
file].
6.1.16 FDP_ITC.1 Import of user data without security attributes
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FMT_MSA.3 Static attribute initialisation
FDP_ITC.1.1 The TSF shall enforce the [assignment: Issuance procedure access control SFP]
when importing user data, controlled under the SFP, from outside of the TOE.
FDP_ITC.1.2 The TSF shall ignore any security attributes associated with the user data when
imported from outside the TOE.
FDP_ITC.1.3 The TSF shall enforce the following rules when importing user data controlled under
the SFP from outside the TOE: [assignment: none].
6.1.17 FDP_UCT.1p Basic data exchange confidentiality (PACE)
Hierarchical to: No other components.
Dependencies: [FTP_ITC.1 Inter-TSF trusted channel or
FTP_TRP.1 Trusted path]
[FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
FDP_UCT.1.1p The TSF shall enforce of [assignment: PACE SFP] to [selection: transmit, receive]
user data in a manner protected from unauthorised disclosure.
6.1.18 FDP_UIT.1p Data exchange integrity (PACE)
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel or
FTP_TRP.1 Trusted path]
FDP_UIT.1.1p The TSF shall enforce the [assignment: PACE SFP] to [selection: transmit, receive]
user data in a manner protected from [selection: modification, deletion, insertion,
replay] errors.
FDP_UIT.1.2p The TSF shall be able to determine, on receipt of user data, whether [selection:
modification, deletion, insertion, replay] has occurred.
6.1.19 FIA_AFL.1a Authentication failure handling (Active Authentication Information Access
Key)
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1a The TSF shall detect when [selection: [assignment: positive integer number], an
administrator configurable positive integer within [assignment: range of acceptable
22
values 1-15]] unsuccessful authentication attempts occur related to [assignment:
authentication with the Active Authentication Information Access Key].
[Note 6-9] Note that an administrator refers to the TOE manufacturer who
configures the number of authentication attempts for Active
Authentication Information Access Key, not the passport issuing
authorities. The same applies to the administrators in FIA_AFL.1.1d
and FIA_AFL.1.1r.
FIA_AFL.1.2a When the defined number of unsuccessful authentication attempts has been
[selection: met, surpassed], the TSF shall [assignment: permanently stop
authentication with the Active Authentication Information Access Key (fix the
authentication status with the Active Authentication Information Access Key to "Not
authenticated yet")].
6.1.20 FIA_AFL.1d Authentication failure handling (Transport key)
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1d The TSF shall detect when [selection: [assignment: positive integer number], an
administrator configurable positive integer within [assignment: range of acceptable
values 1-15]] unsuccessful authentication attempts occur related to [assignment:
authentication with the transport key].
FIA_AFL.1.2d When the defined number of unsuccessful authentication attempts has been
[selection: met, surpassed], the TSF shall [assignment: permanently stop
authentication with the transport key (fix the authentication status with the transport
key to "Not authenticated yet")].
6.1.21 FIA_AFL.1r Authentication failure handling (Readout key)
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1r The TSF shall detect when [selection: [assignment: positive integer number], an
administrator configurable positive integer within [assignment: range of acceptable
values 1-15]] unsuccessful authentication attempts occur related to [assignment:
authentication with the readout key].
FIA_AFL.1.2r When the defined number of unsuccessful authentication attempts has been
[selection: met, surpassed], the TSF shall [assignment: permanently stop
authentication with the readout key (fix the authentication status with the readout
key to "Not authenticated yet")].
6.1.22 FIA_UAU.1 Timing of authentication
Hierarchical to: No other components
Dependencies: FIA_UID.1 Timing of identification
FIA_UAU.1.1 The TSF shall allow [assignment: readout of EF.CardAccess and EF.ATR/INFO], on
behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing
23
any other TSF-mediated actions on behalf of that user.
6.1.23 FIA_UAU.4 Single-use authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to [assignment: mutual
authentication mechanism with the PACE procedure].
6.1.24 FIA_UAU.5 Multiple authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1 The TSF shall provide [assignment: multiple authentication mechanisms shown in
Table 5] to support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to the [assignment:
rules describing how the multiple authentication mechanisms shown in Table 5
provide authentication].
Table 5 Multiple authentication mechanisms
Authentication mechanism name Rule applicable to authentication mechanism
Transport key
Rule of authenticating the authorized personnel of the
passport issuing authorities by verifying transport key that
have been already stored in the TOE
Readout key
Rule of authenticating the authorized personnel of the
passport issuing authorities by verification with readout key
that have been already stored in the TOE
Active Authentication
Information Access Key
Rule of authenticating the authorized personnel of the
passport issuing authorities by verification with Active
Authentication Information Access Key that have been already
stored in the TOE
Mutual authentication
Rule of authenticating terminals according to the mutual
authentication procedure in PACE defined by [Doc 9303]
6.1.25 FIA_UID.1 Timing of identification
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UID.1.1 The TSF shall allow [assignment: readout of EF.CardAccess and EF.ATR/INFO], on
behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
6.1.26 FMT_MTD.1 Management of TSF data
Hierarchical to: No other components.
Dependencies: FMT_SMR.1 Security roles
FMT_SMF.1 Specification of management functions
24
FMT_MTD.1.1 The TSF shall restrict the ability to [selection: change_default, query, modify, delete,
clear, [assignment: other operations]] the [assignment: transport key] to
[assignment: the authorized personnel of the passport issuing authorities].
[Note 6-10]This requirement has to do with the configuration of transport key used
to transport the TOE between locations of the passport issuing
authorities in Phase 3.
6.1.27 FMT_SMF.1 Specification of management functions
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
[assignment: modification of transport key].
6.1.28 FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification
FMT_SMR.1.1 The TSF shall maintain the roles [assignment: authorized personnel of the passport
issuing authorities].
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
6.1.29 FPT_PHP.3 Resistance to physical attack
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_PHP.3.1 The TSF shall resist [assignment: attacks defined by the CC Supporting Documents
related to Smartcards] to the [assignment: hardware of the TOE and software
composing the TSF] by responding automatically such that the SFRs are always
enforced.
[Note 6-11] The supporting documents that are the latest version at the time of the
evaluation for the TOE are applied. The document at the time of PP
issuance is the "Application of Attack Potential to Smartcards and
Similar Devices, Version 3.1, June 2020."
[Note 6-12] Disabling the BAC function may be implemented in the TOE that
conforms to the PP. ST authors should be aware of the existence of
such functions and a potential unauthorized recovery during the TOE
evaluation.
6.1.30 FTP_ITC.1 Inter-TSF trusted channel
Hierarchical to: No other components.
Dependencies: No dependencies.
FTP_ITC.1.1 The TSF shall provide a communication channel between itself and another trusted
IT product that is logically distinct from other communication channels and provides
assured identification of its end points and protection of channel data from
25
modification or disclosure.
FTP_ITC.1.2 The TSF shall permit [selection: the TSF, another trusted IT product] to initiate
communication via the trusted channel.
FTP_ITC.1.3 The TSF shall initiate communication via the trusted channel for [assignment:
reading data from the TOE].
[Note 6-13] Communication between terminal and TSF shall be performed via the
Secure Messaging channel after the secure channel defined by [Doc
9303] has been established.
6.2 Security Assurance Requirements
Security assurance requirements applicable to this TOE are defined by assurance components
shown in Table 6. These components are all included in CC Part 3. Components except
ALC_DVS.2 and AVA_VAN.5 are included in the EAL4 assurance package. ALC_DVS.2 is a
high-level component of ALC_DVS.1 and AVA_VAN.5 is a high-level component of AVA_VAN.3.
The PP applies no operation to all components shown in Table 6.
Table 6 Assurance components
Assurance class Assurance component
Security target evaluation
ASE_CCL.1
ASE_ECD.1
ASE_INT.1
ASE_OBJ.2
ASE_REQ.2
ASE_SPD.1
ASE_TSS.1
Development
ADV_ARC.1
ADV_FSP.4
ADV_IMP.1
ADV_TDS.3
Guidance documents
AGD_OPE.1
AGD_PRE.1
Life- cycle support
ALC_CMC.4
ALC_CMS.4
ALC_DEL.1
ALC_DVS.2
ALC_LCD.1
ALC_TAT.1
Tests
ATE_COV.2
ATE_DPT.1
ATE_FUN.1
ATE_IND.2
Vulnerability assessment AVA_VAN.5
26
6.3 Security Requirements Rationale
6.3.1 Security Functional Requirements Rationale
This chapter describes rationales for that the defined SFRs properly achieve the security
objectives for the TOE.
Section 6.3.1.1 describes that each of the SFRs can be traced back to any of the security
objectives for the TOE, while Section 6.3.1.2 describes that each of the security objectives for
the TOE is properly met by the corresponding effective SFR.
6.3.1.1 Tracing between Security Objectives and Security Functional Requirements
Table 7 shows the SFRs corresponding to the security objectives for the TOE. This table
provides the rationales for the traceability of all SFRs to at least one security objective for the
TOE.
Table 7 Tracing between security objectives for the TOE and SFRs
Security objective
for the TOE
SFR
O.Logical_Attack
O.Physical_Attack
O.AA
O.PACE
O.Authority
O.Data_Lock
FCS_CKM.1p x
FCS_CKM.1e x
FCS_CKM.4 x x
FCS_COP.1a x
FCS_COP.1h x
FCS_COP.1n x
FCS_COP.1e x
FCS_COP.1hp x
FCS_COP.1mp x
FCS_COP.1sp x
FCS_RND.1 x
FDP_ACC.1a x x
FDP_ACC.1p x x
FDP_ACF.1a x x
FDP_ACF.1p x x
FDP_ITC.1 x x x
FDP_UCT.1p x
FDP_UIT.1p x
FIA_AFL.1a x
FIA_AFL.1d x
FIA_AFL.1r x
FIA_UAU.1 x x
FIA_UAU.4 x
FIA_UAU.5 x x
FIA_UID.1 x x
FMT_MTD.1 x
FMT_SMF.1 x
FMT_SMR.1 x
27
FPT_PHP.3 x
FTP_ITC.1 x
6.3.1.2 Justification for the tracing
This section describes rationales for that the security objectives for the TOE are met by their
corresponding SFRs and, at the same time, indicates that individual SFRs have effectiveness
in meeting the security objectives for the TOE.
O.AA
To achieve the security objective O.AA, it shall address the Active Authentication procedure
defined by Part 11 of [Doc 9303]. This Active Authentication is a process for a terminal to
authenticate the IC chip of the TOE, and the TOE itself is not required to provide any
authentication mechanism. The TOE is authenticated by properly responding the
authentication procedure. To meet requirements for the authentication procedure from the
terminal, the TOE incorporates the public key and private key pair, performs cryptographic
operation using the private key defined by FCS_COP.1a, and hashing operation defined by
FCS_COP.1h. The public key and private key pair is imported to the TOE by FDP_ITC.1.
Access control associated with FDP_ITC.1 is defined by FDP_ACC.1a and FDP_ACF.1a.
Destruction of the private key on volatile memory is defined by FCS_CKM.4. The security
objective O.AA is sufficiently achieved by the said SFRs.
O.Logical_Attack
Confidential information (Active Authentication Private Key) subject to protection is stored in
the private key file of the TOE. It is denied for the user process on behalf of the terminal to
read data from the private key file and write to files in the TOE by FDP_ACC.1p and
FDP_ACF.1p applied to the TOE after issuing the TOE embedded passport. The security
objective O.Logical_Attack is sufficiently achieved by the said SFRs.
O.Physical_Attack
Attack scenarios trying to disclose the Active Authentication Private Key that is confidential
information, and to tamper security-related information within the TOE, by physical means are
stated in the list of attacks shown in the FPT_PHP.3 section. The TSF automatically resists the
attacks according to FPT_PHP.3 to protect against the disclosure of the confidential
information. With that, the security objective O.Physical_Attack is sufficiently achieved.
O.PACE
The TOE provides its services to the user who has succeeded in identification and
authentication by FIA_UID.1 and FIA_UAU.1. User authentication requires the mutual
authentication procedure with PACE defined by ICAO, which is defined by FIA_UAU.5. The
mutual authentication procedure requires new authentication data based on random numbers
for each authentication, which is defined by FIA_UAU.4. Likewise, Secure Messaging required
by PACE is defined by the requirements for the protection of transmitted and received data by
FDP_UCT.1p and FDP_UIT.1p, and the requirement of cryptographic communication channels
by FTP_ITC.1. Furthermore, with regard to cryptographic processing required for the PACE
procedure, FCS_COP.1mp defines cryptographic operations necessary for the mutual
authentication procedure and FCS_COP.1sp defines cryptographic operations for Secure
28
Messaging. With regard to the cryptographic keys used for Secure Messaging, FDP_ITC.1
defines the import of password key, FCS_CKM.1e defines the generation of ephemeral key
pairs, FCS_COP.1e defines the key agreement, FCS_CKM.1p and FCS_COP.1hp define the
generation of session keys, FCS_RND.1 defines the generation of random numbers such as
nonce, FCS_COP.1n defines the encryption of nonce, and FCS_CKM.4 defines the destruction
of these keys. In order for only permitted personnel to read given information from the TOE,
rules governing access control with FDP_ACC.1p and FDP_ACF.1p are defined. O.PACE is
sufficiently achieved by the said SFRs.
O.Authority
In writing and reading files in the TOE and updating the transport key at the time of issuance
by the passport issuing authorities, the identification and authentication requirements
FIA_UID.1 and FIA_UAU.1 are applied in order to grant the processing authority only to the
duly authorized user. As for the user authentication mechanisms, FIA_UAU.5 defines the use
of the transport key, readout key, or Active Authentication Information Access Key. If a user is
successfully authenticated by the verification with the key, the user is permitted to access to
the internal data of the TOE defined by O.Authority, applying the access control rule
FDP_ACC.1a and FDP_ACF.1a. The user operation includes writing of the authentication key
(transport key), cryptographic keys (Active Authentication Public Key and private key pair, and
password key for Secure Messaging), and other user data in the TOE. The association
between objects and security attributes when writing is defined by FDP_ITC.1. O.Authority
includes updating (rewriting) of the transport keys by the authorized personnel of the passport
issuing authorities and is defined by FMT_MTD.1, FMT_SMF.1, and FMT_SMR.1. The
security objective O.Authority is sufficiently achieved by the said SFRs.
O.Data_Lock
In the event of an authentication failure with the transport key, readout key or Active
Authentication Information Access Key, authentication corresponding to the relevant key is
permanently prohibited, and as the result, the security objective of permanently prohibiting the
reading and writing permissions of the internal data of the TOE obtained by successful
authentication with these keys is sufficiently achieved by the three SFRs: FIA_AFL.1a,
FIA_AFL.1d, and FIA_AFL.1r.
6.3.1.3 Dependencies for Security Functional Requirements
Table 8 shows dependencies and support for the dependencies defined for SFRs.
In the table, the Dependencies column describes dependencies defined for SFRs, and the
Support for the Dependencies column describes by what SFRs the defined dependencies are
satisfied or rationales indicating the justification for non-satisfied dependencies.
Table 8 Dependencies for SFRs
SFR Dependencies Support for the Dependencies
FCS_CKM.1p
[FCS_CKM.2 or
FCS_COP.1]
FCS_CKM.4
FCS_COP.1sp, FCS_COP.1mp, and FCS_CKM.4
support to satisfy the dependencies.
FCS_CKM.1e
[FCS_CKM.2 or
FCS_COP.1]
FCS_CKM.4
FCS_COP.1e and FCS_CKM.4 support to satisfy the
dependencies.
29
FCS_CKM.4
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FDP_ITC.1, FCS_CKM.1p and FCS_CKM.1e
support to satisfy the dependency. FDP_ITC.1
supports keys only on volatile memory.
FCS_COP.1a
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
FDP_ITC.1 supports. FCS_CKM.4 supports keys on
volatile memory. Since the modification and
destruction of keys on nonvolatile memory are
prohibited, FCS_CKM.4 does not apply to.
FCS_COP.1h
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
Since keys do not exist, any requirements do not
apply to.
FCS_COP.1n
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
FDP_ITC.1 supports. FCS.CKM.4 supports on keys
on volatile memory. Since the modification and
destruction of keys on nonvolatile memory are
prohibited, FCS_CKM.4 does not apply to.
FCS_COP.1e
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1e and FCS_CKM.4 support to satisfy
the dependencies.
FCS_COP.1hp
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
Since keys do not exist, any requirements do not
apply to.
FCS_COP.1mp
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1p and FCS_CKM.4 support to satisfy
the dependencies.
FCS_COP.1sp
[FDP_ITC.1 or
FDP_ITC.2 or
FCS_CKM.1]
FCS_CKM.4
FCS_CKM.1p and FCS_CKM.4 support to satisfy
the dependencies.
FCS_RND.1 No dependencies N/A
FDP_ACC.1a FDP_ACF.1 FDP_ACF.1a supports to satisfy the dependency.
FDP_ACC.1p FDP_ACF.1 FDP_ACF.1p supports to satisfy the dependency.
FDP_ACF.1a
FDP_ACC.1
FMT_MSA.3
FDP_ACC.1a supports. Objects are created at initial
configuration, but not created in the operational
environment of the TOE. Therefore, FMT_MSA.3
related to file creation does not apply to.
FDP_ACF.1p
FDP_ACC.1
FMT_MSA.3
FDP_ACC.1p supports. Objects are created at initial
configuration, but not created in the operational
environment of the TOE. Therefore, FMT_MSA.3
related to file creation does not apply to.
FDP_ITC.1
[FDP_ACC.1 or
FDP_IFC.1]
FMT_MSA.3
FDP_ACC.1a supports. Objects are created at initial
configuration, but not created in the operational
environment of the TOE. Therefore, FMT_MSA.3
related to file creation does not apply to.
FDP_UCT.1p
[FTP_ITC.1 or
FTP_TRP.1]
[FDP_ACC.1 or
FDP_IFC.1]
FTP_ITC.1 and FDP_ACC.1p support to satisfy the
dependencies.
FDP_UIT.1p
[FDP_ACC.1 or
FDP_IFC.1]
[FTP_ITC.1 or
FTP_TRP.1]
FTP_ITC.1 and FDP_ACC.1p support to satisfy the
dependencies.
FIA_AFL.1a FIA_UAU.1 FIA_UAU.1 supports to satisfy the dependency.
FIA_AFL.1d FIA_UAU.1 FIA_UAU.1 supports to satisfy the dependency.
FIA_AFL.1r FIA_UAU.1 FIA_UAU.1 supports to satisfy the dependency.
FIA_UAU.1 FIA_UID.1 FIA_UID.1 supports to satisfy the dependency.
FIA_UAU.4 No dependencies N/A
FIA_UAU.5 No dependencies N/A
FIA_UID.1 No dependencies N/A
FMT_MTD.1
FMT_SMR.1
FMT_SMF.1
FMT_SMR.1 and FMT_SMF.1 support to satisfy the
dependencies.
FMT_SMF.1 No dependencies N/A
FMT_SMR.1 FIA_UID.1 FIA_UID.1 supports to satisfy the dependency.
30
FPT_PHP.3 No dependencies N/A
FTP_ITC.1 No dependencies N/A
6.3.2 Security Assurance Requirements Rationale
The security functionality of the TOE is featured by difficulty of TOE (IC chip) forgeries realized
by adoption of the Active Authentication function and strengthening Secure Messaging with
PACE. The security characteristics of the Active Authentication function are achieved by
protecting the internal confidential information (private key) in the TOE. And, the security
characteristics of the strengthened Secure Messaging functionality are achieved by the use of
the session key which possesses sufficient entropy.
Reading out the information kept secret in an IC chip requires advanced means of physical
attacks, and it costs a certain amount of facilities and takes some time to decipher the
strengthened Secure Messaging.
Assuming attackers possessing a high attack potential who are capable of such attacks,
AVA_VAN.5 is required as the security assurance requirement for the vulnerability assessment.
In addition, ALC_DVS.2 is adopted as the development security assurance requirement to
provide stricter protection of development information used for an attack means.
When using the IC chip as the TOE, state of the art technologies are required for SFRs and
design methods to realize such SFRs. However, there are no significant variations in the
security functionality of product, and points to be checked for the vulnerability assessment are
also well-defined. Consequently, EAL4, which is the top level for commercial product but does
not require stringency as high as that for EAL5 whose target application is military use, is
adopted as the development and manufacturing assurance requirements except development
security and vulnerability assessment.
Note that ALC_DVS.2 does not have dependencies on other components, and the
dependencies defined in AVA_VAN.5 are identical to those in AVA_VAN.3 (EAL4). Therefore,
being identical to the EAL4 assurance package in terms of dependencies, dependencies
among the security assurance components shown in Table 6 are all satisfied.
31
7. Glossary
7.1 CC Related
PP Protection Profile
CC Common Criteria; The same contents of the CC are also
established as ISO/IEC 15408 Standards.
ST Security Target
TOE Target of Evaluation
7.2 ePassport Related
ICAO International Civil Aviation Organization
SAC Supplemental Access Control: A name of access control consisting
of mutual authentication and secure messaging for ePassport
supporting two procedures BAC and PACE. Access is possible by
executing either one.
TOE manufacturer A hardware and software vendor, which develops and
manufactures hardware with installed software embedded in
ePassport booklet.
Passport Issuing Authorities
An organization, which manufactures the passport booklet and
configures basic data (e.g. passport number and other
management data, public/private key pair for Active Authentication)
and personal information data to the IC chip. In Japan, the National
Printing Bureau falls under this category.
Active Authentication Security mechanism, by which means the public key and private
key pair based on the public key cryptography system is stored and
the private key is kept secret in the TOE. The public key is
transmitted to an external device trying to authenticate the TOE and
the TOE is authenticated through cryptographic calculation by the
challenge response system using the private key. The Active
Authentication procedure has been defined by [Doc 9303].
Passive Authentication Security mechanism, by which the digital signature signed by the
passport issuing authority is applied to personal information data
stored in the TOE, and the authenticity of data read from the TOE
is verified by using the PKI system provided by the passport issuing
authority. The Passive Authentication procedure has been defined
by [Doc 9303].
Readout key A key which is used at issuing a passport, and is embedded in the
TOE at the manufacturing phase. Refer to Table 1 for operations
which are permitted by successful verification.
Transport key Same as above.
Active Authentication Information Access Key
32
Same as above.
MRZ data Data provided by the optical character in the fixed dimensional area
located in the passport page (identification page) of an ePassport.
Password key file A file storing the key, which is derived from MRZ data, used for
encryption of nonce at the PACE procedure.
PACE v2 security information
Information used for PACE v2 such as cryptographic algorithms
and domain parameters.
33
8. Reference
[Doc 9303] ICAO Doc 9303 Machine Readable Travel Documents Eighth
Edition, 2021
[TR-03111] BSI: Technical Guideline TR-03111: Elliptic Curve Cryptography,
Version 2.0, 2012