PWPW SmartApp-ID 3.1
(IFX)
Security Target
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 2 of 106 Version 3.1.19.0
This page is intentionally left blank.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 3 of 106
Table of contents
List of tables.........................................................................................................7
1 Introduction.................................................................................................8
1.1 References ...................................................................................................................... 8
1.1.1 Security Target reference............................................................................................. 8
1.1.2 Target of evaluation reference ..................................................................................... 8
1.2 Intended usage................................................................................................................ 8
1.3 Target of evaluation........................................................................................................ 8
1.3.1 Overview...................................................................................................................... 8
1.3.2 TOE definition ........................................................................................................... 10
1.3.3 TOE usage and security features for operational use................................................. 10
1.3.4 Life cycle.................................................................................................................... 13
1.3.4.1 Phase 1: Development ............................................................................................. 13
1.3.4.2 Phase 2: Manufacturing ........................................................................................... 14
1.3.4.3 Phase 3: Personalization of the travel document ..................................................... 15
1.3.4.4 Phase 4: Operational use.......................................................................................... 15
1.3.5 Non-TOE hardware/software/firmware required by the TOE ................................... 16
2 Conformance claims..................................................................................18
2.1 Common Criteria conformance claims......................................................................... 18
2.2 Protection profile claims............................................................................................... 18
2.3 Package claim............................................................................................................... 18
2.4 Conformance claims rationale...................................................................................... 18
3 Security problem definition......................................................................20
3.1 Assets............................................................................................................................ 20
3.2 Subjects......................................................................................................................... 21
3.3 Threats .......................................................................................................................... 22
3.4 Organizational security policies ................................................................................... 25
3.5 Assumptions ................................................................................................................. 25
4 Security objectives.....................................................................................26
4.1 Security objectives for the target of evaluation............................................................ 26
4.2 Security objectives for the operational environment.................................................... 28
4.3 Security objectives rationale......................................................................................... 28
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 4 of 106 Version 3.1.19.0
5 Extended component definition...............................................................29
6 Security requirements...............................................................................30
6.1 Security functional requirements.................................................................................. 30
6.1.1 Class FCS: Cryptographic Support............................................................................ 30
6.1.1.1 FCS_CKM: Cryptographic key management.......................................................... 30
6.1.1.2 FCS_COP: Cryptographic operation ....................................................................... 33
6.1.1.3 FCS_RND: Generation of random numbers............................................................ 35
6.1.2 Class FIA: Identification and Authentication ............................................................ 36
6.1.2.1 FIA_AFL: Authentication failures .......................................................................... 37
6.1.2.2 FIA_UID: User identification.................................................................................. 37
6.1.2.3 FIA_UAU: User authentication............................................................................... 39
6.1.3 Class FDP: User Data Protection............................................................................... 43
6.1.3.1 FDP_ACC: Access control policy........................................................................... 43
6.1.3.2 FDP_ACF: Access control functions....................................................................... 43
6.1.3.3 FDP_RIP: Residual information protection............................................................. 46
6.1.3.4 FDP_UCT: Inter-TSF user data confidentiality transfer protection........................ 46
6.1.3.5 FDP_UIT: Inter-TSF user data integrity transfer protection ................................... 46
6.1.4 Class FTP: Trusted Path/Channels............................................................................. 47
6.1.4.1 FTP_ITC: Inter-TSF trusted channel....................................................................... 47
6.1.5 Class FAU: Security Audit ........................................................................................ 48
6.1.5.1 FAU_SAS: Audit data storage................................................................................. 48
6.1.6 Class FMT: Security Management ............................................................................ 48
6.1.6.1 FMT_SMF: Specification of management functions .............................................. 48
6.1.6.2 FMT_SMR: Security management roles................................................................. 48
6.1.6.3 FMT_LIM: Limited capabilities and availability.................................................... 49
6.1.6.4 FMT_MTD: Management of TSF data ................................................................... 50
6.1.7 Class FPT: Protection of the Security Functions ....................................................... 54
6.1.7.1 FPT_EMS: TOE emanation..................................................................................... 54
6.1.7.2 FPT_FLS: Fail secure.............................................................................................. 55
6.1.7.3 FPT_TST: TSF self test........................................................................................... 55
6.1.7.4 FPT_PHP: TSF physical protection......................................................................... 56
6.2 Security assurance requirements .................................................................................. 57
6.3 Security requirements rationale.................................................................................... 57
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 5 of 106
7 Target of evaluation summary specification ..........................................58
7.1 SFR to TSF mapping.................................................................................................... 58
7.2 SF.Access ..................................................................................................................... 60
7.3 SF.Random................................................................................................................... 61
7.4 SF.SymmetricAuthentication ....................................................................................... 61
7.5 SF.Trust ........................................................................................................................ 62
7.6 SF.TerminalAuthentication .......................................................................................... 63
7.7 SF.ActiveAuthentication .............................................................................................. 64
7.8 SF.Protection ................................................................................................................ 64
7.9 SF.Configuration .......................................................................................................... 65
8 Statement of compatibility concerning the composite ST.....................66
8.1 Separation of the platform TSF.................................................................................... 66
8.1.1 Security functionalities .............................................................................................. 66
8.1.2 Security functional requirements ............................................................................... 67
8.1.3 Security assurance requirements................................................................................ 74
8.2 Compatibility between the composite ST and the platform ST ................................... 75
8.2.1 Threats........................................................................................................................ 75
8.2.2 Organizational security policies................................................................................. 78
8.2.3 Assumptions............................................................................................................... 79
8.2.4 Security objectives of the TOE .................................................................................. 80
8.2.5 Security objectives of the operational environment................................................... 82
Annex A Supported elliptic curves................................................................85
Annex B Bibliography ....................................................................................86
B.1 Common Criteria documents........................................................................................ 86
B.2 Protection profiles ........................................................................................................ 86
B.3 Travel document specifications.................................................................................... 86
B.4 Platform documentation ............................................................................................... 87
B.5 Cryptographic standards............................................................................................... 87
B.6 Other............................................................................................................................. 88
Annex C Acronyms .........................................................................................89
C.1 Organizations................................................................................................................ 89
C.2 Terms............................................................................................................................ 89
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 6 of 106 Version 3.1.19.0
Annex D Glossary............................................................................................91
D.1 Security evaluation terms ............................................................................................. 91
D.2 Smartcard terms............................................................................................................ 92
D.3 Travel documents terms ............................................................................................... 94
Annex E Cryptographic functionality ..........................................................97
Annex F Revision history.............................................................................103
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 7 of 106
List of tables
Table 1.1: TOE platform components........................................................................................ 9
Table 1.2: e-passport application components ........................................................................... 9
Table 1.3: Guidance documentation components ...................................................................... 9
Table 6.1: Overview on authentication SFR ............................................................................ 36
Table 7.1: Functional requirement to TOE security functionality mapping ............................ 58
Table 7.2: Operations and security conditions supported by the TOE..................................... 60
Table 8.1: Operations and security conditions supported by the TOE..................................... 66
Table 8.2: SFRs mapping......................................................................................................... 69
Table 8.3: Security assurance requirements of the platform ST and composite ST ................ 74
Table 8.4: Threats mapping...................................................................................................... 76
Table 8.5: Organizational security policies mappings ............................................................. 79
Table 8.6: Mapping security objectives of the platform and of the TOE................................. 82
Table 8.7: Mappings of security objectives for the operational environment.......................... 84
Table E.1: Cryptographic functionality.................................................................................... 97
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 8 of 106 Version 3.1.19.0
1 Introduction
1.1 References
1.1.1 Security Target reference
ST title: PWPW SmartApp-ID 3.1 (IFX): Security Target
ST author: Polska Wytwórnia Papierów Wartościowych S.A.
ST version: 3.1.19.0
Evaluation body: TÜV Informationstechnik GmbH (TÜViT)
Certification body: Bundesamt für Sicherheit in der Informationstechnik (BSI)
Evaluation assurance level: EAL4 augmented with the following assurance components
ATE_DPT.2, ALC_DVS.2 and AVA_VAN.5
1.1.2 Target of evaluation reference
TOE identification: PWPW SmartApp-ID 3.1 (IFX)
TOE developer: Polska Wytwórnia Papierów Wartościowych S.A.
TOE certification ID: BSI-DSZ-CC-0898
TOE platform: IFX SLJ52GLA080AL
IFX SLJ52GLA128AL
IFX SLJ52GLA150AL
Platform certification ID: ANSSI-CC-2013/42
TOE hardware: IFX SLE78CLX1600PM-m7820-A11
Hardware certification ID: BSI-DSZ-CC-0829-2012
1.2 Intended usage
The TOE is intended for the usage in travel documents, e.g. e-passports or residence permit
cards.
1.3 Target of evaluation
1.3.1 Overview
This security target defines the security objectives and requirements for the chip of machine
readable travel documents based on the requirements and recommendations of the
International Civil Aviation Organization (ICAO) and EU Commission of Article 6.
It addresses the advanced security methods Password Authenticated Connection
Establishment and Extended Access Control (Chip Authentication + Terminal Authentication)
as defined in [Doc9303], [SAC], [TR03110-1] and [TR03110-3].
If a product is using the BAC-established communication channel, it will not be conformant
to [PP-PACE] and [PP-EAC]. The product implementing the TOE may functionally use BAC,
but, while performing BAC, it is acting outside of security policy defined by these protection
profiles.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 9 of 106
The PWPW SmartApp-ID 3.1 (IFX) comprises of :
 the platform,
 the e-passport application,
 the guidance documentation.
The following platform is used: IFX SLJ52GLA080AL, IFX SLJ52GLA128AL,
IFX SLJ52GLA150AL. The platform is certified according to the Common Criteria for
Evaluation Assurance Level 5+ (ANSSI-CC-2013/42).
The information on the platform components and their certifications are given in Table 1.1.
The e-passport application components are identified in Table 1.2.
The guidance documentation components are identified in Table 1.3.
Table 1.1: TOE platform components
Type Developer Name Certification ID EAL
Chip & crypto
library
IFX SLE78CLX1600PM-m7820-A111
BSI-DSZ-CC-0829-2012 EAL 5+
Operating
system
TL
jTOP INF#46 offered as:
IFX SLJ52GLA080AL
IFX SLJ52GLA128AL
IFX SLJ52GLA150AL
ANSSI-CC-2013/42 EAL 5+
Table 1.2: e-passport application components
Type Developer Name Version
JavaCard applet PWPW SmartApp-ID 3.1.22.0 (IFX)
JavaCard package PWPW SmartApp-common 3.1.21.0 (IFX)
JavaCard package PWPW SmartApp-mrtd 3.1.20.0 (IFX)
Table 1.3: Guidance documentation components
Type Developer Name
Document PWPW PWPW SmartApp-ID 3.1 (IFX): Preparative procedures
Document PWPW PWPW SmartApp-ID 3.1 (IFX): Operational user guidance
Note:
The exact versions of guidance documents are given in the certification report.
1
The chip identification (SLE78CLX1600PM-m7820-M11) given in [jTOP_ST] is incorrect.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 10 of 106 Version 3.1.19.0
The TOE supports the following security protocols/mechanisms specific for travel documents:
1. PACE,
2. Extended Access Control, i.e.:
 Chip Authentication,
 Terminal Authentication,
3. Passive Authentication.
Passive Authentication data is calculated by the TOE environment and stored securely
in the TOE during its personalization.
Additionally the following security protocols/mechanisms are supported:
1. Basic Access Control,
2. Active Authentication.
However Basic Access Control and Active Authentication are out of the TOE scope (i.e. they
are excluded from the evaluation) as they are not covered by the claimed protection profiles.
1.3.2 TOE definition
The Target of Evaluation (TOE) addressed by this security target is an electronic travel
document representing a contactless/contact smart card programmed according to ICAO
Technical Report “Supplemental Access Control” [SAC] (which means amongst others
according to the Logical Data Structure (LDS) defined in [Doc9303]) and additionally
providing the Extended Access Control according to [Doc9303] and [TR03110-1],
respectively. The communication between terminal and chip shall be protected by Password
Authenticated Connection Establishment (PACE) according to [PP-PACE].
The TOE comprises of at least:
 the circuitry of the travel document’s chip (the integrated circuit, IC);
 the IC Dedicated Software with the parts IC Dedicated Test Software and IC Dedicated
Support Software;
 the IC Embedded Software (operating system);
 the e-passport application; and
 the associated guidance documentation.
Developer note:
1. The IC being the part of the TOE is contactless
2. The e-passport application is a single instance of the SmartApp-ID applet – the Java Card
applet developed by PWPW. The TOE does not contain any other applet instance.
1.3.3 TOE usage and security features for operational use
A State or Organization issues travel documents to be used by the holder for international
travel. The traveler presents a travel document to the inspection system to prove his or her
identity. The travel document in context of this security target contains (i) visual (eye
readable) biographical data and portrait of the holder, (ii) a separate data summary (MRZ
data) for visual and machine reading using OCR methods in the machine readable zone
(MRZ) and (iii) data elements on the travel document’s chip according to LDS in case
of contactless machine reading. The authentication of the traveler is based on
(i) the possession of a valid travel document personalized for a holder with the claimed
identity as given on the biographical data page and (ii) biometrics using the reference data
stored in the travel document. The Issuing State or Organization ensures the authenticity
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 11 of 106
of the data of genuine travel documents. The Receiving State trusts a genuine travel document
of an Issuing State or Organization.
For this security target the travel document is viewed as unit of:
1. the physical part of the travel document in form of paper and/or plastic and chip,
it presents visual readable data including (but not limited to) personal data of the travel
document holder:
 the biographical data on the biographical data page of the travel document surface,
 the printed data in the Machine Readable Zone (MRZ), and
 the printed portrait;
2. the logical travel document as data of the travel document holder stored according to the
Logical Data Structure as defined in [Doc9303] as specified by ICAO on the contact
based or contactless integrated circuit, it presents contact-based/contactless readable data
including (but not limited to) personal data of the travel document holder:
 the digital Machine Readable Zone Data (digital MRZ data, EF.DG1),
 the digitized portraits (EF.DG2),
 the biometric reference data of finger(s) (EF.DG3) or iris image(s) (EF.DG4) or both2
,
 the other data according to LDS (EF.DG5 to EF.DG16), and
 the Document Security Object (SOD).
The Issuing State or Organization implements security features of the travel document
to maintain the authenticity and integrity of the travel document and their data. The physical
part of the travel document and the travel document’s chip are identified by the document
number.
The physical part of the travel document is protected by physical security measures
(e.g. watermark, security printing), logical (e.g. authentication keys of the travel document’s
chip) and organizational security measures (e.g. control of materials, personalization
procedures) [Doc9303]. These security measures can include the binding of the travel
document’s chip to the travel document.
The logical travel document is protected in authenticity and integrity by a digital signature
created by the document signer acting for the Issuing State or Organization and the security
features of the travel document’s chip.
The ICAO defines the baseline security methods Passive Authentication and the optional
advanced security methods Basic Access Control to the logical travel document, Active
Authentication of the travel document’s chip, Extended Access Control to and the Data
Encryption of sensitive biometrics as optional security measure in the [Doc9303] and
Password Authenticated Connection Establishment [SAC]. The Passive Authentication
Mechanism is performed completely and independently of the TOE by the TOE environment.
This security target addresses the protection of the logical travel document (i) in integrity
by write-only-once access control and by physical means, and (ii) in confidentiality by the
Extended Access Control Mechanism. This security target addresses the Chip Authentication
2
These biometric reference data are optional according to [Doc9303]. This security target assumes that the
Issuing State or Organization uses this option and protects these data by means of extended access control.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 12 of 106 Version 3.1.19.0
Version 1 described in [TR03110-1] as an alternative to the Active Authentication stated
in [Doc9303].
If BAC is supported by the TOE, the travel document has to be evaluated and certified
separately. This is due to the fact that [PP-BAC] does only consider extended basic attack
potential to the Basic Access Control Mechanism (i.e. AVA_VAN.3).
Developer note:
The evaluated product supports Basic Access Control for the downward compatibility.
However Basic Access Control is not covered by the claimed protection profiles and as such
is out of the TOE scope (it is excluded from the evaluation).
The confidentiality by Password Authenticated Connection Establishment (PACE)
is a mandatory security feature of the TOE. The travel document shall strictly conform to
[PP-PACE]. Note that [PP-PACE] considers high attack potential.
For the PACE protocol according to [SAC], the following steps shall be performed:
1. The travel document's chip encrypts a nonce with the shared password, derived from the
MRZ resp. CAN data and transmits the encrypted nonce together with the domain
parameters to the terminal.
2. The terminal recovers the nonce using the shared password, by (physically) reading the
MRZ resp. CAN data.
3. The travel document's chip and terminal computer perform a Diffie-Hellmann key
agreement together with the ephemeral domain parameters to create a shared secret. Both
parties derive the session keys KMAC and KENC from the shared secret.
4. Each party generates an authentication token, sends it to the other party and verifies the
received token.
After successful key negotiation the terminal and the travel document's chip provide private
communication (secure messaging) [TR03110-1], [SAC].
The protection profile requires the TOE to implement the Extended Access Control as defined
in [TR03110-1]. The Extended Access Control consists of two parts (i) the Chip
Authentication Protocol Version 1 and (ii) the Terminal Authentication Protocol Version 1
(v.1). The Chip Authentication Protocol v.1 (i) authenticates the travel document’s chip to the
inspection system and (ii) establishes secure messaging which is used by Terminal
Authentication v.1 to protect the confidentiality and integrity of the sensitive biometric
reference data during their transmission from the TOE to the inspection system. Therefore
Terminal Authentication v.1 can only be performed if Chip Authentication v.1 has been
successfully executed. The Terminal Authentication Protocol v.1 consists of (i) the
authentication of the inspection system as entity authorized by the Receiving State or
Organization through the Issuing State, and (ii) an access control by the TOE to allow reading
the sensitive biometric reference data only to successfully authenticated authorized inspection
systems. The Issuing State or Organization authorizes the Receiving State by means
of certification the authentication public keys of Document Verifiers who create Inspection
System Certificates.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 13 of 106
The TOE uses the following cryptographic functions provided by the platform:
 Triple-DES in CBC mode with 112 bit keys complaint to [FIPS46-3] and [FIPS81];
 AES in CBC mode with 128, 192 and 256 bit keys complaint to [FIPS197];
 Retail-MAC, i.e. ISO/IEC 9797-1 MAC algorithm 3 with block cipher DES, zero IV
(8 bytes), ISO/IEC 9797-1 padding method 2 and cryptographic key size of 112 complaint
to [ISO9797-1];
 CMAC algorithm complaint to [FIPS197] and [NIST800-38B];
 ECDH key generation with key sizes of 224, 256, 320, 384, 512 and 521 bits compliant
to [TR03111];
 ECDH with key sizes of 224, 256, 320, 384, 512 and 521 bits compliant to [IEEE1363];
 SHA-1 compliant to [FIPS180-2];
 SHA-224 compliant to [FIPS180-2];
 SHA-256 compliant to [FIPS180-2];
 ECDSA with SHA-1, compliant to [ISO15946-1] and [ISO15946-2];
 ECDSA with SHA-224 compliant to [ISO15946-1] and [ISO15946-2];
 ECDSA with SHA-256 compliant to [ISO15946-1] and [ISO15946-2];
 ECDSA with SHA-384 compliant to [ISO15946-1] and [ISO15946-2];
 ECDSA with SHA-512 compliant to [ISO15946-1] and [ISO15946-2].
Elliptic curve operations use the following curves:
 NIST P-224 (secp224r1),
 BrainpoolP224r1,
 NIST P-256 (secp256r1),
 BrainpoolP256r1,
 BrainpoolP320r1,
 NIST P-384 (secp384r1),
 BrainpoolP384r1,
 BrainpoolP512r1,
 NIST P-521 (secp521r1).
Table E.1 of Annex E lists all supported cryptographic algorithms and gives brief information
on their usage.
1.3.4 Life cycle
The TOE life-cycle is described in terms of the four life-cycle phases. (With respect to the
[PP-IC], the TOE life-cycle the life-cycle is additionally subdivided into 7 steps.)
1.3.4.1 Phase 1: Development
(Step1) 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.
Developer note:
IFX is the IC Developer.
Developer note:
1. The IC is developed by IFX.
2. The IC Dedicated Software is developed by IFX.
(Step2) 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
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 14 of 106 Version 3.1.19.0
IC Embedded Software (operating system), the e-passport application and the guidance
documentation associated with these TOE components.
Developer note:
IFX, TL and PWPW are IC Embedded Software developers.
Developer note:
1. The IC Basic Software (crypto library and operating system) is developed by IFX and TL.
2. The IC Application Software (e-passport application) is developed by PWPW.
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 e-passport application and the guidance documentation is securely delivered
to the travel document manufacturer.
1.3.4.2 Phase 2: Manufacturing
(Step3) In a first step the TOE integrated circuit is produced containing the travel document’s
IC Dedicated Software and the parts of the travel document’s IC Embedded Software
in the non-volatile non-programmable memories (ROM). The IC Manufacturer writes the IC
Identification Data onto the chip to control the IC as travel document material during the IC
manufacturing and the delivery process to the travel document manufacturer. The IC is
securely delivered from the IC Manufacturer to the travel document manufacturer.
If necessary the IC manufacturer adds the parts of the IC Embedded Software in the
nonvolatile programmable memories (for instance EEPROM).
Developer note:
IFX is the IC Manufacturer.
(Step4 optional) The travel document manufacturer combines the IC with hardware for the
contact-based/contactless interface in the travel document unless the travel document consists
of the card only.
(Step5) The travel document manufacturer (i) adds the IC Embedded Software or part of it
in the non-volatile programmable memories (for instance EEPROM or FLASH) if necessary,
(ii) creates the e-passport application, and (iii) equips travel document’s chips with
pre-personalization data.
Application note 1 from [PP-PACE]:
Application note 1 from [PP-EAC]:
Creation of the application implies:
 For file based operating systems: the creation of MF and ICAO.DF.
 For Java Card operating systems: the Applet instantiation.
Developer note:
1. The TOE uses Java Card operating system.
2. IFX or Smartrac loads the SmartApp-ID applet into EEPROM of IC and creates the applet
instance.
3. IFX or Smartrac is the travel document manufacturer.
The pre-personalized travel document together with the IC Identifier is securely delivered
from the travel document manufacturer to the Personalization Agent. The travel document
manufacturer also provides the relevant parts of the guidance documentation to the
Personalization Agent.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 15 of 106
1.3.4.3 Phase 3: Personalization of the travel document
(Step6) The personalization of the travel document includes: (i) the survey of the travel
document holder’s biographical data, (ii) the enrolment of the travel document holder
biometric reference data (i.e. the digitized portraits and the optional biometric reference data),
(iii) the personalization of the visual readable data onto the physical part of the travel
document, (iv) the writing of the TOE User Data and TSF Data into the logical travel
document and (v) configuration of the TSF if necessary. The step (iv) is performed by the
Personalization Agent and includes but is not limited to the creation of (i) the digital MRZ
data (EF.DG1), (ii) the digitized portrait (EF.DG2), and (iii) the document security object.
The signing of the document security object by the Document Signer [Doc9303] finalizes the
personalization of the genuine travel document for the travel document holder. The
personalized travel document (together with appropriate guidance for TOE use if necessary) is
handed over to the travel document holder for operational use.
Application note 2 from [PP-EAC] (includes Application note 2 from [PP-PACE]):
The TSF data (data created by and for the TOE, that might affect the operation of the TOE;
cf. [CC-Part1] §92) comprise (but are not limited to) the Personalization Agent
Authentication Key(s), the Terminal Authentication trust anchor, the effective date and the
Chip Authentication Private Key.
Developer note:
The TSF data of the TOE comprise:
 Personalization Agent Key,
 configuration data specifying security mechanism to be activated (e.g. PACE, CA, TA),
 cryptographic key to be used to establish PACE and the elliptic curve identifier,
 Chip Authentication Private Key and the elliptic curve identifier,
 Terminal Authentication trust anchor,
 effective date of the document.
Application note 3 from [PP-PACE]:
Application note 3 from [PP-EAC]:
This security target distinguishes between the Personalization Agent as entity known to the
TOE and the Document Signer as entity in the TOE IT environment signing the document
security object as described in [Doc9303]. This approach allows but does not enforce the
separation of these roles.
1.3.4.4 Phase 4: Operational use
(Step7) The TOE is used as a travel document's chip by the traveler and the inspection
systems in the “Operational Use” phase. The user data can be read according to the security
policy of the Issuing State or Organization and can be used according to the security policy
of the Issuing State but they can never be modified.
Application note 4 from [PP-PACE]:
Application note 4 from [PP-EAC]:
The intention of the PP is to consider at least the phases 1 and parts of phase 2 (i.e. Step1
to Step3) as part of the evaluation and therefore to define the TOE delivery according to CC
after this phase. Since specific production steps of phase 2 are of minor security relevance
(e.g. 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 Issuing State or Organization. In this case the national body
of the Issuing State or Organization is responsible for these specific production steps.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 16 of 106 Version 3.1.19.0
Developer note:
1. The TOE is the product intended for local (national) and export projects. That is why, this
evaluation process is limited to Steps 1-3 of the TOE life cycle. Such limitation is
explicitly permitted by the protection profile.
2. If necessary, the evaluation of the other life cycle steps should be done as a separate
process according to needs of the specific Issuing State.
Note that the personalization process and its environment may depend on specific security
needs of an Issuing State or Organization. All production, generation and installation
procedures after TOE delivery up to the “Operational Use” (phase 4) have to be considered
in the product evaluation process under AGD assurance class. Therefore, the security target
has to outline the split up of P.Manufact, P.Personalization and the related security objectives
into aspects relevant before vs. after TOE delivery.
Some production steps, e.g. Step 4 in Phase 2 may also take place in the Phase 3.
1.3.5 Non-TOE hardware/software/firmware required by the TOE
There is no explicit non-TOE hardware, software or firmware required by the TOE to perform
its claimed security features. The TOE is defined to comprise the chip and the complete
operating system and application. Note, the inlay holding the chip as well as the antenna and
the booklet (holding the printed MRZ) are needed to represent a complete travel document,
nevertheless these parts are not inevitable for the secure operation of the TOE.
In order to be powered up and to communicate with the ‘external world’ the TOE needs
a terminal (card reader) supporting the contactless/contact based communication according
to ISO/IEC 14443 and ISO/IEC 7816.
From the logical point of view, the TOE shall be able to recognize the following terminal
types, which, hence, shall be available:
 Basic Inspection System with PACE,
 Extended Inspection System.
The TOE shall require terminals to evince possessing authorization information (a shared
secret) before access according to [Doc9303], option ‘PACE’ is granted. To authenticate
a terminal as a basic inspection system with PACE, Standard Inspection Procedure must be
used.
In scope of [PP-PACE] the following types of inspection systems shall be distinguished:
 BIS-PACE: Basic Inspection System3
with PACE4
,
 BIS-BAC: Basic Inspection System with BAC5
.
Moreover, [PP-EAC] introduces another type of inspection systems, i.e. EIS: Extended
Inspection System.
Developer note:
Definitions of above inspection system types are cited in D.3.
[PP-PACE] defines security policy for the usage of only Basic Inspection System with PACE
(BIS-PACE) in the context of the e-passport application. Using other types of inspection
systems and terminals is out of the scope of [PP-PACE]. Some developers might decide to
3
Basic Inspection Systems always uses Standard Inspection Procedure
4
SIP with PACE means: PACE and passive authentication with SOD
5
SIP with BAC means: BAC and passive authentication with SOD. It is commensurate with BIS in [PP-PACE];
i.e. the terminal proven the possession of MRZ optically read out from the plastic part of the card.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 17 of 106
implement their products being downwardly compatible with ICAO-terminals6
, so that they
also functionally support Basic Access Control (BAC). However, any product using BAC will
not be conformant to [PP-PACE]; i.e. a product implementing the TOE may functionally use
BAC, but, while performing BAC, they are acting outside of security policy defined by [PP-
PACE]. Therefore, organizations being responsible for the operation of inspection systems
shall be aware of this context.
Application note 5 from [PP-PACE]:
A terminal7
shall always start a communication session using PACE. If successfully, it should
then proceed with passive authentications. If the trial with PACE failed, the terminal may try
to establish a communication session using other valid options as described above.
6
so called non-compliant inspection systems not supporting PACE
7
See [Doc9303] for further details.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 18 of 106 Version 3.1.19.0
2 Conformance claims
2.1 Common Criteria conformance claims
This security target 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
[CC-Part1]
 Common Criteria for Information Technology Security Evaluation, Part 2: Security
functional components; CCMB-2012-09-002; Version 3.1, Revision 4, September 2012
[CC-Part2]
 Common Criteria for Information Technology Security Evaluation, Part 3: Security
assurance requirements; CCMB-2012-09-003; Version 3.1, Revision 4, September 2012
[CC-Part3]
as follows:
 Part 2 extended
 Part 3 conformant
Common Methodology for Information Technology Security Evaluation, Evaluation
methodology; CCMB-2012-09-004; Version 3.1, Revision 4, September 2012 [CC-CEM] has
to be taken into account.
2.2 Protection profile claims
This security target claims strict conformance to the following Common Criteria protection
profiles:
 Common Criteria Protection Profile Machine Readable Travel Document using Standard
Inspection Procedure with PACE (PACE PP), BSI-CC-PP-0068-V2-2011, Version 1.0,
2nd November 2011 [PP-PACE]
 Common Criteria Protection Profile Machine Readable Travel Document with „ICAO
Application", Extended Access Control with PACE (EAC PP), BSI-CC-PP-0056-V2-2012,
version 1.3.2, 5th December 2012 [PP-EAC]
2.3 Package claim
This security target is conformant to the assurance package EAL 4 augmented with the
following assurance components ATE_DPT.2, ALC_DVS.2 and AVA_VAN.5.
2.4 Conformance claims rationale
This security target uses only definitions of assets, threats, organizational security policies and
assumptions given in the claimed protection profiles (see section 3 for details). No definition
is modified. No additional definition is introduced.
This security target uses only security objectives given in the claimed protection profiles (see
section 4 for details). No security objective is modified. No additional security objective is
introduced.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 19 of 106
This security target uses only extended components given in the claimed protection profiles
(see section 5 for details). No extended component is modified. No additional extended
component is introduced.
This security target uses SFRs given in the claimed protection profiles (see section 6 for
details). Only operations of the SFRs (assignment, iteration, selection and refinement)
explicitly permitted by the claimed protection profiles are done. One additional SFR is
introduced, i.e. FCS_CKM.1.1/CAPK. It is done with the strict conformance to [PP-EAC].
All application notes given in the claimed protection profiles are considered and addressed.
Moreover, all application notes requiring ST writer actions are commented with developer
notes.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 20 of 106 Version 3.1.19.0
3 Security problem definition
This security target claims strict conformance to [PP-PACE] and [PP-EAC]. All definitions
of assets, threats, organizational security policies and assumptions given in these protection
profiles are included to the security target. The definitions are taken over as described in the
protection profiles, therefore they are not repeated here.
3.1 Assets
The following definitions of primary assets are included:
 user data stored on the TOE from [PP-PACE]
 user data transferred between the TOE and the terminal connected from [PP-PACE]
 travel document tracing data from [PP-PACE]
 logical travel document sensitive user data from [PP-EAC]
All these primary assets represent User Data in the sense of the CC.
Application note 6 from [PP-PACE]:
Please note that user data include, amongst other, individual-related (personal) data of the
travel document holder which also include his sensitive (i.e. biometric) data. Hence, the
general security policy defined by [PP-PACE] also secures these specific travel document
holder’s data.
Application note 5 from [PP-EAC]:
Due to interoperability reasons [Doc9303] requires that Basic Inspection Systems may have
access to logical travel document data DG1, DG2, DG5 to DG16. The TOE is not in certified
mode, if it is accessed using BAC. Note that the BAC mechanism cannot resist attacks with
high attack potential (cf. [PP-BAC]). If supported, it is therefore recommended to use PACE
instead of BAC. If nevertheless BAC has to be used, it is recommended to perform Chip
Authentication v.1 before getting access to data (except DG14), as this mechanism is resistant
to high potential attacks.
Developer note:
The evaluated product supports BAC to ensure downward compatibility. However BAC is out
of the TOE scope. In order to operate in the certified mode, the PACE shall be used.
The following definitions of secondary assets are included:
 accessibility to the TOE functions and data only for authorized subjects from [PP-PACE]
 genuineness of the TOE from [PP-PACE]
 TOE internal secret cryptographic keys from [PP-PACE]
 TOE internal non-secret cryptographic material from [PP-PACE]
 travel document communication establishment authorization data from [PP-PACE]
 authenticity of the travel document’s chip from [PP-EAC]
The secondary assets represent TSF and TSF-data in the sense of the CC.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 21 of 106
Application note 7 from [PP-PACE]:
Since the travel document does not support any secret travel document holder authentication
data and the latter may reveal, if necessary, his or her verification values of the PACE
password to an authorized person or device, a successful PACE authentication of a terminal
does not unambiguously mean that the travel document holder is using TOE.
Developer note:
Neither the PACE password nor any data derived from the PACE password is revealed by the
TOE.
Application note 8 from [PP-PACE]:
Travel document communication establishment authorization data are represented by two
different entities: (i) reference information being persistently stored in the TOE and
(ii) verification information being provided as input for the TOE by a human user as an
authorization attempt. The TOE shall secure the reference information as well as – together
with the terminal connected8
– the verification information in the ‘TOE ↔ terminal’ channel,
if it has to be transferred to the TOE. Please note that PACE passwords are not to be send to
the TOE.
Developer note:
1. The reference information is securely sent to the TOE during the personalization.
Immediately upon its receiving: (i) the TOE derives the cryptographic key using the
received reference information as a seed, (ii) stores the derived cryptographic key in the
Java Card secure object and (iii) destroys the received reference data.
2. Neither the reference information nor the information derived from it is sent from the
TOE.
3. As the PACE passwords are not sent to the TOE, it is sufficient to protect only
authenticity and integrity of the verification information. It is achieved by using MACs as
specified in [SAC].
Only assets defined in the protection profiles are used in this security target. No additional
asset is introduced.
3.2 Subjects
The following definitions of subjects are included:
 travel document holder from [PP-PACE]
 travel document presenter (traveler) from [PP-PACE]
 terminal from [PP-PACE]9
 basic inspection system with PACE (BIS-PACE) from [PP-PACE]
 document signer (DS) from [PP-PACE]
 country signing certification authority (CSCA) from [PP-PACE]
 personalization agent from [PP-PACE]
 manufacturer from [PP-PACE]
 country verifying certification authority (CVCA) from [PP-EAC]
8
the input device of the terminal
9
This definition is introduced in [PP-PACE] and repeated in [PP-EAC].
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 22 of 106 Version 3.1.19.0
 document verifier (DV) from [PP-EAC]
 inspection system (IS) from [PP-EAC]
 attacker from [PP-EAC]10
Application note 9 from [PP-PACE]:
Since the TOE does not use BAC, a Basic Inspection System with BAC (BIS-BAC) cannot be
recognized by the TOE.
Developer note:
The evaluated product supports BAC for the downward compatibility, but this functionality is
of the TOE scope. It means the evaluated product can recognize BIS-BAC, but it is possible
only when the non-certified mode is used.
Application note 6 from [PP-EAC]:
For definition of Basic Inspection System (BIS) resp. Basic Inspection System with PACE
(BIS-PACE) see [PP-PACE].
Application note 7 from [PP-EAC]:
An impostor is attacking the inspection system as TOE IT environment independent on using
a genuine, counterfeit or forged travel document. Therefore the impostor may use results of
successful attacks against the TOE but the attack itself is not relevant for the TOE.
Only subjects defined in the protection profiles are used in this security target. No additional
subject is introduced.
3.3 Threats
The following definitions of threats are included:
 T.Skimming from [PP-PACE]
 T.Eavesdropping from [PP-PACE]
 T.Tracing from [PP-PACE]
 T.Forgery from [PP-PACE]
 T.Abuse-Func from [PP-PACE]
 T.Information_Leakage from [PP-PACE]
 T.Phys-Tamper from [PP-PACE]
 T.Malfunction from [PP-PACE]
 T.Read_Sensitive_Data from [PP-EAC]
 T.Counterfeit from [PP-EAC]
Application note 10 from [PP-PACE]:
A product using BIS-BAC cannot avert T.Skimming in the context of the security policy
defined in [PP-PACE].
Developer note:
BAC is out of the TOE scope, so the above application note is not relevant for the TOE.
10
This definition is introduced in [PP-PACE] and then refined in [PP-EAC].
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 23 of 106
Application note 11 from [PP-PACE]:
MRZ is printed and CAN is printed or stuck on the travel document. Please note that neither
CAN nor MRZ effectively represent secrets, but are restricted-revealable,
cf. OE.Travel_Document_Holder.
Application note 12 from [PP-PACE]:
A product using BIS-BAC cannot avert T.Eavesdropping in the context of the security policy
defined in [PP-PACE].
Developer note:
BAC is out of the TOE scope, so the above application note is not relevant for the TOE.
Application note 13 from [PP-PACE]:
T.Tracing completely covers and extends T.Chip-ID from [PP-BAC].
Application note 14 from [PP-PACE]:
A product using BAC (whatever the type of the inspection system is: BIS-BAC) cannot avert
T.Tracing in the context of the security policy defined in from [PP-PACE].
Developer note:
BAC is out of the TOE scope, so the above application note is not relevant for the TOE.
Application note 15 from [PP-PACE]:
Since the Standard Inspection Procedure does not support any unique-secret-based
authentication of the travel document’s chip (no Chip Authentication or Active
Authentication), a threat like T.Counterfeit (counterfeiting travel document)11
cannot be
averted by the current TOE.
Developer note:
1. The TOE supports Chip Authentication. It can be used to avert T.Counterfeit.
2. The evaluated product supports also Active Authentication, but this functionality is out of
the TOE scope. Active Authentication can be used to avert T.Counterfeit.
Application note 8 from [PP-EAC]:
T.Forgery from the [PP-PACE] shall be extended by the Extended Inspection System
additionally to the PACE authenticated BIS-PACE being outsmarted by the attacker.
Developer note:
T.Forgery definition resulting from the above application note will be as follows:
T.Forgery Forgery of Data
Adverse action: An attacker fraudulently alters the User Data or/and TSF-data stored
on the travel document or/and exchanged between the TOE and the
terminal connected in order to outsmart the PACE authenticated
BIS-PACE and/or EIS by means of changed travel document holder’s
related reference data (like biographic or biometric data). The attacker
does it in such a way that the terminal connected perceives these
modified data as authentic one.
Threat agent: having high attack potential
Asset: integrity of the travel document
11
Such a threat might be formulated like: ‘An attacker produces an unauthorized copy or reproduction
of a genuine travel document to be used as part of a counterfeit Passport: he or she may generate a new data set
or extract completely or partially the data from a genuine travel document and copy them on another functionally
appropriate chip to imitate this genuine travel document. This violates the authenticity of the travel document
being used for authentication of a travel document presenter as the travel document holder’.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 24 of 106 Version 3.1.19.0
Application note 16 from [PP-PACE]:
Details of the relevant attack scenarios depend, for instance, on the capabilities of the test
features provided by the IC Dedicated Test Software being not specified here.
Application note 17 from [PP-PACE]:
Leakage may occur through emanations, variations in power consumption, I/O characteristics,
clock frequency, or by changes in processing time requirements. This leakage may be
interpreted as a covert channel transmission, but is more closely related to measurement of
operating parameters which may be derived either from measurements of the contactless
interface (emanation) or direct measurements (by contact to the chip still available even for a
contactless chip) and can then be related to the specific operation being performed. Examples
are Differential Electromagnetic Analysis (DEMA) and Differential Power Analysis (DPA).
Moreover the attacker may try actively to enforce information leakage by fault injection
(e.g. Differential Fault Analysis).
Developer note:
The TOE uses security mechanisms provided by the platform (see 1.1.2 for platform details)
to ensure protection against attacks described above.
Application note 18 from [PP-PACE]:
Physical tampering may be focused directly on the disclosure or manipulation of the user data
(e.g. the biometric reference data for the inspection system) or the TSF data
(e.g. authentication key of the travel document) or indirectly by preparation of the TOE to
following attack methods by modification of security features (e.g. to enable information
leakage through power analysis). Physical tampering requires a direct interaction with the
travel document’s internals. Techniques commonly employed in IC failure analysis and IC
reverse engineering efforts may be used. Before that, hardware security mechanisms and
layout characteristics need to be identified. Determination of software design including
treatment of the user data and the TSF data may also be a pre-requisite. The modification may
result in the deactivation of a security function. Changes of circuitry or data can be permanent
or temporary.
Developer note:
The TOE uses security mechanisms provided by the platform (see 1.1.2 for platform details)
to ensure protection against attacks described above.
Application note 19 from [PP-PACE]:
A malfunction of the TOE may also be caused using a direct interaction with elements on the
chip surface. This is considered as being a manipulation (refer to the threat T.Phys-Tamper)
assuming a detailed knowledge about TOE’s internals.
Developer note:
The TOE uses security mechanisms provided by the platform (see 1.1.2 for platform details)
to ensure protection against attacks described above.
Only threats defined in the protection profiles are used in this security target. No additional
threat is introduced.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 25 of 106
3.4 Organizational security policies
The following definitions of organizational security policies are included:
 P.Manufact from [PP-PACE]
 P.Pre-Operational from [PP-PACE]
 P.Card_PKI from [PP-PACE]
 P.Trustworthy_PKI from [PP-PACE]
 P.Terminal from [PP-PACE]
 P.Sensitive_Data from [PP-EAC]
 P.Personalization from [PP-EAC]
Application note 20 from [PP-PACE]:
The description of P.Card_PKI states the responsibilities of involved parties and represents
the logical, but not the physical structure of the PKI. Physical distribution ways shall be
implemented by the involved parties in such a way that all certificates belonging to the PKI
are securely distributed / made available to their final destination, e.g. by using directory
services.
Only organizational security policies defined in the protection profiles are used in this
security target. No additional security policy is introduced.
3.5 Assumptions
The following definitions of assumptions are included:
 A.Passive_Auth from [PP-PACE]
 A.Insp_Sys from [PP-EAC]
 A.Auth_PKI from [PP-EAC]
Only assumptions defined in the protection profiles are used in this security target.
No additional assumption is introduced.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 26 of 106 Version 3.1.19.0
4 Security objectives
This security target claims strict conformance to [PP-PACE] and [PP-EAC]. All definitions
of security objectives given in these protection profiles are included to the security target. The
definitions are taken over as described in the protection profiles, therefore they are not
repeated here.
4.1 Security objectives for the target of evaluation
The following definitions of security objectives for the target of evaluation are included:
 OT.Data_Integrity from [PP-PACE]
 OT.Data_Authenticity from [PP-PACE]
 OT.Data_Confidentiality from [PP-PACE]
 OT.Tracing from [PP-PACE]
 OT.Prot_Abuse-Func from [PP-PACE]
 OT.Prot_Inf_Leak from [PP-PACE]
 OT.Prot_Phys-Tamper from [PP-PACE]
 OT.Prot_Malfunction from [PP-PACE]
 OT.Identification from [PP-PACE]
 OT.AC_Pers from [PP-PACE]
 OT.Sens_Data_Conf from [PP-EAC]
 OT.Chip_Auth_Proof from [PP-EAC]
Application note 21 from [PP-PACE]:
Since the Standard Inspection Procedure does not support any unique-secret-based
authentication of the travel document’s chip (no Chip Authentication), a security objective
like OT.Chip_Auth_Proof (proof of travel document authenticity)12
cannot be achieved by the
current TOE.
Developer note:
The TOE supports Chip Authentication. It shall be used when the proof of travel document
authenticity is needed.
Application note 22 from [PP-PACE]:
OT.Prot_Inf_Leak pertains to measurements with subsequent complex signal processing due
to normal operation of the TOE or operations enforced by an attacker.
Developer note:
The above objective is fulfilled by security mechanisms of the platform (see 1.1.2 for
platform details).
12
Such a security objective might be formulated like: ‘The TOE must enable the terminal connected to verify the
authenticity of the travel document as a whole device as issued by the travel document Issuer (issuing PKI
branch of the travel document Issuer) by means of the Passive and Chip Authentication as defined in [6]’.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 27 of 106
Application note 23 from [PP-PACE]:
The OT.AC_Pers implies that the data of the LDS groups written during personalization for
travel document holder (at least EF.DG1 and EF.DG2) cannot be changed using write access
after personalization.
Developer note:
The TOE permanently blocks writing access at the end of the personalization.
Application note 9 from [PP-EAC]:
The OT.Chip_Auth_Proof implies the travel document’s chip to have (i) a unique identity as
given by the travel document’s Document Number, (ii) a secret to prove its identity by
knowledge i.e. a private authentication key as TSF data. The TOE shall protect this TSF data
to prevent their misuse. The terminal shall have the reference data to verify the authentication
attempt of travel document’s chip i.e. a certificate for the Chip Authentication Public Key that
matches the Chip Authentication Private Key of the travel document’s chip. This certificate is
provided by (i) the Chip Authentication Public Key (EF.DG14) in the LDS defined in
[Doc9303] and (ii) the hash value of DG14 in the Document Security Object signed by the
Document Signer.
Developer note:
1. The Document Number (the unique identity of the document) is stored in the TOE by the
Personalization Agent during the personalization. The Document Number is stored in
DG1 as specified in [Doc9303].
2. The Document Number is protected (as part of DG1) with the Passive Authentication as
specified in [Doc9303].
3. The Chip Authentication Private Key is stored in the TOE by the Personalization Agent
during the personalization.
4. The Chip Authentication Private Key is protected by storing it in a security object
provided by the platform.
5. The Chip Authentication Public Key (the reference data used to verify the authentication
attempt of travel document’s chip) is stored in DG14 as specified in [Doc9303].
6. The Chip Authentication Public Key is protected (as part of DG14) with the Passive
Authentication as specified in [Doc9303].
Only security objectives for the target of evaluation defined in the protection profiles are used
in this security target. No additional security objective is introduced.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 28 of 106 Version 3.1.19.0
4.2 Security objectives for the operational environment
The following definitions of security objectives for the operational environment are included:
 OE.Legislative_Compliance from [PP-PACE]
 OE.Passive_Auth_Sign from [PP-PACE]
 OE.Personalization from [PP-PACE]
 OE.Terminal from [PP-PACE]
 OE.Travel_Document_Holder from [PP-PACE]
 OE.Auth_Key_Travel_Document from [PP-EAC]
 OE.Authoriz_Sens_Data from [PP-EAC]
 OE.Exam_Travel_Document from [PP-EAC]
 OE.Prot_Logical_Travel_Document from [PP-EAC]
 OE.Ext_Insp_Systems from [PP-EAC]
Application note 24 from [PP-PACE]:
OE.Terminal completely covers and extends OE.Exam_MRTD, OE.Passive_Auth_Verif and
OE.Prot_Logical_MRTD from [PP-BAC].
Only security objectives for the operational environment defined in the protection profiles are
used in this security target. No additional security objective is introduced.
4.3 Security objectives rationale
All threats described in this security target are coming from [PP-PACE] and [PP-EAC].
No new threat, no new organization security policy and no new assumption is introduced.
Therefore security objectives rationales given in the protection profiles remain in force.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 29 of 106
5 Extended component definition
This security target claims strict conformance to [PP-PACE] and [PP-EAC]. All definitions
of extended components given in these protection profiles are included to the security target.
The definitions are taken over as described in the protection profiles, therefore they are not
repeated here.
The following definitions of extended components are included:
 FAU_SAS from [PP-PACE]
 FCS_RND from [PP-PACE]
 FMT_LIM from [PP-PACE]
 FPT_EMS from [PP-PACE]
 FIA_API from [PP-EAC]
Application note 25 from [PP-PACE]:
The functional requirements FMT_LIM.1 and FMT_LIM.2 assume existence of two types of
mechanisms (limited capabilities and limited availability) which together shall provide
protection in order to enforce the related policy. This also allows that (i) the TSF is provided
without restrictions in the product in its user environment, but its capabilities are so limited
that the policy is enforced or conversely (ii) the TSF is designed with high functionality, but
is removed or disabled in the product in its user environment. The combination of both the
requirements shall enforce the related policy.
Application note 10 from [PP-EAC]:
The other families of the Class FIA describe only the authentication verification of users’
identity performed by the TOE and do not describe the functionality of the user to prove their
identity. [PP-EAC] defines the family FIA_API in the style of [CC-Part2] from a TOE point
of view.
Only extended components defined in the protection profiles are used in this security target.
No additional extended component is introduced.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 30 of 106 Version 3.1.19.0
6 Security requirements
This section defines the functional requirements for the TOE and the assurance requirements
for the TOE.
Application note 11 from [PP-EAC]:
The Country Verifying Certification Authority identifies a Document Verifier as “domestic”
in the Document Verifier Certificate if it belongs to the same State as the Country Verifying
Certification Authority. The Country Verifying Certification Authority identifies a Document
Verifier as “foreign” in the Document Verifier Certificate if it does not belong to the same
State as the Country Verifying Certification Authority. From travel document’s point of view
the domestic Document Verifier belongs to the issuing State or Organization.
6.1 Security functional requirements
The permitted operations (assignment, iteration, selection and refinement) of the SFR, that
have been made by the PP author are denoted as underlined text.
The permitted operations (assignment, iteration, selection and refinement) of the SFR, that
have been filled in by the ST author are denoted as underlined and italic text.
6.1.1 Class FCS: Cryptographic Support
6.1.1.1 FCS_CKM: Cryptographic key management
FCS_CKM.1/DH_PACE
Cryptographic key generation – Diffie-Hellman for PACE session keys
FCS_CKM.1.1/DH_PACE
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key
generation algorithm ECDH compliant to [TR03111] and specified cryptographic key sizes
of 112, 128, 192, 256 bits that meet the following: [SAC].
Developer note:
1. Session keys of 112 bits length are generated when secure messaging is based
on Triple-DES.
2. Session keys of 128, 192 and 256 bits lengths are generated when secure messaging is
based on AES.
3. The complete list of supported elliptic curves is given in Annex A.
Application note 26 from [PP-PACE]:
The TOE generates a shared secret value K with the terminal during the PACE protocol,
see [SAC]. This protocol may be based on the Diffie-Hellman Protocol compliant to PKCS#3
(i.e. modulo arithmetic based cryptographic algorithm, cf. [PKCS#3]) or on the ECDH
compliant to TR-03111 [TR03111] (i.e. the elliptic curve cryptographic algorithm ECKA,
cf. [SAC] and [TR03111] for details). The shared secret value K is used for deriving the AES
or DES session keys for message encryption and message authentication (PACE-KMAC,
PACE-KEnc) according to [SAC] for the TSF required by FCS_COP.1/PACE_ENC and
FCS_COP.1/PACE_MAC.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 31 of 106
Developer note:
The TOE uses ECDH to generate a shared secret value. Then, the shared secret value is used
for deriving the Triple-DES or AES session keys for message encryption and message
authentication.
Application note 27 from [PP-PACE]:
FCS_CKM.1/DH_PACE implicitly contains the requirements for the hashing functions used
for key derivation by demanding compliance to [SAC].
Developer note:
1. The TOE uses SHA-1 to derive 112 (Triple-DES) and 128 (AES) bits session keys.
2. The TOE uses SHA-256 to derive 192 (AES) and 256 (AES) bits session keys.
FCS_CKM.1/CA
Cryptographic key generation – Diffie-Hellman for Chip Authentication session keys
FCS_CKM.1.1/CA
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key
generation algorithm based on an ECDH protocol and specified cryptographic key sizes
of 112 bits, 128 bits, 192 bits, 256 bits that meet the following: based on an ECDH protocol
compliant to [TR03111].
Developer note:
1. Session keys of 112 bits length are generated when secure messaging is based
on Triple-DES.
2. Session keys of 128, 192 and 256 bits lengths are generated when secure messaging is
based on AES.
3. The complete list of supported elliptic curves is given in Annex A.
Application note 12 from [PP-EAC]:
FCS_CKM.1/CA implicitly contains the requirements for the hashing functions used for key
derivation by demanding compliance to [TR03110-1].
Developer note:
1. The TOE uses SHA-1 to derive 112 (Triple-DES) and 128 (AES) bits session keys.
2. The TOE uses SHA-256 to derive 192 (AES) and 256 (AES) bits session keys.
Application note 13 from [PP-EAC]:
The TOE generates a shared secret value with the terminal during the Chip Authentication
Protocol Version 1, see [TR03110-1]. This protocol may be based on the Diffie-Hellman
Protocol compliant to PKCS#3 (i.e. modulo arithmetic based cryptographic algorithm,
cf. [PKCS#3]) or on the ECDH compliant to TR-03111 (i.e. an elliptic curve cryptography
algorithm) (cf. [TR03111], for details). The shared secret value is used to derive the Chip
Authentication Session Keys used for encryption and MAC computation for secure messaging
(defined in Key Derivation Function [TR03110-1]).
Developer note:
The TOE uses ECDH to generate a shared secret value. Then, the shared secret value is used
for deriving the Triple-DES or AES session keys for message encryption and message
authentication.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 32 of 106 Version 3.1.19.0
Application note 14 from [PP-EAC]:
The TOE shall implement the hash function SHA-1 for the cryptographic primitive to derive
the keys for secure messaging from any shared secrets of the Authentication Mechanisms.
The Chip Authentication Protocol v.1 may use SHA-1 (cf. [TR03110-1]). The TOE may
implement additional hash functions SHA-224 and SHA-256 for the Terminal Authentication
Protocol v.1 (cf. [TR03110-1] for details).
Developer note:
1. The TOE uses SHA-1 to derive 112 (Triple-DES) and 128 (AES) bits session keys for
secure messaging.
2. According to requirements given in the section A.2.3 of [TR03110-3], the bit-length of the
hash function shall be greater or equal to the bit-length of the derived key. That is why,
the Chip Authentication Protocol implemented by the TOE uses SHA-256 to derive
session keys of 192 (AES) and 256 (AES) bits lengths for secure messaging.
3. The Terminal Authentication implemented by the TOE supports SHA-1, SHA-224,
SHA-256, SHA-384 and SHA-512.
Application note 15 from [PP-EAC]:
The TOE shall destroy any session keys in accordance with FCS_CKM.4 from [PP-PACE]
after (i) detection of an error in a received command by verification of the MAC and (ii) after
successful run of the Chip Authentication Protocol v.1. (iii) The TOE shall destroy the PACE
Session Keys after generation of a Chip Authentication Session Keys and changing the secure
messaging to the Chip Authentication Session Keys. (iv) The TOE shall clear the memory
area of any session keys before starting the communication with the terminal in a new
after-reset-session as required by FDP_RIP.1. Concerning the Chip Authentication keys
FCS_CKM.4 is also fulfilled by FCS_CKM.1/CA.
Developer note:
Session keys are cleared by calling the dedicated function provided by the platform once a
secure messaging session is broken due to:
 receiving APDU in a plain text,
 unsuccessful MAC verification,
 unsuccessful APDU decryption,
 establishing new secure messaging keys (starting a new session),
 the applet selection,
 card reset resulting with the applet selection.
FCS_CKM.1/CAPK
Cryptographic key generation – Chip Authentication key pair
FCS_CKM.1.1/CAPK
The TSF shall generate cryptographic keys in accordance with a specified cryptographic key
generation algorithm Generating ECDH / ECDSA keys with Brainpool curve or NIST curve
(for length 521 bits) and specified cryptographic key sizes of 224, 256, 320, 384, 512 and 521
bits that meet the following: [ISO15946-1], [ISO15946-3], [TR03110-1] and [TR03110-3].
Developer note:
The complete list of supported elliptic curves is given in Annex A.
Developer note:
The Chip Authentication key pair can either be generated in the TOE or imported by the
Manufacturer or Personalization Agent (see FMT_MTD.1/CAPK). This SFR has been
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 33 of 106
included as required by [PP-EAC] (see application note after FMT_MTD.1/CAPK). This SFR
has been included in this security target in addition to the SFRs defined by the protection
profiles claimed in clause 2.2. This extension does not conflict with the strict conformance to
the claimed protection profiles.
FCS_CKM.4
Cryptographic key destruction – Session keys
FCS_CKM.4.1
The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key
destruction method physically overwriting the keys with zeros that meets the following: none.
Application note 28 from [PP-PACE]:
The TOE shall destroy the PACE session keys after detection of an error in a received
command by verification of the MAC. The TOE shall clear the memory area of any session
keys before starting the communication with the terminal in a new after-reset-session
as required by FDP_RIP.1.
Developer note:
Session keys are cleared by calling the dedicated function provided by the platform once a
secure messaging session is broken due to:
 receiving APDU in a plain text,
 unsuccessful MAC verification,
 unsuccessful APDU decryption,
 establishing new secure messaging keys (starting a new session),
 the applet selection,
 card reset resulting with the applet selection.
6.1.1.2 FCS_COP: Cryptographic operation
FCS_COP.1/PACE_ENC
Cryptographic operation – Encryption / Decryption AES / 3DES
FCS_COP.1.1/PACE_ENC
The TSF shall perform secure messaging – encryption and decryption in accordance with
a specified cryptographic algorithm Triple-DES and AES in CBC mode and cryptographic key
sizes of 112, 128, 192, 256 bits that meet the following: compliant to [SAC].
Developer note:
1. Session keys of 112 bits length are used for Triple-DES.
2. Session keys of 128, 192 and 256 bits lengths are used for AES.
Application note 29 from [PP-PACE]:
This SFR requires the TOE to implement the cryptographic primitive AES or 3DES for secure
messaging with encryption of transmitted data and encrypting the nonce in the first step
of PACE. The related session keys are agreed between the TOE and the terminal as part of the
PACE protocol according to the FCS_CKM.1/DH_PACE (PACE-KEnc).
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 34 of 106 Version 3.1.19.0
Developer note:
The TOE uses secure messaging implementation provided by the platform (see 1.1.2 for
platform details).
FCS_COP.1/PACE_MAC
Cryptographic operation – MAC
FCS_COP.1.1/PACE_MAC
The TSF shall perform secure messaging – message authentication code in accordance with
a specified cryptographic algorithm Retail-MAC and CMAC and cryptographic key sizes
of 112, 128, 192, 256 bits that meet the following: compliant to [SAC].
Developer note:
1. Retail-MAC and session keys of 112 bits length are used when secure messaging is based
on Triple DES algorithm.
2. CMAC and session keys of 128, 192 and 256 bits lengths are used when secure messaging
is based on AES algorithm.
Application note 30 from [PP-PACE]:
This SFR requires the TOE to implement the cryptographic primitive for secure messaging
with message authentication code over transmitted data. The related session keys are agreed
between the TOE and the terminal as part of either the PACE protocol according to the
FCS_CKM.1/DH_PACE (PACE-KMAC). Note that in accordance with [SAC] the (two-key)
Triple-DES could be used in Retail mode for secure messaging.
Developer note:
The TOE uses secure messaging implementation provided by the platform (see 1.1.2 for
platform details).
FCS_COP.1/CA_ENC
Cryptographic operation – Symmetric Encryption / Decryption
FCS_COP.1.1/CA_ENC
The TSF shall perform secure messaging – encryption and decryption in accordance with
a specified cryptographic algorithm Triple-DES and AES and cryptographic key sizes
of 112, 128, 192, 256 bits that meet the following: [SAC].
Developer note:
1. Session keys of 112 bits length are used for Triple-DES.
2. Session keys of 128, 192 and 256 bits lengths are used for AES.
Application note 16 from [PP-EAC]:
This SFR requires the TOE to implement the cryptographic primitives (e.g. Triple-DES
and/or AES) for secure messaging with encryption of the transmitted data. The keys are
agreed between the TOE and the terminal as part of the Chip Authentication Protocol
Version 1 according to the FCS_CKM.1/CA.
Developer note:
The TOE uses secure messaging implementation provided by the platform (see 1.1.2 for
platform details).
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 35 of 106
FCS_COP.1/CA_MAC
Cryptographic operation – MAC
FCS_COP.1.1/CA_MAC
The TSF shall perform secure messaging – message authentication code in accordance with
a specified cryptographic algorithm Retail-MAC and CMAC and cryptographic key sizes
of 112, 128, 192, 256 bits that meet the following: [SAC].
Developer note:
1. Retail-MAC and session keys of 112 bits length are used when secure messaging is based
on Triple DES algorithm.
2. CMAC and session keys of 128, 192 and 256 bits lengths are used when secure messaging
is based on AES algorithm.
Application note 18 from [PP-EAC]:
This SFR requires the TOE to implement the cryptographic primitive for secure messaging
with encryption and message authentication code over the transmitted data. The key is agreed
between the TSF by Chip Authentication Protocol Version 1 according to the
FCS_CKM.1/CA. Furthermore the SFR is used for authentication attempts of a terminal
as Personalization Agent by means of the authentication mechanism.
Developer note:
The TOE uses secure messaging implementation provided by the platform (see 1.1.2 for
platform details).
FCS_COP.1/SIG_VER
Cryptographic operation – Signature verification by travel document
FCS_COP.1.1/SIG_VER
The TSF shall perform digital signature verification in accordance with a specified
cryptographic algorithm ECDSA with SHA-1, SHA-224, SHA-256, SHA-384, SHA-512
and cryptographic key sizes of 224, 256, 320, 384, 512 and 521 bits that meet the following:
[ISO15946-1], [ISO15946-2] and [FIPS180-2].
Developer note:
The complete list of supported elliptic curves is given in Annex A.
Application note 17 from [PP-EAC]:
Information for the security target author only – no action required.
6.1.1.3 FCS_RND: Generation of random numbers
FCS_RND.1
Quality metric for random numbers
FCS_RND.1.1
The TSF shall provide a mechanism to generate random numbers that meet class DRG.3
according to [AIS20/AIS31].
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 36 of 106 Version 3.1.19.0
Developer note:
Presented below are security functional requirements for the RNG class DRG.3 taken from
[AIS20/AIS31] with selections and assignments made by the author of this security target:
FCS_RNG.1
Random number generation (Class DRG.3)
FCS_RNG.1.1
The TSF shall provide a deterministic random number generator that implements:
(DRG.3.1) If initialized with a random seed using a PTRNG of class PTG.2 as random
source, the internal state of the RNG shall have at least Min-Entropy of 100 bits.
(DRG.3.2) The RNG provides forward secrecy.
(DRG.3.3) The RNG provides backward secrecy even if the current internal state is
known.
FCS_RNG.1.2
The TSF shall provide random numbers that meet:
(DRG.3.4) The RNG, initialized with a random seed during the SmartApp-ID applet
instantiation and reseeding, generates output for which 235
strings of bit length 128 are
mutually different with probability above 1-2-16
.
(DRG.3.5) Statistical test suites cannot practically distinguish the random numbers from
output sequences of an ideal RNG. The random numbers must pass test procedure A
and no additional tests.
Application note 31 from [PP-PACE]:
This SFR requires the TOE to generate random numbers (random nonce) used for the
authentication protocol (PACE) as required by FIA_UAU.4/PACE.
6.1.2 Class FIA: Identification and Authentication
Application note 19 from [PP-EAC]:
The Table 6.1 provides an overview on the authentication mechanisms used.
Table 6.1: Overview on authentication SFR
Name SFR for the TOE
Authentication Mechanism for Personalization Agents FIA_UAU.4/PACE
Chip Authentication Protocol v.1 FIA_API.1
FIA_UAU.5/PACE
FIA_UAU.6/EAC
Terminal Authentication Protocol v.1 FIA_UAU.5/PACE
PACE protocol FIA_UAU.1/PACE
FIA_UAU.5/PACE
FIA_AFL.1/PACE
Passive Authentication FIA_UAU.5/PACE
Note the Chip Authentication Protocol Version 1 as defined in this security target includes:
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 37 of 106
 the asymmetric key agreement to establish symmetric secure messaging keys between the
TOE and the terminal based on the Chip Authentication Public Key and the Terminal
Public Key used later in the Terminal Authentication Protocol Version 1,
 the check whether the TOE is able to generate the correct message authentication code
with the expected key for any message received by the terminal.
The Chip Authentication Protocol v.1 may be used independent of the Terminal
Authentication Protocol v.1. But if the Terminal Authentication Protocol v.1 is used the
terminal shall use the same public key as presented during the Chip Authentication
Protocol v.1.
6.1.2.1 FIA_AFL: Authentication failures
FIA_AFL.1/PACE
Authentication failure handling – PACE authentication using non-blocking
authorization data
FIA_AFL.1.1/PACE
The TSF shall detect when 3 (three) unsuccessful authentication attempt occurs related
to authentication attempts using the PACE password as shared password.
FIA_AFL.1.2/PACE
When the defined number of unsuccessful authentication attempts has been met, the TSF shall
delay each following authentication attempt until the next successful authentication attempt
by approximately 5 (five) seconds.
Application note 32 from [PP-PACE]:
The open assignment operation shall be performed according to a concrete implementation
of the TOE, whereby actions to be executed by the TOE may either be common for all data
concerned (PACE passwords, see [SAC]) or for an arbitrary subset of them or may also
separately be defined for each datum in question. Since all non-blocking authorization data
(PACE passwords) being used as a shared secret within the PACE protocol do not possess
a sufficient entropy13
, the TOE shall not allow a quick monitoring of its behavior (e.g. due
to a long reaction time) in order to make the first step of the skimming attack14
requiring
an attack potential beyond high, so that the threat T.Tracing can be averted in the frame of the
security policy of [PP-PACE]. One of some opportunities for performing this operation might
be ‘consecutively increase the reaction time of the TOE to the next authentication attempt
using PACE passwords’.
6.1.2.2 FIA_UID: User identification
FIA_UID.1/PACE Timing of identification
FIA_UID.1.1/PACE
The TSF shall allow:
13
≥ 100 bits; a theoretical maximum of entropy which can be delivered by a character string is N*ld(C),
whereby N is the length of the string, C – the number of different characters which can be used within the string.
14
guessing CAN or MRZ, see T.Skimming above
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 38 of 106 Version 3.1.19.0
1. to establish a communication channel,
2. carrying out the PACE Protocol according to [SAC],
3. to read the Initialization Data if it is not disabled by TSF according to
FMT_MTD.1/INI_DIS,
4. to carry out the Chip Authentication Protocol v.1 according to [TR03110-1],
5. to carry out the Terminal Authentication Protocol v.1 according to [TR03110-1],
6. none.
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2/PACE
The TSF shall require each user to be successfully identified before allowing any other
TSF-mediated actions on behalf of that user.
Application note 33 from [PP-PACE]:
User identified after a successfully performed PACE protocol is a PACE authenticated
BIS-PACE. Please note that neither CAN nor MRZ effectively represent secrets (but other
PACE passwords may do so), but are restricted-revealable; i.e. it is either the travel document
holder itself or an authorized other person or device (BIS-PACE).
Developer note:
The TOE supports MRZ and CAN only. No other PACE password is supported.
Application note 20 from [PP-EAC]:
The SFR FIA_UID.1/PACE in [PP-EAC] covers the definition in [PP-PACE] and extends it
by EAC aspect 4. This extension does not conflict with the strict conformance to [PP-PACE].
Application note 21 from [PP-EAC]:
In the Phase 2 “Manufacturing of the TOE” the Manufacturer is the only user role known to
the TOE which writes the Initialization Data and/or Pre-personalization Data in the audit
records of the IC. The travel document manufacturer may create the user role Personalization
Agent for transition from Phase 2 to Phase 3 “Personalization of the travel document”. The
users in role Personalization Agent identify themselves by means of selecting the
authentication key. After personalization in the Phase 3 the PACE domain parameters, the
Chip Authentication data and Terminal Authentication Reference Data are written into the
TOE. The Inspection System is identified as default user after power up or reset of the TOE
i.e. the TOE will run the PACE protocol, to gain access to the Chip Authentication Reference
Data and to run the Chip Authentication Protocol Version 1. After successful authentication
of the chip the terminal may identify itself as (i) Extended Inspection System by selection of
the templates for the Terminal Authentication Protocol Version 1 or (ii) if necessary and
available by authentication as Personalization Agent (using the Personalization Agent Key).
Developer note:
1. In the Phase 2 of the life cycle, the Manufacturer is the only user role known to the TOE.
2. Transition from Phase 2 to Phase 3 of the life cycle creates the user role Personalization
Agent and involves permanent blocking of the user role Manufacturer.
3. Transition from Phase 3 to Phase 4 of the life cycle creates the user role Inspection
System and permanently blocks the user role Personalization Agent.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 39 of 106
Application note 22 from [PP-EAC]:
User identified after a successfully performed PACE protocol is a terminal. Please note that
neither CAN nor MRZ effectively represent secrets, but are restricted-revealable; i.e. it is
either the travel document holder itself or an authorized other person or device (Basic
Inspection System with PACE).
Application note 23 from [PP-EAC]:
In the life-cycle phase ‘Manufacturing’ the Manufacturer is the only user role known to the
TOE. The Manufacturer writes the Initialization Data and/or Pre-personalization Data in the
audit records of the IC. Please note that a Personalization Agent acts on behalf of the travel
document issuer under his and CSCA and DS policies. Hence, they define authentication
procedure(s) for Personalization Agents. The TOE must functionally support these
authentication procedures being subject to evaluation within the assurance components
ALC_DEL.1 and AGD_PRE.1. The TOE assumes the user role ‘Personalization Agent’,
when a terminal proves the respective Terminal Authorization Level as defined by the related
policy (policies).
Developer note:
The authentication procedure for Personalization Agents is specified in AGD_PRE.1.
6.1.2.3 FIA_UAU: User authentication
FIA_UAU.1/PACE
Timing of authentication
FIA_UAU.1.1/PACE
The TSF shall allow:
1. to establish a communication channel,
2. carrying out the PACE Protocol according to [SAC] 15
,
3. to read the Initialization Data if it is not disabled by TSF according to
FMT_MTD.1/INI_DIS,
4. to identify themselves by selection of the authentication key,
5. to carry out the Chip Authentication Protocol Version 1 according to [TR03110-1],
6. to carry out the Terminal Authentication Protocol Version 1 according to [TR03110-1],
7. none.
on behalf of the user to be performed before the user is authenticated.
15
travel document identifies itself within the PACE protocol by selection of the authentication key
ephem-PKPICC-PACE
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 40 of 106 Version 3.1.19.0
FIA_UAU.1.2/PACE
The TSF shall require each user to be successfully authenticated before allowing any other
TSF-mediated actions on behalf of that user.
Application note 34 from [PP-PACE]:
The user authenticated after a successfully performed PACE protocol is a PACE authenticated
BIS-PACE. Please note that neither CAN nor MRZ effectively represent secrets (but other
PACE passwords may do so), but are restricted-revealable; i.e. it is either the travel document
holder itself or an authorized other person or device (BIS-PACE). If PACE was successfully
performed, secure messaging is started using the derived session keys (PACE-KMAC,
PACE-KEnc), cf. FTP_ITC.1/PACE.
Application note 24 from [PP-EAC]:
The SFR FIA_UAU.1/PACE. in [PP-EAC] covers the definition in [PP-PACE] and extends it
by EAC aspect 5. This extension does not conflict with the strict conformance
to [PP-PACE].
Application note 25 from [PP-EAC]:
The user authenticated after a successfully performed PACE protocol is a terminal. Please
note that neither CAN nor MRZ effectively represent secrets, but are restricted-revealable;
i.e. it is either the travel document holder itself or an authorized other person or device
(BIS-PACE). If PACE was successfully performed, secure messaging is started using the
derived session keys (PACE-KMAC, PACE-KEnc), cf. FTP_ITC.1/PACE.
FIA_UAU.4/PACE
Single-use authentication mechanisms – Single-use authentication of the Terminals
by the TOE
FIA_UAU.4.1/PACE
The TSF shall prevent reuse of authentication data related to:
1. PACE Protocol according to [SAC],
2. Authentication Mechanism based on Triple-DES,
3. Terminal Authentication Protocol v.1 according to [TR03110-1].
Application note 35 from [PP-PACE]:
For the PACE protocol, the TOE randomly selects a nonce s of 128 bits length being (almost)
uniformly distributed.
Developer note:
As input of a generic mapping function required by the PACE protocol and used by the TOE
has to be of the same length as an elliptic curve base point order, the selected nonce is
extended with the leading zeros to the required length.
Application note 26 from [PP-EAC]:
The SFR FIA_UAU.4.1 in [PP-EAC] covers the definition in [PP-PACE] and extends it by
the EAC aspect 3. This extension does not conflict with the strict conformance to [PP-PACE].
The generation of random numbers (random nonce) used for the authentication protocol
(PACE) and Terminal Authentication as required by FIA_UAU.4/PACE is required by
FCS_RND.1 from [PP-PACE].
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 41 of 106
Application note 27 from [PP-EAC]:
The authentication mechanisms may use either a challenge freshly and randomly generated
by the TOE to prevent reuse of a response generated by a terminal in a successful
authentication attempt. However, the authentication of Personalization Agent may rely on
other mechanisms ensuring protection against replay attacks, such as the use of an internal
counter as a diversifier.
Developer note:
All authentication mechanisms listed in FIA_UAU.4.1/PACE use challenges freshly and
randomly generated by the TOE.
FIA_UAU.5/PACE
Multiple authentication mechanisms
FIA_UAU.5.1/PACE
The TSF shall provide:
1. PACE Protocol according to [SAC],
2. Passive Authentication according to [Doc9303],
3. Secure messaging in MAC-ENC mode according to [SAC],
4. Symmetric Authentication Mechanism based on Triple-DES,
5. Terminal Authentication Protocol v.1 according to [TR03110-1].
to support user authentication.
FIA_UAU.5.2/PACE
The TSF shall authenticate any user’s claimed identity according to the following rules:
1. Having successfully run the PACE protocol the TOE accepts only received commands
with correct message authentication code sent by means of secure messaging with the key
agreed with the terminal by means of the PACE protocol.
2. The TOE accepts the authentication attempt as Personalization Agent by the
Authentication Mechanism with Personalization Agent Key(s).
3. After run of the Chip Authentication Protocol Version 1 the TOE accepts only received
commands with correct message authentication code sent by means of secure messaging
with key agreed with the terminal by means of the Chip Authentication Mechanism v1.
4. The TOE accepts the authentication attempt by means of the Terminal Authentication
Protocol v.1 only if the terminal uses the public key presented during the Chip
Authentication Protocol v.1 and the secure messaging established by the Chip
Authentication Mechanism v.1
5. none.
Application note 36 from [PP-PACE]:
Please note that Passive Authentication does not authenticate any TOE’s user, but provides
evidence enabling an external entity (the terminal connected) to prove the origin of e-passport
application.
Application note 28 from [PP-EAC]:
The SFR FIA_UAU.5.1/PACE in [PP-EAC] covers the definition in [PP-PACE] and extends
it by EAC aspects 4), 5), and 6). The SFR FIA_UAU.5.2/PACE in [PP-EAC] covers the
definition in [PP-PACE] and extends it by EAC aspects 2), 3), 4) and 5). These extensions do
not conflict with the strict conformance to [PP-PACE].
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 42 of 106 Version 3.1.19.0
FIA_UAU.6/PACE
Re-authenticating of Terminal by the TOE
FIA_UAU.6.1/PACE
The TSF shall re-authenticate the user under the conditions each command sent to the TOE
after successful run of the PACE protocol shall be verified as being sent by the PACE
terminal.
Application note 37 from [PP-PACE]:
The PACE protocol specified in [SAC] starts secure messaging used for all commands
exchanged after successful PACE authentication. The TOE checks each command by secure
messaging in encrypt-then-authenticate mode based on CMAC or Retail-MAC, whether
it was sent by the successfully authenticated terminal (see FCS_COP.1/PACE_MAC for
further details). The TOE does not execute any command with incorrect message
authentication code. Therefore, the TOE re-authenticates the terminal connected, if a secure
messaging error occurred, and accepts only those commands received from the initially
authenticated terminal.
Developer note:
1. The TOE uses Retail-MAC or CMAC to verify APDUs protected with secure messaging.
2. Once APDU with incorrect MAC is received, the TOE breaks secure messaging session.
FIA_UAU.6/EAC
Re-authenticating – Re-authenticating of Terminal by the TOE
FIA_UAU.6.1/EAC
The TSF shall re-authenticate the user under the conditions each command sent to the TOE
after successful run of the Chip Authentication Protocol Version 1 shall be verified as being
sent by the Inspection System.
Application note 29 from [PP-EAC]:
The Password Authenticated Connection Establishment and the Chip Authentication Protocol
specified in [Doc9303] include secure messaging for all commands exchanged after
successful authentication of the Inspection System. The TOE checks by secure messaging
in MAC_ENC mode each command based on a corresponding MAC algorithm whether it was
sent by the successfully authenticated terminal (see FCS_COP.1/CA_MAC for further
details). The TOE does not execute any command with incorrect message authentication code.
Therefore the TOE re-authenticates the user for each received command and accepts only
those commands received from the previously authenticated user.
Developer note:
1. The TOE uses Retail-MAC or CMAC to verify APDUs protected with secure messaging.
2. Once APDU with incorrect MAC is received, the TOE breaks secure messaging session.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 43 of 106
FIA_API.1
Authentication Proof of Identity
FIA_API.1.1
The TSF shall provide a Chip Authentication Protocol Version 1 according to [TR03110-1]
to prove the identity of the TOE.
Application note 30 from [PP-EAC]:
This SFR requires the TOE to implement the Chip Authentication Mechanism v.1 specified
in [TR03110-1]. The TOE and the terminal generate a shared secret using the Diffie-Hellman
Protocol (DH or ECDH) and two session keys for secure messaging in ENC_MAC mode
according to [Doc9303]. The terminal verifies by means of secure messaging whether the
travel document’s chip was able or not to run his protocol properly using its Chip
Authentication Private Key corresponding to the Chip Authentication Key (EF.DG14).
Developer note:
The TOE implements the Chip Authentication Mechanism v.1 based on ECDH.
6.1.3 Class FDP: User Data Protection
6.1.3.1 FDP_ACC: Access control policy
FDP_ACC.1/TRM
Subset access control – Terminal Access
FDP_ACC.1.1/TRM
The TSF shall enforce the Access Control SFP on terminals gaining access to the User Data
stored in the travel document and data stored in EF.SOD of the logical travel document.
Application note 38 from [PP-PACE]:
Information for the security target author only – no action required.
Application note 31 from [PP-EAC]:
The SFR FIA_ACC.1.1 in [PP-EAC] covers the definition in [PP-PACE] and extends it by
data stored in EF.SOD of the logical travel document. This extension does not conflict with
the strict conformance to [PP-PACE].
6.1.3.2 FDP_ACF: Access control functions
FDP_ACF.1/TRM
Security attribute based access control – Terminal Access
FDP_ACF.1.1/TRM
The TSF shall enforce the Access Control SFP to objects based on the following:
1. Subjects:
a. Terminal,
b. BIS-PACE,
c. Extended Inspection System;
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 44 of 106 Version 3.1.19.0
2. Objects:
a. data in EF.DG1, EF.DG2 and EF.DG5 to EF.DG16 , EF.SOD and EF.COM of the
logical travel document,
b. data in EF.DG3 of the logical travel document,
c. data in EF.DG4 of the logical travel document,
d. all TOE intrinsic secret cryptographic keys stored in the travel document16
;
3. Security attributes:
a. Authentication status of terminals,
b. Terminal Authentication v.1,
c. Authorization of the Terminal.
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:
1. A BIS-PACE is allowed to read data objects from FDP_ACF.1/TRM according to [SAC]
after a successful PACE authentication as required by FIA_UAU.1/PACE.
FDP_ACF.1.3/TRM
The TSF shall explicitly authorize access of subjects to objects based on the following
additional rules: none.
FDP_ACF.1.4/TRM
The TSF shall explicitly deny access of subjects to objects based on the following additional
rules:
1. Any terminal being not authenticated as PACE authenticated BIS-PACE is not allowed
to read, to write, to modify, to use any User Data stored on the travel document.
2. Terminals not using secure messaging are not allowed to read, to write, to modify, to use
any data stored on the travel document.
3. Any terminal being not successfully authenticated as Extended Inspection System with the
Read access to DG 3 (Fingerprint) granted by the relative certificate holder authorization
encoding is not allowed to read the data objects 2b) of FDP_ACF.1.1/TRM.
4. Any terminal being not successfully authenticated as Extended Inspection System with the
Read access to DG 4 (Iris) granted by the relative certificate holder authorization encoding
is not allowed to read the data objects 2c) of FDP_ACF.1.1/TRM.
5. Nobody is allowed to read the data objects 2d) of FDP_ACF.1.1/TRM.
6. Terminals authenticated as CVCA or as DV are not allowed to read data in the EF.DG3
and EF.DG4.
Application note 39 from [PP-PACE]:
Information for the security target author only – no action required.
Application note 40 from [PP-PACE]:
Please note that the Document Security Object (SOD) stored in EF.SOD (see [Doc9303]) does
not belong to the user data, but to the TSF-data. The Document Security Object can be read
out by the PACE authenticated BIS-PACE, see [Doc9303].
16
e.g. Chip Authentication Version 1 and ephemeral keys
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 45 of 106
Application note 41 from [PP-PACE]:
Please note that the control on the user data transmitted between the TOE and the PACE
terminal is addressed by FTP_ITC.1/PACE.
Application note 32 from [PP-EAC]:
The SFR FDP_ACF.1.1/TRM in [PP-EAC] covers the definition in [PP-PACE] and extends it
by additional subjects and objects. The SFRs FDP_ACF.1.2/TRM and FDP_ACF.1.3/TRM in
[PP-EAC] cover the definition in [PP-PACE]. The SFR FDP_ACF.1.4/TRM in [PP-EAC]
covers the definition in [PP-PACE] and extends it by 3) to 6). These extensions do not
conflict with the strict conformance to [PP-PACE].
Application note 33 from [PP-EAC]:
The relative certificate holder authorization encoded in the CVC of the inspection system is
defined in [TR03110-1]. The TOE verifies the certificate chain established by the Country
Verifying Certification Authority, the Document Verifier Certificate and the Inspection
System Certificate (cf. FMT_MTD.3). The Terminal Authorization is the intersection of the
Certificate Holder Authorization in the certificates of the Country Verifying Certification
Authority, the Document Verifier Certificate and the Inspection System Certificate in a valid
certificate chain.
Application note 34 from [PP-EAC]:
Please note that the Document Security Object (SOD) stored in EF.SOD (see [Doc9303]) does
not belong to the user data, but to the TSF data. The Document Security Object can be read
out by Inspection Systems using PACE, see [SAC].
Application note 35 from [PP-EAC]:
FDP_UCT.1/TRM and FDP_UIT.1/TRM require the protection of the User Data transmitted
from the TOE to the terminal by secure messaging with encryption and message
authentication codes after successful Chip Authentication Version 1 to the Inspection System.
The Password Authenticated Connection Establishment, and the Chip Authentication Protocol
v.1 establish different key sets to be used for secure messaging (each set of keys for the
encryption and the message authentication key).
Developer note:
1. After completing Password Authenticated Connection Establishment, a secure messaging
session is started with the key set resulting from Password Authenticated Connection
Establishment.
2. After completing Chip Authentication, the key set resulting from Password Authenticated
Connection Establishment is cleared. Then a new secure messaging session is started with
the key set resulting from Chip Authentication.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 46 of 106 Version 3.1.19.0
6.1.3.3 FDP_RIP: Residual information protection
FDP_RIP.1
Subset residual information protection
FDP_RIP.1.1
The TSF shall ensure that any previous information content of a resource is made unavailable
upon the de-allocation of the resource from the following objects:
1. Session Keys (immediately after closing related communication session),
2. the ephemeral private key ephem-SKPICC-PACE (by having generated a DH shared
secret K17
),
3. none.
Application note 42 from [PP-PACE]:
The functional family FDP_RIP possesses such a general character, so that it is applicable not
only to user data (as assumed by the class FDP), but also to TSF-data; in this respect it is
similar to the functional family FPT_EMS. Applied to cryptographic keys, FDP_RIP.1
requires a certain quality metric (‘any previous information content of a resource is made
unavailable’) for key’s destruction in addition to FCS_CKM.4 that merely requires a fact
of key destruction according to a method/standard.
Developer note:
The TOE stores cryptographic keys in dedicated Java Card objects, which ensure secure
deleting and de-allocation.
6.1.3.4 FDP_UCT: Inter-TSF user data confidentiality transfer protection
FDP_UCT.1/TRM
Basic data exchange confidentiality – MRTD
FDP_UCT.1.1/TRM
The TSF shall enforce the Access Control SFP to be able to transmit and receive user data
in a manner protected from unauthorized disclosure.
6.1.3.5 FDP_UIT: Inter-TSF user data integrity transfer protection
FDP_UIT.1/TRM
Data exchange integrity
FDP_UIT.1.1/TRM
The TSF shall enforce the Access Control SFP to be able to transmit and receive user data
in a manner protected from modification, deletion, insertion and replay errors.
FDP_UIT.1.2/TRM
The TSF shall be able to determine on receipt of user data, whether modification, deletion,
insertion and replay has occurred.
17
according to [SAC]
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 47 of 106
6.1.4 Class FTP: Trusted Path/Channels
6.1.4.1 FTP_ITC: Inter-TSF trusted channel
FTP_ITC.1/PACE
Inter-TSF trusted channel after PACE
FTP_ITC.1.1/PACE
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 the channel data from modification
or disclosure.
FTP_ITC.1.2/PACE
The TSF shall permit another trusted IT product to initiate communication via the trusted
channel.
FTP_ITC.1.3/PACE
The TSF shall initiate enforce communication via the trusted channel for any data exchange
between the TOE and the Terminal.
Application note 43 from [PP-PACE]:
The trusted IT product is the terminal. In FTP_ITC.1.3/PACE, the word “initiate” is changed
to ‘enforce”, as the TOE is a passive device that can not initiate the communication. All the
communication are initiated by the Terminal, and the TOE enforce the trusted channel.
Application note 44 from [PP-PACE]:
The trusted channel is established after successful performing the PACE protocol
(FIA_UAU.1/PACE). If the PACE was successfully performed, secure messaging
is immediately started using the derived session keys (PACE-KMAC, PACE-KEnc): this secure
messaging enforces preventing tracing while Passive Authentication and the required
properties of operational trusted channel; the cryptographic primitives being used for the
secure messaging are as required by FCS_COP.1/PACE_ENC and FCS_COP.1/PACE_MAC.
The establishing phase of the PACE trusted channel does not enable tracing due to the
requirements FIA_AFL.1/PACE.
Application note 45 from [PP-PACE]:
Please note that the control on the user data stored in the TOE is addressed
by FDP_ACF.1/TRM.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 48 of 106 Version 3.1.19.0
6.1.5 Class FAU: Security Audit
6.1.5.1 FAU_SAS: Audit data storage
FAU_SAS.1
Audit storage
FAU_SAS.1.1
The TSF shall provide the Manufacturer with the capability to store the Initialization and
Pre-Personalization Data in the audit records.
Application note 46 from [PP-PACE]:
The Manufacturer role is the default user identity assumed by the TOE in the life cycle phase
‘manufacturing’. The IC manufacturer and the travel document manufacturer in the
Manufacturer role write the Initialization and/or Pre-personalization Data as TSF-data into the
TOE. The audit records are usually write-only-once data of the travel document
(see FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS). Please note that there could also be such
audit records which cannot be read out, but directly used by the TOE.
Developer note:
1. In the Phase 2 of the life cycle, the Manufacturer is the only user role known to the TOE.
2. The Manufacturer user role performs the following operations:
 writes identification data of the chip,
 activates random UID generation,
 stores embedded software (including the e-passport applet) in the chip,
 creates the e-passport application (instantiates the SmartApp-ID applet),
 writes authentication keys for the Personalization Agent user role.
3. All operations listed above (except writing identification data of the chip) are reversible,
i.e. they can be repeated many times as long as the TOE is in the Phase 2 of the life cycle.
6.1.6 Class FMT: Security Management
6.1.6.1 FMT_SMF: Specification of management functions
FMT_SMF.1
Specification of management functions
FMT_SMF.1.1
The TSF shall be capable of performing the following management functions:
1. Initialization,
2. Pre-personalization,
3. Personalization,
4. Configuration.
6.1.6.2 FMT_SMR: Security management roles
Application note 36 from [PP-EAC]:
The SFR FMT_SMR.1/PACE provides basic requirements to the management of the TSF
data.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 49 of 106
FMT_SMR.1/PACE
Security roles
FMT_SMR.1.1/PACE
The TSF shall maintain the roles
1. Manufacturer,
2. Personalization Agent,
3. Terminal,
4. PACE authenticated BIS-PACE,
5. Country Verifying Certification Authority,
6. Document Verifier,
7. Domestic Extended Inspection System,
8. Foreign Extended Inspection System.
FMT_SMR.1.2/PACE
The TSF shall be able to associate users with roles.
Application note 47 from [PP-PACE]:
For explanation on the role Manufacturer and Personalization Agent please refer to the
glossary. The role Terminal is the default role for any terminal being recognized by the TOE
as not PACE authenticated BIS-PACE (‘Terminal’ is used by the travel document presenter).
The TOE recognizes the travel document holder or an authorized other person or device
(BIS-PACE) by using PACE authenticated BIS-PACE (FIA_UAU.1/PACE).
Application note 37 from [PP-EAC]:
The SFR FMT_SMR.1.1/PACE in [PP-EAC] covers the definition in [PP-PACE] and extends
it by 5) to 8). This extension does not conflict with the strict conformance
to [PP-PACE].
6.1.6.3 FMT_LIM: Limited capabilities and availability
Application note 38 from [PP-EAC]:
The SFR FMT_LIM.1 and FMT_LIM.2 address the management of the TSF and TSF data
to prevent misuse of test features of the TOE over the life-cycle phases.
FMT_LIM.1
Limited capabilities
FMT_LIM.1.1
The TSF shall be designed in a manner that limits their capabilities so that in conjunction with
‘Limited availability (FMT_LIM.2)’ the following policy is enforced: Deploying test features
after TOE delivery do not allow:
1. User Data to be manipulated and disclosed,
2. TSF data to be manipulated or disclosed,
3. software to be reconstructed,
4. substantial information about construction of TSF to be gathered which may enable other
attacks, and
5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 50 of 106 Version 3.1.19.0
FMT_LIM.2
Limited availability
FMT_LIM.2.1
The TSF shall be designed in a manner that limits their availability so that in conjunction with
‘Limited capabilities (FMT_LIM.1)’ the following policy is enforced: Deploying test features
after TOE delivery do not allow:
1. User Data to be manipulated and disclosed,
2. TSF data to be manipulated or disclosed,
3. software to be reconstructed,
4. substantial information about construction of TSF to be gathered which may enable other
attacks, and
5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed.
Application note 39 form [PP-EAC] (includes Application note 48 from [PP-PACE]):
The formulation of “Deploying Test Features …” in FMT_LIM.2.1 might be a little bit
misleading since the addressed features are no longer available (e.g. by disabling or removing
the respective functionality). Nevertheless the combination of FMT_LIM.1 and FMT_LIM.2
is introduced to provide an optional approach to enforce the same policy.
Note that the term “software” in item 3 of FMT_LIM.1.1 and FMT_LIM.2.1 refers to both IC
Dedicated and IC Embedded Software.
Developer note:
Test features of the TOE are blocked when the e-passport application is created (during the
SmartApp-ID applet instantiation).
6.1.6.4 FMT_MTD: Management of TSF data
Application note 40 from [PP-EAC]:
The following SFR are iterations of the component Management of TSF data (FMT_MTD.1).
The TSF data include but are not limited to those identified below.
FMT_MTD.1/INI_ENA
Management of TSF data – Writing Initialization and Pre-personalization Data
FMT_MTD.1.1/INI_ENA
The TSF shall restrict the ability to write the Initialization Data and Pre-personalization Data
to the Manufacturer.
FMT_MTD.1/INI_DIS
Management of TSF data – Reading and using Initialization and Pre-personalization
Data
FMT_MTD.1.1/INI_DIS
The TSF shall restrict the ability to read out the Initialization Data and the Pre-personalization
Data to the Personalization Agent.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 51 of 106
Application note 49 from [PP-PACE]:
The TOE may restrict the ability to write the Initialization Data and the Pre-personalization
Data by (i) allowing writing these data only once and (ii) blocking the role Manufacturer
at the end of the manufacturing phase. The Manufacturer may write the Initialization Data
(as required by FAU_SAS.1) including, but being not limited to a unique identification of the
IC being used to trace the IC in the life cycle phases ‘manufacturing’ and ‘issuing’, but being
not needed and may be misused in the ‘operational use’. Therefore, read and use access to the
Initialization Data shall be blocked in the ‘operational use’ by the Personalization Agent,
when he switches the TOE from the life cycle phase ‘issuing’ to the life cycle phase
‘operational use’.
Developer note:
1. The Initialization Data and the Pre-personalization Data can be written many times when
the TOE is in the Phase 2 of the life cycle.
2. The Manufacturer user role is permanently blocked during the transition from the Phase 2
to the Phase 3 of the life cycle.
3. Read and use access to the Initialization Data is permanently blocked during the transition
from the Phase 2 to the Phase 3 of the life cycle.
4. Read and use access to the Pre-personalization Data is permanently blocked during the
transition from the Phase 3 to the Phase 4 of the life cycle.
FMT_MTD.1/KEY_READ
Management of TSF data – Key Read
FMT_MTD.1.1/KEY_READ
The TSF shall restrict the ability to read the:
1. PACE passwords,
2. Chip Authentication Private Key,
3. Personalization Agent Keys
to none.
Application note 45 from [PP-EAC]:
The SFR FMT_MTD.1/KEY_READ in [PP-EAC] covers the definition in [PP-PACE] and
extends it by additional TSF data. This extension does not conflict with the strict conformance
to [PP-PACE].
FMT_MTD.1/PA
Management of TSF data – Personalization Agent
FMT_MTD.1.1/PA
The TSF shall restrict the ability to write the Document Security Object (SOD) to the
Personalization Agent.
Application note 50 from [PP-PACE]:
By writing SOD into the TOE, the Personalization Agent confirms (on behalf of DS) the
correctness and genuineness of all the personalization data related. This consists of user- and
TSF-data.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 52 of 106 Version 3.1.19.0
FMT_MTD.1/CVCA_INI
Management of TSF data – Initialization of CVCA Certificate and Current Date
FMT_MTD.1.1/CVCA_INI
The TSF shall restrict the ability to write the:
1. initial Country Verifying Certification Authority Public Key,
2. initial Country Verifying Certification Authority Certificate,
3. initial Current Date,
4. none
to the Personalization Agent.
Application note 41 from [PP-EAC]:
Information for the security target author only – no action required.
FMT_MTD.1/CVCA_UPD
Management of TSF data – Country Verifying Certification Authority
FMT_MTD.1.1/CVCA_UPD
The TSF shall restrict the ability to update the:
1. Country Verifying Certification Authority Public Key,
2. Country Verifying Certification Authority Certificate
to Country Verifying Certification Authority.
Application note 42 from [PP-EAC]:
The Country Verifying Certification Authority updates its asymmetric key pair and distributes
the public key be means of the Country Verifying CA Link-Certificates (cf. [TR03110-1]).
The TOE updates its internal trust-point if a valid Country Verifying CA Link-Certificates
(cf. FMT_MTD.3) is provided by the terminal (cf. [TR03110-1]).
FMT_MTD.1/DATE
Management of TSF data – Current date
FMT_MTD.1.1/DATE
The TSF shall restrict the ability to modify the Current date to:
1. Country Verifying Certification Authority,
2. Document Verifier,
3. Domestic Extended Inspection System.
Application note 43 from [PP-EAC]:
The authorized roles are identified in their certificate (cf. [TR03110-1]) and authorized
by validation of the certificate chain (cf. FMT_MTD.3). The authorized role of the terminal is
part of the Certificate Holder Authorization in the card verifiable certificate provided by the
terminal for the identification and the Terminal Authentication v.1 (cf. to [TR03110-1]).
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 53 of 106
FMT_MTD.1/CAPK
Management of TSF data – Chip Authentication Private Key
FMT_MTD.1.1/CAPK
The TSF shall restrict the ability to create, load the Chip Authentication Private Key
to the Manufacturer and Personalization Agent.
Application note 44 from [PP-EAC]:
The component FMT_MTD.1/CAPK is refined by (i) selecting other operations and (ii)
defining a selection for the operations “create” and “load” to be performed by the ST writer.
The verb “load” means here that the Chip Authentication Private Key is generated securely
outside the TOE and written into the TOE memory. The verb “create” means here that the
Chip Authentication Private Key is generated by the TOE itself. In the latter case the ST
writer shall include an appropriate instantiation of the component FCS_CKM.1/CA as SFR
for this key generation. The ST writer shall perform the assignment for the authorized
identified roles in the SFR component FMT_MTD.1/CAPK.
Developer note:
1. The following operations have been selected: ‘load’, ‘create’.
2. Due to selecting the ‘create’ operation, the following instantiation of the component
FCS_CKM.1/CA (as SFR) has been done: FCS_CKM.1/CAPK.
FMT_MTD.3
Secure TSF data
FMT_MTD.3.1
The TSF shall ensure that only secure values of the certificate chain are accepted for TSF
data of the Terminal Authentication Protocol v.1 and the Access Control.
Refinement: The certificate chain is valid if and only if:
1. the digital signature of the Inspection System Certificate can be verified as correct
with the public key of the Document Verifier Certificate and the expiration date
of the Inspection System Certificate is not before the Current Date of the TOE,
2. the digital signature of the Document Verifier Certificate can be verified as correct
with the public key in the Certificate of the Country Verifying Certification
Authority and the expiration date of the Certificate of the Country Verifying
Certification Authority is not before the Current Date of the TOE and the expiration
date of the Document Verifier Certificate is not before the Current Date of the TOE,
3. the digital signature of the Certificate of the Country Verifying Certification
Authority can be verified as correct with the public key of the Country Verifying
Certification Authority known to the TOE.
The Inspection System Public Key contained in the Inspection System Certificate
in a valid certificate chain is a secure value for the authentication reference data of the
Extended Inspection System.
The intersection of the Certificate Holder Authorizations contained in the certificates
of a valid certificate chain is a secure value for Terminal Authorization of a successful
authenticated Extended Inspection System.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 54 of 106 Version 3.1.19.0
Application note 46 from [PP-EAC]:
The Terminal Authentication Version 1 is used for Extended Inspection System as required
by FIA_UAU.4/PACE and FIA_UAU.5/PACE. The Terminal Authorization is used as TSF
data for access control required by FDP_ACF.1/TRM.
6.1.7 Class FPT: Protection of the Security Functions
6.1.7.1 FPT_EMS: TOE emanation
FPT_EMS.1
TOE Emanation
FPT_EMS.1.1
The TOE shall not emit electromagnetic emissions or variations in the time or power
consumption required to process an APDU command in excess of levels that could be
measured or analyzed in the current state of art enabling access to:
1. Chip Authentication Session Keys,
2. PACE session keys (PACE-KMAC, PACE-KEnc),
3. the ephemeral private key ephem-SKPICC-PACE,
4. none,
5. Personalization Agent Key(s),
6. Chip Authentication Private Key, and
7. none.
FPT_EMS.1.2
The TSF shall ensure any users are unable to use the following interface travel document’s
contactless/contact interface and circuit contacts to gain access to:
1. Chip Authentication Session Keys,
2. PACE session keys (PACE-KMAC, PACE-KEnc),
3. the ephemeral private key ephem-SKPICC-PACE,
4. none,
5. Personalization Agent Key(s),
6. Chip Authentication Private Key, and
7. none.
Application note 51 from [PP-PACE]:
The TOE shall prevent attacks against the listed secret data where the attack is based
on external observable physical phenomena of the TOE. Such attacks may be observable
at the interfaces of the TOE or may be originated from internal operation of the TOE or may
be caused by an attacker that varies the physical environment under which the TOE operates.
The set of measurable physical phenomena is influenced by the technology employed
to implement the smart card. The travel document’s chip has to provide a smart card
contactless interface, but may have also (not used by the terminal, but maybe by an attacker)
sensitive contacts according to ISO/IEC 7816-2 as well. Examples of measurable phenomena
include, but are not limited to variations in the power consumption, the timing of signals and
the electromagnetic radiation due to internal operations or data transmissions.
Developer note:
The TOE uses security mechanisms provided by the platform (see 1.1.2 for platform details)
to ensure protection against attacks described above.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 55 of 106
Application note 47 from [PP-EAC]:
The SFR FPT_EMS.1.1 in [PP-EAC] covers the definition in [PP-PACE] and extends
it by EAC aspects 1., 5. and 6. The SFR FPT_EMS.1.2 in [PP-EAC] covers the definition in
[PP-PACE] and extends it by EAC aspects 4) and 5). These extensions do not conflict with
the strict conformance to [PP-PACE].
Application note 48 from [PP-EAC]:
The ST writer shall perform the operation in FPT_EMS.1.1 and FPT_EMS.1.2. The TOE
shall prevent attacks against the listed secret data where the attack is based on external
observable physical phenomena of the TOE. Such attacks may be observable at the interfaces
of the TOE or may be originated from internal operation of the TOE or may be caused
by an attacker that varies the physical environment under which the TOE operates. The set
of measurable physical phenomena is influenced by the technology employed to implement
the smart card. The travel document’s chip can provide a smart card contactless interface and
contact based interface according to ISO/IEC 7816-2 [ISO7816-2] as well (in case the
package only provides a contactless interface the attacker might gain access to the contacts
anyway). Examples of measurable phenomena include, but are not limited to variations in the
power consumption, the timing of signals and the electromagnetic radiation due to internal
operations or data transmissions.
Developer note:
The TOE uses security mechanisms provided by the platform (see 1.1.2 for platform details)
to ensure protection against attacks described above.
6.1.7.2 FPT_FLS: Fail secure
FPT_FLS.1
Failure with preservation of secure state
FPT_FLS.1.1
The TSF shall preserve a secure state when the following types of failures occur:
1. exposure to operating conditions causing a TOE malfunction,
2. failure detected by TSF according to FPT_TST.1,
3. none.
6.1.7.3 FPT_TST: TSF self test
FPT_TST.1
TSF testing
FPT_TST.1.1
The TSF shall run a suite of self tests during initial start-up to demonstrate the correct
operation of the TSF.
FPT_TST.1.2
The TSF shall provide authorized users with the capability to verify the integrity of the
TSF-data.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 56 of 106 Version 3.1.19.0
FPT_TST.1.3
The TSF shall provide authorized users with the capability to verify the integrity of stored
TSF executable code.
Application note 52 from [PP-PACE]:
If the travel document’s chip uses state of the art smart card technology, it will run some self
tests at the request of an authorized user and some self tests automatically. E.g. a self test for
the verification of the integrity of stored TSF executable code required by FPT_TST.1.3 may
be executed during initial start-up by the ‘authorized user’ Manufacturer in the life cycle
phase ‘Manufacturing’. Other self tests may automatically run to detect failures and
to preserve the secure state according to FPT_FLS.1 in the phase ‘operational use’,
e.g. to check a calculation with a private key by the reverse calculation with the corresponding
public key as a countermeasure against Differential Failure Analysis.
Developer note:
1. The TOE uses security mechanisms provided by the platform (see 1.1.2 for platform
details) to ensure integrity of stored TSF executable code.
2. The TOE automatically verifies the integrity of the TSF-data before every use of these
data.
3. The TOE always checks a calculation with a private key by the reverse calculation with
the corresponding public key.
6.1.7.4 FPT_PHP: TSF physical protection
FPT_PHP.3
Resistance to physical attack
FPT_PHP.3.1
The TSF shall resist physical manipulation and physical probing to the TSF by responding
automatically such that the SFRs are always enforced.
Application note 53 from [PP-PACE]:
The TOE will implement appropriate measures to continuously counter physical manipulation
and physical probing. Due to the nature of these attacks (especially manipulation) the TOE
can by no means detect attacks on all of its elements. Therefore, permanent protection against
these attacks is required ensuring that the TSP could not be violated at any time. Hence,
‘automatic response’ means here (i) assuming that there might be an attack at any time and
(ii) countermeasures are provided at any time.
Developer note:
The TOE uses security mechanisms provided by the platform (see 1.1.2 for platform details)
to ensure protection against attacks described above.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 57 of 106
6.2 Security assurance requirements
The assurance requirements for the evaluation of the TOE and its development and operating
environment are those taken from the assurance package EAL 4 and augmented by taking the
following components ALC_DVS.2, ATE_DPT.2 and AVA_VAN.5.
Application note 49 from [PP-EAC]:
The TOE shall protect the assets against high attack potential. This includes intermediate
storage in the chip as well as secure channel communications established using the Chip
Authentication Protocol v.1 (OE.Prot_Logical_Travel_Document). If the TOE is operated
in non-certified mode using the BAC-established communication channel, the confidentiality
of the standard data shall be protected against attackers with at least Enhanced-Basic attack
potential (AVA_VAN.3).
6.3 Security requirements rationale
All security functional requirements described in this security target are coming from [PP-
PACE] and [PP-EAC]. No new security functional requirement is introduced. Therefore
security requirements rationales given in the protection profiles remain in force.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 58 of 106 Version 3.1.19.0
7 Target of evaluation summary specification
This section describes all security function implemented by the TOE and maps their
functionalities to SFRs. The mapping allows to demonstrate, that all SFRs defined in this
security target have been addressed and each of them is covered by at least one security
function.
7.1 SFR to TSF mapping
Table 7.1: Functional requirement to TOE security functionality mapping
TOE security functional
requirement
TOE
Security
functionality
SF.Access
SF.Random
SF.SymmetricAuthentication
SF.Trust
SF.TerminalAuthentication
SF.Protection
SF.Configuration
FCS_CKM.1/DH_PACE A
FCS_CKM.1/CA C
FCS_CKM.1/CAPK C
FCS_CKM.4 B
FCS_COP.1/PACE_ENC B
FCS_COP.1/PACE_MAC B
FCS_COP.1/CA_ENC B
FCS_COP.1/CA_MAC B
FCS_COP.1/SIG_VER A
FCS_RND.1 A A
FIA_AFL.1/PACE A
FIA_UID.1/PACE A A, C A
FIA_UAU.1/PACE A A, C A
FIA_UAU.4/PACE A A
FIA_UAU.5/PACE A A, B, C A
FIA_UAU.6/PACE A, B
FIA_UAU.6/EAC B, C
FIA_API.1 B, C
FDP_ACC.1/TRM A
FDP_ACF.1/TRM A A
FDP_RIP.1 A, B A
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 59 of 106
Table 7.1 (continued)
TOE security functional
requirement
TOE
Security
functionality
SF.Access
SF.Random
SF.SymmetricAuthentication
SF.Trust
SF.TerminalAuthentication
SF.Protection
SF.Configuration
FDP_UCT.1/TRM B
FDP_UIT.1/TRM B
FTP_ITC.1/PACE A A, B
FAU_SAS.1 A
FMT_SMF.1 A A
FMT_SMR.1/PACE A
FMT_LIM.1 A A
FMT_LIM.2 A A
FMT_MTD.1/INI_ENA A A
FMT_MTD.1/INI_DIS A A
FMT_MTD.1/KEY_READ A A
FMT_MTD.1/PA A A
FMT_MTD.1/CVCA_INI A
FMT_MTD.1/CVCA_UPD A
FMT_MTD.1/DATE A
FMT_MTD.1/CAPK A A
FMT_MTD.3 A
FPT_EMS.1 A
FPT_FLS.1 A
FPT_TST.1 A
FPT_PHP.3 A
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 60 of 106 Version 3.1.19.0
7.2 SF.Access
A. Access Control
This security functionality provides the mechanism which allows to control the TOE life
cycle phases, check user roles and enforce national and/or international security policies
relevant for the travel documents.
Table 7.2: Operations and security conditions supported by the TOE
Symmetric
Authentication
Mechanism
Basic
Access
Control
PACE
Secure
Messaging
Chip
Authentication
Terminal
Authentication
Symmetric Authentication Mechanism key replacement X
Enabling/disabling security protocols X
Enabling/disabling Chip Authentication keys generation X
Chip Authentication keys generation X
Switching to the next life cycle phase X
Symmetric Authentication Mechanism key replacement X
Writing personalization data X
Chip Authentication keys generation X
Switching to the next life cycle phase X
Reading low sensitive data (all DGs except DG3 and DG4) X X X X
Reading high sensitive data (DG3 or DG4) X X X X X
Developer note:
1. The TOE supports secure messaging based on Triple-DES and AES. The security
condition Secure Messaging covers both of them.
2. The security condition Chip Authentication is optional in the context of reading low
sensitive data, i.e. it is not covered by [PP-PACE]. However its use is recommended due
to additional protection against MRTD cloning.
3. PACE (corresponding to the security condition PACE) and BAC (corresponding to the
security condition Basic Access Control) are alternative protocols. According to the most
recent security requirements, MRTDs shall use PACE whenever it is possible. BAC shall
be supported only due to downward compatibility reasons. Protection profiles claimed by
this evaluation, i.e. [PP-PACE] and [PP-EAC], do not cover BAC. In consequence, BAC
is excluded from this evaluation.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 61 of 106
Before performing any operation, the TOE checks security conditions resulting from
mentioned security policies to verify whether the communicating entity is allowed to perform
requested operation. Table 7.2 lists briefly operations supported by the TOE and security
conditions enforced by this security functionality.
The e-passport application (SmartApp-ID applet) controls only operations relevant for the
following life cycle phases:
 Phase 2: Manufacturing, Step 5, (iii);
 Phase 3: Personalization of the travel document;
 Phase 4: Operational use.
Operations specific for other life cycle phases are handled directly by the platform.
The description of the TOE life cycle is given in 1.3.4.
7.3 SF.Random
A. Random number generation
This security functionality generates random challenges intended for various authentication
mechanisms. Generated challenges come from the random number generator meeting
requirements of class DRG.3 specified in [AIS20/AIS31].
This security functionality uses SF.CryptoOperation of the platform, which provides the
implementation of the following algorithms:
 SHA-256 compliant to [FIPS180-2],
 EC key pair generation with key size of 256 bits compliant to [TR03111].
7.4 SF.SymmetricAuthentication
A. Symmetric Authentication Mechanism
This security functionality is used to authenticate:
 IC Manufacturer who wants to pre-personalize e-passport application, i.e. perform
Phase 2: Manufacturing, Step 5, (iii) of the TOE life cycle (see 1.3.4.2 for details); or
 Personalization Agent who wants to personalize e-passport application, i.e. perform
Phase 3: Personalization of the travel document (see 1.3.4.3 for details).
This security functionality uses SF.CryptoOperation of the platform, which provides the
implementation of the following algorithms:
 Triple-DES in CBC mode with 168 bit keys complaint to [FIPS46-3] and [FIPS81].
B. Authentication key management
This security functionality allows to replace existing authentication key used by Symmetric
Authentication Mechanism with a new one. It can be done by IC Manufacturer or
Personalization Agent who successfully authenticated himself with Symmetric Authentication
Mechanism.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 62 of 106 Version 3.1.19.0
7.5 SF.Trust
A. Password Authenticated Connection Establishment
This security functionality authenticates the inspection system, which tries to establish
connection with the TOE. After successful authentication and securing the communication
with Secure Messaging based on Triple-DES or AES, the inspection system can read low
sensitive data stored in the TOE, i.e. all DGs except DG3 (containing fingerprint images) and
DG4 (containing iris images).
The security protocol implemented by this security functionality (PACE) is specified
in [SAC].
The complete list of elliptic curves supported by this security functionality is given
in Annex A.
This security functionality uses SF.CryptoOperation of the platform, which provides the
implementation of the following algorithms:
 Triple-DES in CBC mode with 112 bit keys complaint to [FIPS46-3] and [FIPS81];
 AES in CBC mode with 128, 192 and 256 bit keys complaint to [FIPS197];
 ECDH key generation with key sizes of 224, 256, 320, 384, 512 and 521 bits compliant
to [TR03111];
 ECDH with key sizes of 224, 256, 320, 384, 512 and 521 bits compliant to [IEEE1363];
 Retail-MAC, i.e. ISO/IEC 9797-1 MAC algorithm 3 with block cipher DES, zero IV
(8 bytes), ISO/IEC 9797-1 padding method 2 and cryptographic key size of 112 complaint
to [ISO9797-1];
 CMAC algorithm complaint to [FIPS197] and [NIST800-38B];
 SHA-1 compliant to [FIPS180-2];
 SHA-256 compliant to [FIPS180-2].
B. Secure Messaging based on AES
This security functionally is used to secure communication between the TOE and the
inspection system when the inspection system is authenticated with Password Authentication
Connection Establishment. The communication is protected by:
 encrypting the messages (APDUs and responses to them) with AES in CBC mode with
128, 192 and 256 bit keys as specified in [SAC];
 calculating MACs of the messages using CMAC algorithm to as specified in [SAC].
The security protocol implemented by this security functionality is specified
in [SAC].
This security functionality uses SF.CryptoOperation of the platform, which provides the
implementation of the following algorithms:
 AES in CBC mode with 128, 192 and 256 bit keys complaint to [FIPS197];
 CMAC algorithm complaint to [FIPS197] and [NIST800-38B].
C. Chip Authentication
This security functionality is used by the TOE to prove its identity (to prevent cloning). The
successful performing of Chip Authentication is the necessary but not the sufficient condition
to read high sensitive data stored in the TOE. After successful Chip Authentication, new
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 63 of 106
secure messaging keys are calculated to replace keys used by the active secure messaging
protocol (Secure Messaging based on AES or Secure Messaging based on Triple-DES).
The security protocol implemented by this security functionality (Chip Authentication)
is specified in [TR03110-1].
The complete list of elliptic curves supported by this security functionality is given
in Annex A.
This security functionality uses SF.CryptoOperation of the platform, which provides
the implementation of the following algorithms:
 ECDH key generation with key sizes of 224, 256, 320, 384, 512 and 521 bits compliant
to [TR03111];
 ECDH with key sizes of 224, 256, 320, 384, 512 and 521 bits compliant to [IEEE1363];
 SHA-1 compliant to [FIPS180-2];
 SHA-256 compliant to [FIPS180-2].
D. Basic Access Control
This security functionally is excluded from this evaluation as it is not covered by [PP-PACE]
and [PP-EAC]. Therefore, its details are not given in this document.
E. Secure Messaging based on Triple-DES
This security functionally is used to secure communication between the TOE and the
inspection system when the inspection system is authenticated with Basic Access Control or
Password Authenticated Connection Establishment. The communication is protected by:
 encrypting the messages (APDUs and responses to them) with Triple-DES in CBC mode
using 112 bit keys as specified in [Doc9303],
 calculating MACs of the messages according to ISO/IEC 9797-1 MAC algorithm 3 with
block cipher DES, zero IV (8 bytes), ISO/IEC 9797-1 padding method 2 and
cryptographic key size of 112 bits as specified in [Doc9303].
The security protocol implemented by this security functionality is specified
in [Doc9303].
This security functionality uses SF.CryptoOperation of the platform, which provides the
implementation of the following algorithms:
 Triple-DES in CBC mode with 112 bit keys complaint to [FIPS46-3] and [FIPS81];
 ISO/IEC 9797-1 MAC algorithm 3 with block cipher DES, zero IV (8 bytes),
ISO/IEC 9797-1 padding method 2 and cryptographic key size of 112 complaint
to [ISO9797-1].
7.6 SF.TerminalAuthentication
A. Terminal Authentication
This security functionality authenticates the inspection system, which tries to read high
sensitive data stored in the TOE, i.e. DG3 (containing fingerprint images) or DG4
(containing iris images). It can be executed only after successful performing of Chip
Authentication.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 64 of 106 Version 3.1.19.0
The security protocol implemented by this security functionality (Terminal Authentication)
is specified in [TR03110-1].
The complete list of elliptic curves supported by this security functionality is given
in Annex A.
This security functionality uses SF.CryptoOperation of the platform, which provides the
implementation of the following algorithms:
 ECDSA with SHA-1 compliant to [ISO15946-1] and [ISO15946-2],
 ECDSA with SHA-224 compliant to [ISO15946-1] and [ISO15946-2],
 ECDSA with SHA-256 compliant to [ISO15946-1] and [ISO15946-2],
 ECDSA with SHA-384 compliant to [ISO15946-1] and [ISO15946-2],
 ECDSA with SHA-512 compliant to [ISO15946-1] and [ISO15946-2].
7.7 SF.ActiveAuthentication
A. Active Authentication
This security functionally is excluded from this evaluation as it is not covered by [PP-PACE]
and [PP-EAC]. Therefore, its details are not given in this document.
7.8 SF.Protection
A. Protection against interference, logical tampering and bypass
The platform provides the following protection against interference, logical tampering
and bypass:
 The platform performs self-tests to confirm it operates as intended.
 The platform provides protection against physical attacks.
 The platform supports JavaCard security domains.
 The platform protects the application software against malfunctions caused by exposure
to operating conditions exceeding permitted limits. It includes hardware resets.
The e-passport application (i.e. the SmartApp-ID applet and relevant SmartApp libraries
constituting parts of the TOE) implements additional protections. They are listed below:
 The integrity of sensitive data is protected by redundant storage or by using check digits.
 The application flow is protected with Integrity Counter.
 Integrity Counter is protected by redundant storage and controlled before execution
of each important command.
 Important flow-control conditions are checked twice.
 Once the application flow is disrupted or data integrity is violated, the executed operation
is aborted and Integrity Counter is incremented.
 Once integrity of Integrity Counter is violated or its value reaches the number of 5 (five)
detected errors, the TOE is blocked permanently.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 65 of 106
7.9 SF.Configuration
A. Security mechanism configuration
This security functionality is used to:
 select security mechanisms (i.e. SAC, EAC, BAC, AA) to be active during the operational
use of the evaluated product (the Phase 4 of the life cycle).
This security functionality is available for the Personalization Agent during the Phase 3 of the
life cycle.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 66 of 106 Version 3.1.19.0
8 Statement of compatibility concerning the composite ST
8.1 Separation of the platform TSF
8.1.1 Security functionalities
Table 8.1 confronts the relevant security functionalities of the platform with the security
functionalities of the composite TOE to separate them. The security functionalities provided
by the platform are summarized based on [jTOP_ST], [jTOP_OPE] and [jTOP_PRE].
Table 8.1: Operations and security conditions supported by the TOE
The platform functionalities Usage by
the TOE
References/Remarks
Cryptographic algorithms and functionalities
3DES (112 and 168 bit keys) for en-/decryption (CBC and ECB) and
MAC generation and verification (Retail-MAC, CMAC and CBC-MAC)
YES 7.4, 7.5 (D18
, E)
AES (Advanced Encryption Standard) with key length of 128, 192, and
256 bit for en-/decryption (CBC and ECB) and MAC generation and
verification (CMAC, CBC-MAC)
YES 7.5 (A, B)
RSA and RSA CRT (512 up to 2048 bits keys) for en-/decryption and
signature generation and verification
YES 7.7
RSA and RSA CRT key generation (512 up to 2048 bits keys) YES 7.7
SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 hash algorithm YES 7.3, 7.5 (A, C, D), 7.6,
7.7
ECC over GF(p) algorithm that can be used for signature generation and
signature verification (ECDSA) with Brainpool curve (224, 256, 320, 384
and 512 bits) or NIST curve (224, 256, 384 and 521 bits)
YES 7.6, 7.7
ECC over GF(p) algorithm that can be used for key exchange (ECDH)
with Brainpool curve (224, 256, 320, 384 and 512 bits) or NIST curve
(224, 256, 384 and 521 bits)
YES 7.5 (A, C)
ECC over GF(p) key generation algorithm that can be used to generate
ECC over GF(p) key pairs with Brainpool curve (224, 256, 320, 384 and
512 bits) or NIST curve (224, 256, 384 and 521 bits)
YES 7.3, 7.5 (A, C), 7.7
Random number generation compliant to the STANDARD level specified
in [RGS]
NO -
BAC DES Authentication and secure messaging YES 7.5 (D)
PACE mapping (point generation with ECDH and domain generation) YES 7.5 (A)
Secure Messaging using DES and AES session keys YES -
Java Card 3.0.4 functionalities
Garbage collection of unreachable class instances and arrays YES -
Support for Extended Length APDUs YES -
18
This security functionally is excluded from this evaluation as it is not covered by [PP-PACE] and [PP-EAC].
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 67 of 106
Table 8.1 (continued)
The platform functionalities Usage by
the TOE
References/Remarks
GlobalPlatform 2.2.1 functionalities
A Cardholder Verification Method consisting of a Global PIN NO -
Secure communication with secure channel YES SCP02 is used
Card manager YES -
Delegated management NO -
Other functionalities of the platform
Native implementation of File System available via LDS FS API YES -
Native implementation of PACE protocol available via PACE API NO -
Post-issuance installation and deletion of applets, packages and objects NO -
Pre-personalization mechanism YES -
8.1.2 Security functional requirements
The following composite SFRs are platform related:
 FAU_SAS.1,
 FCS_CKM.1/DH_PACE,
 FCS_CKM.1/CA,
 FCS_CKM.1/CAPK,
 FCS_CKM.4,
 FCS_COP.1/PACE_ENC,
 FCS_COP.1/PACE_MAC,
 FCS_COP.1/CA_ENC,
 FCS_COP.1/CA_MAC,
 FCS_COP.1/SIG_VER,
 FCS_RND.1,
 FDP_ACC.1/TRM,
 FDP_ACF.1/TRM,
 FDP_RIP.1,
 FDP_UCT.1/TRM,
 FDP_UIT.1/TRM,
 FIA_UAU.5/PACE,
 FIA_UAU.6/PACE,
 FMT_LIM.1,
 FMT_LIM.2,
 FMT_MTD.1/INI_ENA,
 FMT_SMF.1,
 FMT_SMR.1/PACE,
 FPT_EMS.1,
 FPT_FLS.1,
 FPT_PHP.3,
 FPT_TST.1,
 FTP_ITC.1/PACE.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 68 of 106 Version 3.1.19.0
Other SFRs of the composite ST are not related to the platform and their implementations are
not based on the platform SFRs.
The following SFRs of the IC contribute to the composite SFRs:
 FAU_SAS.1-IC,
 FDP_IFC.1-IC,
 FDP_ITT.1-IC,
 FMT_LIM.1-IC,
 FMT_LIM.2-IC,
 FPT_FLS.1-IC,
 FPT_ITT.1-IC,
 FPT_PHP.3-IC,
 FRU_FLT.2-IC.
The following SFRs of the operating system contribute to the composite SFRs:
 FAU_ARP.1-JCS,
 FCS_CKM.1-Key_generation-ALG-EC-FP,
 FCS_CKM.2-Key_agreement-APP-EC-SVDP-DH-PLAIN,
 FCS_CKM.3-KL-JCS,
 FCS_CKM.4-KD,
 FCS_COP.1-APP-SHA,
 FCS_COP.1-Asymetric-APP-ECDSA,
 FCS_COP.1-Symetric-APP-CIPHER/AES,
 FCS_COP.1-Symetric-APP-CIPHER/DES,
 FCS_COP.1-Symetric-APP-SIGN/AES,
 FCS_COP.1-Symetric-APP-SIGN/DES,
 FDP_RIP.1-KEYS,
 FDP_RIP.1-ODEL,
 FDP_RIP.1-TRANSIENT,
 FMT_MTD.1-JCRE,
 FMT_MTD.3-AID,
 FMT_SMF.1,
 FMT_SMF.1-SCP,
 FMT_SMF.1-SD,
 FMT_SMR.1-CA,
 FMT_SMR.1-CCM,
 FMT_SMR.1-PRV,
 FPT_FLS.1-JCS,
 FPT_TST.1,
 FCS_CKM.4/LDS,
 FCS_COP.1/LDS-ENC,
 FCS_COP.1/LDS-MAC,
 FDP_ACF.1/LDS,
 FDP_RIP.1/LDS,
 FDP_UCT.1/LDS,
 FDP_UIT.1/LDS,
 FDP_ACC.1/LDS,
 FIA_UAU.5/LDS,
 FIA_UAU.6/LDS,
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 69 of 106
 FMT_LIM.1/LDS,
 FMT_LIM.2/LDS,
 FMT_SMR.1/LDS,
 FTP_ITC.1/PACE_LDS.
The other platform SFRs are not used.
Mapping of the platform SFRs to the composite SFRs is provided in Table 8.2.
Table 8.2: SFRs mapping
Composite SFR Platform SFR Comments
FAU_SAS.1 FAU_SAS.1-IC The Manufacturer user role performs the
following operations:
 writes identification data of the chip,
 activates random UID generation,
 stores embedded software (including
the e-passport applet) in the chip,
 creates the e-passport application
(instantiates the SmartApp-ID applet),
 writes authentication keys for the
Personalization Agent user role.
FCS_CKM.1/DH_PACE
(see Note 1 below the
table)
FCS_CKM.1-Key_generation-
ALG-EC-FP
FCS_COP.1-APP-SHA
Random nonce is generated by the TOE
during each PACE establishment.
The TOE uses the random number
generator utilizing EC key generation and
SHA-256.
FCS_COP.1-Symetric-
APP-CIPHER/DES
FCS_COP.1-Symetric-
APP-CIPHER/AES
Random nonce generated by the TOE is
encrypted with TripleDES or AES.
FCS_CKM.1-Key_generation-
ALG-EC-FP
Ephemeral ECDH key pairs are generated
twice during each PACE establishment.
FCS_CKM.2-Key_agreement-
APP-EC-SVDP-DH-PLAIN
ECDH key agreement is performed twice
during each PACE establishment.
FCS_COP.1-APP-SHA Derivation of session keys during PACE
requires usage of SHA function.
FCS_COP.1-Symetric-
APP-SIGN/DES
FCS_COP.1-Symetric-
APP-SIGN/AES
Each PACE establishment requires
exchange of Authentication Tokens
calculated according to Retail-MAC or
CMAC.
FCS_CKM.3-KL-JCS All keys used during PACE establishment
are stored in subclasses of Key class and
accessed via Key class API.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 70 of 106 Version 3.1.19.0
Table 8.2 (continued)
Composite SFR Platform SFR Comments
FCS_CKM.1/CA
(see Note 2 below the
table)
FCS_CKM.2-Key_agreement-
APP-EC-SVDP-DH-PLAIN
ECDH key agreement is performed during
each CA establishment.
FCS_CKM.3-KL-JCS All keys used during CA establishment are
stored in subclasses of Key class and
accessed via Key class API.
FCS_COP.1-APP-SHA Derivation of session keys during CA
requires usage of SHA function.
FCS_CKM.1/CAPK FCS_CKM.1-Key_generation-
ALG-EC-FP
Static ECDH key pair for CA can be
generated during personalization of the
TOE.
FCS_CKM.4 FCS_CKM.4-KD
FCS_CKM.4/LDS
Secure messaging session keys are
destroyed by means of LDS FS API.
All other cryptographic keys are destroyed
using the Java Card API.
FCS_COP.1/PACE_ENC FCS_COP.1/LDS-ENC Triple DES and AES encryption
functionality of the platform is used for
secure messaging. Data encryption and
decryption is performed via LDS FS API.
FCS_COP.1/PACE_MAC FCS_COP.1/LDS-MAC Triple DES and AES encryption
functionality of the platform is used for
secure messaging. MAC generation and
verification is performed via LDS FS API.
FCS_COP.1/CA_ENC FCS_COP.1/LDS-ENC Triple DES and AES encryption
functionality of the platform is used for
secure messaging. Data encryption and
decryption is performed via LDS FS API.
FCS_COP.1/CA_MAC FCS_COP.1/LDS-MAC Triple DES and AES encryption
functionality of the platform is used for
secure messaging. MAC generation and
verification is performed via LDS FS API.
FCS_COP.1/SIG_VER FCS_COP.1-Asymetric-
APP-ECDSA
FCS_RND.1 FCS_CKM.1-Key_generation-
ALG-EC-FP
FCS_COP.1-APP-SHA
The TOE uses the random number
generator utilizing EC key generation and
SHA-256.
FDP_ACC.1/TRM FDP_ACC.1/LDS LDS FS API is used to enforce the Access
Control SFP on terminals accessing User
Data.
FDP_ACF.1/TRM FDP_ACF.1/LDS LDS FS API is used to enforce the Access
Control SFP rules.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 71 of 106
Table 8.2 (continued)
Composite SFR Platform SFR Comments
FDP_RIP.1 FCS_CKM.4-KD Unused ephemeral private key is removed
using destruction method described in
FCS_CKM.4-KD of the platform.
FDP_RIP.1-ODEL
FDP_RIP.1-KEYS
FDP_RIP.1-TRANSIENT
In case of memory reorganization by
garbage collector, removed keys are made
unavailable according to
FDP_RIP.1-ODEL, FDP_RIP.1-KEYS and
FDP_RIP.1-TRANSIENT.
FDP_RIP.1/LDS Unused session keys are removed using
destruction method described in
FDP_RIP.1/LDS of the platform.
FDP_UCT.1/TRM FDP_UCT.1/LDS User data is transmitted and received in a
manner protected from unauthorized
disclosure by means of secure messaging
mechanism provided by the platform via
LDS FS API.
FDP_UIT.1/TRM FDP_UIT.1/LDS User data is transmitted and received in a
manner protected from modification,
deletion, insertion and replay errors by
means of secure messaging mechanism
provided by the platform via LDS FS API.
FIA_UAU.5/PACE FIA_UAU.5/LDS LDS FS API is used to provide support for
secure messaging in MAC-ENC mode
according to FIA_UAU.5/LDS.
PACE and Symmetric Authentication
described in FIA_UAU.5/LDS are handled
without using LDS FS API.
FIA_UAU.6/PACE FIA_UAU.6/LDS LDS FS API is used to perform MAC
verification of incoming commands.
FMT_LIM.1 FMT_LIM.1-IC
FMT_LIM.1/LDS
FMT_LIM.2 FMT_LIM.2-IC
FMT_LIM.2/LDS
FMT_MTD.1/INI_ENA FMT_MTD.1-JCRE Writing the Initialization Data by the
Manufacturer covers the SmartApp-ID
applet instantiation and is handled by the
platform.
Writing the Pre-personalization Data by
the Manufacturer is not related to the
platform and is handled directly by the
SmartApp-ID applet.
FMT_MTD.3-AID The platform verifies whether the value of
Application Identifier (AID) of the
SmartApp-ID applet instance to be created
is the secure value.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 72 of 106 Version 3.1.19.0
Table 8.2 (continued)
Composite SFR Platform SFR Comments
FMT_SMF.1 FMT_SMF.1
FMT_SMF.1-SD
FMT_SMF.1-SCP
Initialization function covers:
 establishing a secure channel to the
Card Manager applet,
 creation of the SmartApp-ID applet
instance,
 setting the SmartApp-ID applet
instance as default selected,
 switching the operating system in the
closed mode, which block the Card
Manager applet and prevents applets
loading.
Pre-personalization, Personalization and
Configuration functions are not related to
the platform and are handled directly by the
SmartApp-ID applet.
FMT_SMR.1/PACE FMT_SMR.1-CCM
FMT_SMR.1-CA
FMT_SMR.1-PRV
In order to perform the TOE Initialization,
the Manufacturer uses the following roles
of the platform:
 Installer,
 Card Administrator,
 Default Selected Applet,
 Implicit Selection Install Parameters.
Personalization Agent, Country Verifying
Certification Authority and Document
Verifier roles are not related to the
platform.
FMT_SMR.1/LDS The roles Terminal, PACE authenticated
BIS-PACE, Domestic Extended Inspection
System and Foreign Extended Inspection
System are maintained by FileSystem
object of LDS FS API provided by the
platform.
FPT_EMS.1 FDP_ITT.1-IC
FPT_ITT.1-IC
FDP_IFC.1-IC
FRU_FLT.2-IC
FPT_FLS.1-IC
FPT_PHP.3-IC
FPT_EMS.1 is fulfilled by the underlying
platform of the TOE. It matches the
combination of the following SFRs of the
IC: FDP_ITT.1-IC, FPT_ITT.1-IC,
FDP_IFC.1-IC, FRU_FLT.2-IC,
FPT_FLS.1-IC, FPT_PHP.3-IC.
FPT_FLS.1 FPT_FLS.1-JCS
FAU_ARP.1-JCS
FPT_PHP.3 FPT_PHP.3-IC
FPT_TST.1 FPT_TST.1
FTP_ITC.1/PACE FTP_ITC.1/PACE_LDS Secure messaging is provided by the
platform by mans of LDS FS API.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 73 of 106
Note 1:
FCS_CKM.1/DH_PACE covers generation of secure messaging session keys according to the
PACE protocol. This procedure is composed of several TOE activities:
1. Generation of the random nonce (FCS_COP.1-APP-SHA and
FCS_CKM.1-Key_generation-ALG-EC-FP).
2. Encryption of the generated nonce with
TripleDES (FCS_COP.1-Symetric-APP-CIPHER/DES) or
AES (FCS_COP.1-Symetric-APP-CIPHER/AES).
3. Generation of ephemeral EC key pair (FCS_CKM.1-Key_generation-ALG-EC-FP).
4. Exchange of ephemeral public keys with the terminal.
5. Generation of the shared secret according to the anonymous Elliptic Curve
Diffie-Hellman (ECDH) key agreement algorithm
(FCS_CKM.2-Key_agreement-APP-EC-SVDP-DH-PLAIN) based on the ephemeral
public key of the terminal and the ephemeral private key of the TOE.
6. Calculation of the new EC base point according to the Generic Mapping procedure, based
on: current base point, random nonce, shared secret.
7. Generation of the ephemeral EC key pair based on the new EC base point
(FCS_CKM.1-Key_generation-ALG-EC-FP).
8. Exchange of ephemeral public keys with the terminal.
9. Generation of the shared secret according to the anonymous Elliptic Curve
Diffie-Hellman (ECDH) key agreement algorithm
(FCS_CKM.2-Key_agreement-APP-EC-SVDP-DH-PLAIN) based on the ephemeral
public key of the terminal and the ephemeral private key of the TOE.
10. Derivation of session keys from the shared secret using
SHA-1 (FCS_COP.1-APP-SHA) for TripleDES or
SHA-256 (FCS_COP.1-APP-SHA) for AES.
11. Verification of the Authentication Token received from the terminal and calculation of the
Authentication Token of the TOE using
Retail-MAC (FCS_COP.1-Symetric-APP-SIGN/DES) or
CMAC (FCS_COP.1-Symetric-APP-SIGN/AES).
For technical implementation of aforementioned steps, all cryptographic keys are stored and
accessed via the API of the Key class and its subclasses (FCS_CKM.3-KL-JCS).
Note 2:
FCS_CKM.1/CA of the composite ST is not mapped to FCS_CKM.1 of the platform ST
because no asymmetric key pairs are generated by the TOE during establishment of CA. Only
static key pair loaded or generated during personalization is used. Generation of this static key
pair is covered by separate SFR: FCS_CKM.1/CAPK.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 74 of 106 Version 3.1.19.0
8.1.3 Security assurance requirements
It is shown in Table 8.3 that the security assurance requirements of the composite evaluation
represent a subset of the SARs of the underlying platform.
Table 8.3: Security assurance requirements of the platform ST and composite ST
Assurance component
Platform ST
Compare Assurance component
Composite ST
Development
ADV_ARC.1 = ADV_ARC.1
ADV_FSP.5  ADV_FSP.4
ADV_IMP.1 = ADV_IMP.1
ADV_INT.2  -
ADV_TDS.4  ADV_TDS.3
Guidance documents
AGD_OPE.1 = AGD_OPE.1
AGD_PRE.1 = AGD_PRE.1
Life-cycle support
ALC_CMC.4 = ALC_CMC.4
ALC_CMS.5  ALC_CMS.4
ALC_DEL.1 = ALC_DEL.1
ALC_DVS.2 = ALC_DVS.2
ALC_LCD.1 = ALC_LCD.1
ALC_TAT.2 = ALC_TAT.1
Security target evaluation
ASE_CCL.1 = ASE_CCL.1
ASE_ECD.1 = ASE_ECD.1
ASE_INT.1 = ASE_INT.1
ASE_OBJ.2 = ASE_OBJ.2
ASE_REQ.2 = ASE_REQ.2
ASE_SPD.1 = ASE_SPD.1
ASE_TSS.1 = ASE_TSS.1
Tests
ATE_COV.2 = ATE_COV.2
ATE_DPT.3  ATE_DPT.2
ATE_FUN.1 = ATE_FUN.1
ATE_IND.2 = ATE_IND.2
Vulnerability assessment
AVA_VAN.5 = AVA_VAN.5
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 75 of 106
8.2 Compatibility between the composite ST and the platform ST
8.2.1 Threats
The following threats of the composite ST are directly related to the platform functionality:
 T.Phys-Tamper,
 T.Malfunction,
 T.Abuse-Func,
 T.Information_Leakage,
 T.Forgery,
 T.Skimming,
 T.Eavesdropping,
 T.Tracing,
 T.Counterfeit,
 T.Read_Sensitive_Data.
The following IC threats are relevant for the TOE:
 T.LEAK-INHERENT,
 T.PHYS_PROBING,
 T.MALFUNCTION,
 T.PHYS_MANIPULATION,
 T.LEAK-FORCED,
 T.ABUSE-FUNC,
 T.RND,
 T.MEM-ACCESS.
The following operating system threats are relevant for the TOE:
 T.INVALID-INPUT,
 T.INVALID-ORDER,
 T.FORCED-RESET,
 T.REPLAY,
 T.BRUTE-FORCE,
 T.LIFE-CYCLE,
 T.CRYPTO,
 T.INSTALL,
 T.DELETION,
 T.PHYSICAL,
 T.Skimming,
 T.Eavesdropping,
 T.Tracing,
 T.Counterfeit,
 T.Forgery,
 T.Phys_Tamper,
 T.Read_Sensitive_Data,
 T.Abuse_Func,
 T.Information_Leakage,
 T.Malfunction.
T.IMPERSONATE of the operating system is not applicable to the composite threats as
Cardholder Verification Method (CVM) consisting of a Global PIN is not used by the TOE.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 76 of 106 Version 3.1.19.0
T.RESOURCES, T.CONFID-JCS-CODE, T.CONFID-JCS-DATA, T.INTEG-JCS-CODE,
T.INTEG-JCS-DATA, T.INTEG-APPLI-CODE, T.INTEG-APPLI-DATA, T.SID.1, T.SID.2,
T.CONFID-APPLI-DATA, T.EXE-CODE.1, T.EXE-CODE.2, T.OBJ-DELETION and
T.RECEIPT of the operating system involve executing a malware application. These threads
are not applicable to the composite threats as the TOE contains only single instance of the
SmartApp-ID applet (the e-passport application) and no other application is allowed.
T.INTEG-APPLI-CODE.LOAD and T.INTEG-APPLI-DATA.LOAD of the operating
system are not applicable to the composite threats as no application loading is allowed during
the whole life cycle of the TOE.
T.NATIVE of the operating system is not applicable to the composite threats as no native
code is allowed.
Mapping of the platform threats to the composite ST threats is provided in Table 8.4.
Table 8.4: Threats mapping
Composite
ST
threats
T.Phys-Tamper
T.Malfunction
T.Abuse-Func
T.Information_Leakage
T.Forgery
T.Skimming
T.Eavesdropping
T.Tracing
T.Counterfeit
T.Read_Sensitive_Data
Platform ST threats
T.LEAK-INHERENT X X
T.PHYS_PROBING X X
T.MALFUNCTION X X X X
T.PHYS_MANIPULATION X X X
T.LEAK-FORCED X X
T.ABUSE-FUNC X X
T.RND X
T.MEM-ACCESS X
T.INVALID-INPUT X
T.INVALID-ORDER X
T.FORCED-RESET X
T.REPLAY X
T.BRUTE-FORCE X
T.LIFE-CYCLE X
T.CRYPTO X
T.INSTALL X
T.DELETION X
T.PHYSICAL X X X X
T.Skimming X
T.Eavesdropping X
T.Tracing X
T.Counterfeit X
T.Forgery X
T.Phys_Tamper X
T.Read_Sensitive_Data X
T.Abuse_Func X
T.Information_Leakage X
T.Malfunction X
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 77 of 106
T.Phys-Tamper
T.LEAK-INHERENT, T.LEAK-FORCED, T.PHYS_PROBING, T.MALFUNCTION,
T.PHYS-MANIPULATION and T.RND contribute to T.Phys-Tamper as physical TOE
interfaces could be used to exploit vulnerabilities.
T.PHYSICAL contributes to T.Phys-Tamper with physical tampering of the TOE.
T.Phys_Tamper of the platform (LDS FS API) matches T.Phys_Tamper of the TOE.
T.Malfunction
T.INVALID-INPUT and T.INVALID-ORDER contribute to T.Malfunction with sending
unexpected APDUs.
T.FORCED-RESET contributes to T.Malfunction with inappropriate termination of selected
operations.
T.PHYSICAL contributes to T.Malfunction with physical tampering of the TOE that also
includes the modification of the runtime execution of the TOE code through alteration of the
intended execution order of (set of) instructions.
T.MALFUNCTION contributes to T.Malfunction with TOE malfunctions caused by the
attacker applying environmental stress.
T.Malfunction of the platform (LDS FS API) matches T.Malfunction of the TOE.
T.Abuse-Func
T.MEM-ACCESS contributes to T.Abuse-Func as security violations either accidentally
or deliberately could access restricted data (which may include code) or privilege levels.
T.REPLAY contributes to T.Abuse-Func with reusing operations, which have been
successfully performed by Manufacturer and/or Personalization Agent during the TOE
preparation.
T.LIFE-CYCLE contributes to T.Abuse-Func with exploit APDUs, which have been blocked
before TOE delivery.
T.INSTALL and T.DELETION contribute to T.Abuse-Func with usage of card management
functionalities, which have been blocked before TOE delivery.
T.ABUSE-FUNC contributes to T.Abuse-Func with usage of the TOE functionality, which
have been blocked before TOE delivery.
T.Abuse-Func of the platform (LDS FS API) matches T.Abuse-Func of the TOE.
T.Information_Leakage
T.LEAK-INHERENT, T.PHYS_PROBING, T.MALFUNCTION, T.LEAK-FORCED,
T.PHYS-MANIPULATION and T.ABUSE-FUNC contribute to T.Information_Leakage
as physical TOE interfaces could be used to exploit information leaking from the TOE during
its usage.
T.BRUTE-FORCE contributes to T.Information_Leakage with brute force attacks on
authentication mechanism used by the TOE.
T.CRYPTO contributes to T.Information_Leakage with cryptographic and brute force attacks
on cryptographic algorithms used by the TOE.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 78 of 106 Version 3.1.19.0
T.PHYSICAL contributes to T.Information_Leakage with IC failure analysis, electrical
probing and DPA.
T.Information_Leakage of the platform (LDS FS API) matches T.Information_Leakage of the
TOE.
T.Forgery
T.PHYS_MANIPULATION and T.MALFUNCTION contribute to T.Forgery with physical
modifications of the User Data and/or the TSF-Data stored in the TOE and/or exchanged
between the TOE and the inspection system.
T.PHYSICAL contributes to T.Forgery with physical modifications of the User Data and/or
the TSF-Data stored in the TOE and/or exchanged between the TOE and the inspection
system.
T.Forgery of the platform (LDS FS API) matches T.Forgery of the TOE.
T.Skimming
T.Skimming of the platform (LDS FS API) matches T.Skimming of the TOE.
T.Eavesdropping
T.Eavesdropping of the platform (LDS FS API) matches T.Eavesdropping of the TOE.
T.Tracing
T.Tracing of the platform (LDS FS API) matches T.Tracing of the TOE.
T.Counterfeit
T.Counterfeit of the platform (LDS FS API) matches T.Counterfeit of the TOE.
T.Read_Sensitive_Data
T.Read_Sensitive_Data of the platform (LDS FS API) matches T.Read_Sensitive_Data
of the TOE.
8.2.2 Organizational security policies
The following organizational security policies coming from the composite ST are not related
to the platform:
 P.Pre-Operational,
 P.Card_PKI,
 P.Trustworthy_PKI,
 P.Sensitive_Data,
 P.Personalisation.
No organizational security policy of IC is relevant for the TOE.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 79 of 106
The following organizational security policies of the operating system are relevant for the
TOE:
 OSP.Pre-Operational,
 OSP.Card_PKI,
 OSP.Trustworthy_PKI,
 OSP.Sensitive_Data,
 OSP.MRTD_Personalization.
OSP.BAC-PP of the operating system is not relevant as BAC is excluded from the evaluation.
OSP.Manufact is not relevant as operating system (LDS FS API) functionality relevant for
this policy is not used.
Mapping of the platform organizational security policies to the composite ST organizational
security policies is provided in Table 8.5.
Table 8.5: Organizational security policies mappings
Composite
ST
OSP
OSP.Pre-Operational
OSP.Card_PKI
OSP.Trustworthy_PKI
OSP.Sensitive_Data
OSP.MRTD_Personalization
Platform ST OSP
P.Pre-Operational X
P.Card_PKI X
P.Trustworthy_PKI X
P.Sensitive_Data X
P.Personalisation X
OSP.Pre-Operational matches P.Pre-Operational.
OSP.Card_PKI matches P.Card_PKI.
OSP.Trustworthy_PKI matches P.Trustworthy_PKI.
OSP.Sensitive_Data matches P.Sensitive_Data.
OSP.MRTD_Personalization does not contradict to P.Personalisation.
8.2.3 Assumptions
The assumptions of the composite ST make no assumptions on the platform.
The following IC assumptions are relevant for the TOE:
 A.PROCESS-SEC-IC,
 A.PLAT-APPL,
 A.RESP-APPL,
 A.KEY_FUNCTION.
A.PROCESS-SEC-IC is covered by A.MRTD_Manufact of the operating system.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 80 of 106 Version 3.1.19.0
A.PLAT-APPL is addressed with evaluations listed in 1.1.2.
A.RESP-APPL is addressed with OT.Data_Integrity, OT.Prot_Abuse-Func and
OT.Prot_Phys-Tamper of the composite ST.
A.KEY_FUNCTION is addressed with OT.Prot_Inf_Leak of the composite ST.
The following operating system assumptions are relevant for the TOE:
 A.MRTD_Manufact,
 A.MRTD_Delivery,
 A.Auth_PKI,
 A.Passive_Auth,
 A.Insp_Sys,
 A.Personalization.
A.MRTD_Manufact is addressed with the package of ALC documents.
A.MRTD_Delivery is addressed with ALC_DEL.1.
A.Auth_PKI matches A.Auth_PKI of the composite ST.
A.Passive_Auth matches A.Passive_Auth of the composite ST.
A.Insp_Sys is addressed with AGD_OPE.1.
A.Personalization is addressed with OE.Personalization of the composite ST.
8.2.4 Security objectives of the TOE
The following security objectives of the TOE are related to the platform:
 OT.Prot_Abuse-Func,
 OT.Prot_Inf_Leak,
 OT.Prot_Phys-Tamper,
 OT.Prot_Malfunction,
 OT.Data_Integrity,
 OT.Data_Authenticity,
 OT.Data_Confidentiality,
 OT.Tracing,
 OT.AC_PersAccess,
 OT.Sens_Data_Conf,
 OT.Chip_Auth_Proof.
The following security objectives of the IC contribute to security objectives of the TOE:
 O.PHYS-PROBING,
 O.MALFUNCTION,
 O.PHYS-MANIPULATION,
 O.ABUSE-FUNC,
 O.LEAK-FORCED,
 O.LEAK-INHERENT.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 81 of 106
The following security objectives of the operating system contribute to security objectives
of the TOE:
 O.LIFE-CYCLE,
 O.ERROR-COUNTERS,
 O.RECOVERY,
 O.LOCK,
 O.VERIFICATION,
 O.OS-SUPPORT,
 O.OPERATE,
 O.REALLOCATION,
 O.ALARM,
 O.AC_Pers,
 O.Data_Int,
 O.Data_Confidentiality,
 O.Sens_Data_Conf,
 O.Prot_Phys-Tamper,
 O.Data_Authenticity,
 O.Tracing,
 O.Prot_Abuse_Func,
 O.Prot_Inf_Leak,
 O.Prot_Malfunction,
 O.Chip_Auth_Proof.
Other security objectives of the platform are not related to the composite ST.
Mapping between security objectives of the platform and security objectives of the TOE
is given in Table 8.6.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 82 of 106 Version 3.1.19.0
Table 8.6: Mapping security objectives of the platform and of the TOE
SO
of
the
TOE
OT.Prot_Abuse-Func
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfunction
OT.Data_Integrity
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Tracing
OT.AC_PersAccess
OT.Sens_Data_Conf
OT.Chip_Auth_Proof
SO of the platform
O.PHYS-PROBING X
O.MALFUNCTION X X
O.PHYS-MANIPULATION X
O.ABUSE-FUNC X
O.LEAK-FORCED X
O.LEAK-INHERENT X
O.LIFE-CYCLE X
O.ERROR-COUNTERS X X
O.RECOVERY X X X
O.LOCK X X X
O.VERIFICATION X X
O.OS-SUPPORT X X X X
O.OPERATE X X X
O.REALLOCATION X
O.ALARM X X
O.AC_Pers X
O.Data_Int X
O.Data_Confidentiality X
O.Sens_Data_Conf X
O.Chip_Auth_Proof X
O.Prot_Phys-Tamper X
O.Data_Authenticity X
O.Tracing X
O.Prot_Inf_Leak X
O.Prot_Malfunction X
O.Prot_Abuse_Func X
8.2.5 Security objectives of the operational environment
The following security objectives of the operational environment coming from the composite
ST are related to the platform:
 OE.Legislative_Compliance,
 OE.Passive_Auth_Sign,
 OE.Personalization,
 OE.Terminal,
 OE.Travel_Document_Holder,
 OE.Auth_Key_Travel_Document,
 OE.Authoriz_Sens_Data,
 OE.Exam_Travel_Document,
 OE.Prot_Logical_Travel_Document,
 OE.Ext_Insp_Systems.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 83 of 106
The following security objectives of the operational environment coming from ST of IC are
relevant for the TOE:
 OE.PLAT-APPL,
 OE.RESP-APPL,
 OE.PROCESS-SEC-IC.
The following security objectives of the operational environment coming from ST of the
operating system are relevant for the TOE:
 OE.SCP.IC,
 OE.SCP.RECOVERY,
 OE.SCP.SUPPORT,
 OE.VERIFICATION,
 OE.CODE-EVIDENCE,
 OE.MRTD_Delivery,
 OE.MRTD_Manufact,
 OE.Authoriz_Sens_Data,
 OE.Ext_Insp_Systems,
 OE.Auth_Key_MRTD,
 OE.Legislative_Compliance,
 OE.Travel_Document_Holder,
 OE.Passive_Auth_Sign,
 OE.Personalization,
 OE.Exam_MRTD,
 OE.Prot_Logical_MRTD,
 OE.Passive_Auth_Verif.
Mapping between security objectives of the platform operational environment and security
objectives of the TOE operational environment is given in Table 8.7.
OE.PLAT-APPL, OE.RESP-APPL, OE.SCP.IC, OE.SCP.RECOVERY, OE.SCP.SUPPORT
could not be mapped. They are addressed with evaluations listed in 1.1.2.
OE.PROCESS-SEC-IC, OE.VERIFICATION, OE.CODE-EVIDENCE,
OE.MRTD_Manufact could not be mapped. They are addressed with the package of ALC
documents.
OE.MRTD_Delivery could not be mapped. It is addressed with ALC_DEL.1.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 84 of 106 Version 3.1.19.0
Table 8.7: Mappings of security objectives for the operational environment
SO
of
the
TOE
operational
environment
OE.Legislative_Compliance
OE.Passive_Auth_Sign
OE.Personalization
OE.Terminal
OE.Travel_Document_Holder
OE.Auth_Key_Travel_Document
OE.Authoriz_Sens_Data
OE.Exam_Travel_Document
OE.Prot_Logical_Travel_Document
OE.Ext_Insp_Systems
SO of the platform operational environment
OE.Authoriz_Sens_Data X
OE.Ext_Insp_Systems X
OE.Auth_Key_MRTD X
OE.Legislative_Compliance X
OE.Travel_Document_Holder X
OE.Passive_Auth_Sign X
OE.Personalization X
OE.Exam_MRTD X X
OE.Prot_Logical_MRTD X X
OE.Passive_Auth_Verif X
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 85 of 106
Annex A Supported elliptic curves
The TOE supports the following elliptic curves:
 NIST P-224 (secp224r1),
 BrainpoolP224r1,
 NIST P-256 (secp256r1),
 BrainpoolP256r1,
 BrainpoolP320r1,
 NIST P-384 (secp384r1),
 BrainpoolP384r1,
 BrainpoolP512r1,
 NIST P-521 (secp521r1).
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 86 of 106 Version 3.1.19.0
Annex B Bibliography
B.1 Common Criteria documents
[CC-Part1] Common Criteria for Information Technology Security Evaluation,
Part 1: Introduction and general model; CCMB-2012-09-001;
Version 3.1, Revision 4, September 2012
[CC-Part2] Common Criteria for Information Technology Security Evaluation,
Part 2: Security functional components; CCMB-2012-09-002;
Version 3.1, Revision 4, September 2012
[CC-Part3] Common Criteria for Information Technology Security Evaluation,
Part 3: Security assurance requirements; CCMB-2012-09-003;
Version 3.1, Revision 4, September 2012
[CC-CEM] Common Methodology for Information Technology Security Evaluation,
Evaluation methodology; CCMB-2012-09-004; Version 3.1, Revision 4,
September 2012
[CC-Smartcard] Common Criteria – Supporting Document Guidance – Smartcard
Evaluation, CCDB-2010-03-001, Version 2.0, February 2010
B.2 Protection profiles
[PP-BAC] Common Criteria Protection Profile Machine Readable Travel Document
with „ICAO Application", Basic Access Control, BSI-PP-0055,
Version 1.10, 25th
March 2009
[PP-PACE] Common Criteria Protection Profile Machine Readable Travel Document
using Standard Inspection Procedure with PACE (PACE PP),
BSI-CC-PP-0068-V2-2011, Version 1.0, 2nd
November 2011
[PP-EAC] Common Criteria Protection Profile Machine Readable Travel Document
with „ICAO Application", Extended Access Control with PACE
(EAC PP), BSI-CC-PP-0056-V2-2012, version 1.3.2, 5th
December 2012
[PP-IC] Security IC Platform Protection Profile; registered and certified by BSI
(Bundesamt für Sicherheit in der Informationstechnik) under the
reference BSI-PP-0035-2007, Version 1.0, June 2007
B.3 Travel document specifications
[Doc9303] [Doc9303-1V2] or [Doc9303-3V2]
[Doc9303-1V2] ICAO Doc 9303: Machine Readable Travel Documents – Part 1:
Machine Readable Passports, Volume 2 : Specifications for
Electronically Enabled Passports with Biometric Identification
Capability, 6th
edition, 2006
[Doc9303-3V2] ICAO Doc 9303: Machine Readable Travel Documents – Part 3:
Machine Readable Official Travel Documents, Volume 2 : Specifications
for Electronically Enabled MRTDs with Biometric Identification
Capability, 3rd
edition, 2008
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 87 of 106
[SAC] ICAO Technical Report: Machine Readable Travel Documents –
Supplemental Access Control for Machine Readable Travel Documents,
Version 1.01, 11 November 2010
[TR03110-1] BSI Technical Guideline TR-03110-1: Advanced Security Mechanisms
for Machine Readable Travel Documents – Part 1: eMRTDs with
BAC/PACEv2 and EACv1, Version 2.10, 20 March 2012
[TR03110-3] BSI Technical Guideline TR-03110-3: Advanced Security Mechanisms
for Machine Readable Travel Documents – Part 3: Common
Specifications, Version 2.10, 20 March 2012
B.4 Platform documentation
[IC_ST] Security Target, M7820 A11 and M11 including optional Software
Libraries RSA - EC – SHA-2 – Toolbox, Version 1.6, 2012-08-28
[jTOP_ST] Java Card Open Platform for MRTD Security Target LITE,
Reference/version PU-2011-RT-484-v46-1.0-LITE, 2013-05-18
[jTOP_PRE] jTOP INFv#46 (SLJ 52 Gxx yyy zL) Preparative Procedures,
Reference/version CP-2011-RT-731-46-1.0, 2012-06-01
[jTOP_OPE] jTOP INFv#46 (SLJ 52 Gxx yyy zL) Operational User Guidance,
Reference/version CP-2011-RT-732-46-1.3, 2013-02-04
B.5 Cryptographic standards
[TR03111] BSI Technical Guideline TR-03111: Elliptic Curve Cryptography,
Version 1.11, 17.04.2009
[ISO9797-1] ISO/IEC 9797-1:1999: Information technology – Security techniques –
Message Authentication Codes (MACs) – Part 1: Mechanisms using
a block cipher
[ISO15946-1] ISO/IEC 15946-1:2008: Information technology – Security techniques –
Cryptographic techniques based on elliptic curves – Part 1: General
[ISO15946-2] ISO/IEC 15946-2:2002: Information technology – Security techniques –
Cryptographic techniques based on elliptic curves – Part 2: Digital
signatures
[ISO15946-3] ISO/IEC 15946-3:2002 Information technology – Security techniques –
Cryptographic techniques based on elliptic curves – Part 3: Key
establishment
[FIPS46-3] Federal Information Processing Standards Publication 46-3: Data
Encryption Standard (DES), U.S. Department of Commerce / National
Institute of Standards and Technology, reaffirmed October 25th
, 1999
[FIPS81] Federal Information Processing Standards Publication 81: DES Modes of
Operation, U.S. Department of Commerce / National Institute of
Standards and Technology, December 2nd
, 1980
[FIPS180-2] Federal Information Processing Standards Publication 180-2: Secure
Hash Standard (SHS), U.S. Department of Commerce / National
Institute of Standards and Technology, August 1st
2002
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 88 of 106 Version 3.1.19.0
[FIPS197] Federal Information Processing Standards Publication 197: Advanced
Encryption Standard (AES), U.S. Department of Commerce / National
Institute of Standards and Technology, November 26th
2001
[NIST800-38B] NIST Special Publication 800-38B: Recommendation for Block Cipher
Modes of Operation – The CMAC Mode for Authentication, U.S.
Department of Commerce / National Institute of Standards and
Technology, May 2005
[PKCS#1] PKCS #1 v2.1: RSA Cryptography Standard, RSA Laboratories,
14 June 2002
[PKCS#3] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
Laboratories Technical Note, Version 1.4, Revised, 1 November 1993
[IEEE1363] IEEE 1363-2000: IEEE Standard Specifications for Public-Key
Cryptography, 2002-08-06
[AIS20/AIS31] Wolfgang Killmann (T-Systems GEI GmbH), Werner Schindler (BSI),
A proposal for: Functionality classes for random number generators,
Version 2.0, 18 September 2011
[RGS] Référentiel Général de Sécurité, Annexe B1: Mécanismes
cryptographiques – Règles et recommandations concernant le choix et le
dimensionnement des mécanismes cryptographiques de niveau de
robustesse “standard”. ANSSI, version 1.20, 26 janvier 2010
B.6 Other
[ISO7816-2] ISO/IEC 7816-2:2007: Identification cards – Integrated circuit cards –
Part 2: Cards with contacts – Dimensions and location of the contacts
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 89 of 106
Annex C Acronyms
C.1 Organizations
ANSSI Agence Nationale de la Sécurité des Systèmes d'Information
BSI Bundesamt für Sicherheit in der Informationstechnik
IFX Infineon Technologies
PWPW Polska Wytwórnia Papierów Wartościowych S.A.
TL Trusted Logic
TUViT TÜV Informationstechnik GmbH
C.2 Terms
AS application software
BAC Basic Access Control
BIS basic inspection system
BIS-BAC basic inspection system with BAC
BIS-PACE basic inspection system with PACE
BS basic software
CA chip authentication
CAD card acceptance device
CC common criteria
CSCA country signing certification authority
CVCA country verifying certification authority
DS document signer
DV document verifier
EAL evaluation assurance level
EIS extended inspection system
ES embedded software
IC integrated circuit
IS inspection system
JCVM java card virtual machine
OSP organization security policy
PACE password authenticated connection establishment
PP protection profile
SAR security assurance requirements
SO security objectives
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 90 of 106 Version 3.1.19.0
SOD document security object
ST security target
TA terminal authentication
TOE target of evaluation
TSF TOE security function
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 91 of 106
Annex D Glossary
D.1 Security evaluation terms
Application Note
Optional informative part of the protection profile containing sensitive supporting information
that is considered relevant or useful for the construction, evaluation, or use of the TOE.
Common Criteria
A set of rules and procedures for evaluating the security properties of a product.
Evaluation Assurance Level
A set of assurance requirements for a product, its manufacturing process and its security
evaluation specified by Common Criteria.
Protection Profile
A document specifying security requirements for a class of products that conforms
in structure and content to rules specified by Common Criteria.
Security Target
A document specifying security requirements for a particular product that conforms
in structure and content to rules specified by Common Criteria, which may be based on one
or more protection profiles.
Target of Evaluation
Abstract reference in a document, such as a protection profile, for a particular product that
meets specific security requirements.
Target of Evaluation Security Functions
Functions implemented by the TOE to meet the requirements specified for it in a protection
profile or security target.
TSF Data
Data created by and for the TOE, that might affect the operation of the TOE.
User Data
Data created by and for the user, that does not affect the operation of the TSF.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 92 of 106 Version 3.1.19.0
D.2 Smartcard terms
Integrated Circuit
Electronic component(s) designed to perform processing and/or memory functions
(i.e. the hardware component containing the micro-controller and IC dedicated software).
A typical IC comprises: a processing unit, security components, I/O ports and volatile and
non-volatile memories. It also includes any IC designer/manufacturer proprietary
IC dedicated software, required for testing purposes. This IC dedicated software may be either
IC embedded software (also known as IC firmware) or security-relevant parts of tests
programs outside the IC. The IC may include any IC pre-personalization data.
IC Dedicated Software
IC proprietary software embedded in a smartcard IC (also known as IC firmware) and
developed by the IC Developer. Such software is required for testing purposes (IC Dedicated
Test Software) but may provide additional services to facilitate usage of the hardware and/or
to provide additional services.
IC Dedicated Test Software
That part of the IC Dedicated Software (refer to above) which is used to test the device but
which does not provide functionality during Phases 4 to 7.
Phases of the smartcard life-cycle are described in [CC-Smartcard], figure 4.
IC Dedicated Support Software
That part of the IC Dedicated Software (refer to above) which provides functions in Phases 4
to 7. The usage of parts of the IC Dedicated Software might be restricted to certain phases.
Phases of the smartcard life-cycle are described in [CC-Smartcard], figure 4.
Identification Data
Any data defined by the Integrated Circuit manufacturer and injected into the nonvolatile
memory by the Integrated Circuit manufacturer (Phase 3). These data are for instance used for
traceability.
Phases of the smartcard life-cycle are described in [CC-Smartcard], figure 4.
Basic Software
Smartcard embedded software in charge of generic functions of the Smartcard IC, such
as an operating system, general routines and interpreters.
Application Software
Smartcard embedded software (may be in ROM or loaded onto a platform in EEPROM
or Flash Memory). This is software dedicated to the applications.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 93 of 106
Embedded Software
Software embedded in a smartcard IC but not developed by the IC Designer. This comprises
embedded software in charge of generic functions of the Smartcard IC, such as an operating
system, general routines and interpreters (Smartcard Basic Software - BS) and embedded
software dedicated to applications (Smartcard Application Software - AS). The Smartcard
Embedded Software is designed in Phase 1 and embedded into the Smartcard IC in Phase 3
or in later phases of the smartcard product life-cycle.
Phases of the smartcard life-cycle are described in [CC-Smartcard], figure 4.
Smartcard Personalization
Final process under the responsibility of the card issuer, through which a smartcard is to be
configured, security parameters loaded and secret keys set. At the end of the personalization
process, the smartcard is irreversibly set into “user mode”. Hence, it becomes fully
operational and can be delivered to the end user.
IC Platform
Usually refers to a smartcard component which may undergo an evaluation process,
as a complete Target of Evaluation (TOE) in itself, but which is not an end-user product
(i.e. a smartcard component without any Application Software loaded).
IC Initialization
Process of writing Initialization Data to the IC.
IC Initialization Data
Any data defined by the IC Manufacturer and injected into the non-volatile memory during
the manufacturing process. These data are for instance used for traceability and for IC
identification.
IC Pre-personalization
Process performed at the IC manufacturer site, through which customer data can be loaded
onto the IC, prior to the IC being irreversibly set into “issuer mode”.
IC Pre-personalization Data
Any data supplied by the software developer that is injected into the non-volatile memory
by the Integrated Circuits manufacturer (Phase 3). These data are for instance used for
traceability and/or to secure shipment between phases.
Phases of the smartcard life-cycle are described in [CC-Smartcard], figure 4.
Smartcard Product
A product corresponds to a fully operational smartcard, composed of both IC and complete
ES, including application software as appropriate.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 94 of 106 Version 3.1.19.0
IC Developer
The entity which develops the integrated circuit, the IC Dedicated Software (firmware) and
the guidance documentation.
IC Manufacturer
Institution (or its agent) responsible for the IC manufacturing, testing, and
pre-personalization.
ES Developer or AS Developer
Institution (or its agent) responsible for the smartcard Embedded Software or Application
Software development and the specification of IC pre-personalization requirements.
Card Manufacturer
The customer of the IC Manufacturer who receives the TOE during TOE Delivery. The Card
Manufacturer includes all roles after TOE Delivery up to Phase 7. The Card Manufacturer has
the following roles: (i) the Smartcard Product Manufacturer (Phase 5); (ii) the Personalizer
(Phase 6). If the TOE is delivered after Phase 3 in the form of wafers or sawn wafers (dice)
he also assumes the role of the IC Packaging Manufacturer (Phase 4). Usually, the Card
Manufacturer is also the ES or AS developer.
Phases of the smartcard life-cycle are described in [CC-Smartcard], figure 4.
Card Issuer
Customer for a product who is in charge of the issuance of the product to the smartcard
holders (end users).
D.3 Travel documents terms
Manufacturer
Generic term for the IC Manufacturer producing integrated circuit and the travel document
manufacturer completing the IC to the travel document.
Personalization
The process by which the Personalization Data are stored in and unambiguously, inseparably
associated with the travel document. This may also include the optional biometric data
collected during the enrolment.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 95 of 106
Personalization Agent
An organization acting on behalf of the travel document issuer to personalize the travel
document for the travel document holder by some or all of the following activities:
1. establishing the identity of the travel document holder for the biographic data in the travel
document,
2. enrolling the biometric reference data of the travel document holder,
3. writing a subset of these data on the physical travel document (optical personalization)
and storing them in the travel document (electronic personalization) for the travel
document holder,
4. writing the document details data,
5. writing the initial TSF data,
6. signing the Document Security Object (in the role of DS).
Personalization Data
A set of data which includes:
1. individual-related data (biographic and biometric data) of the travel document holder,
2. dedicated document details data, and
3. dedicated initial TSF data (including the Document Security Object).
Country Signing Certification Authority
An organization enforcing the policy of the travel document issuer with respect to confirming
correctness of user and TSF data stored in the travel document. The CSCA represents the
country specific root of the PKI for the travel documents and creates the Document Signer
certificates within this PKI.
Document Signer
An organization enforcing the policy of the CSCA and signing the document security object
stored (carrying hashes of LDS data groups) on the travel document for passive
authentication.
Country Verifying Certification Authority
An organization enforcing the privacy policy of the travel document Issuer with respect
to protection of user data stored in the travel document (at a trial of a terminal to get an access
to these data). The CVCA represents the country specific root of the PKI for the terminals
using it and creates the Document Verifier certificates within this PKI. Updates of the public
key of the CVCA are distributed in form of CVCA link-certificates.
Document Verifier
An organization enforcing the policies of the CVCA and of a Service Provider
(here: of a governmental organization / inspection authority) and managing terminals
belonging together (e.g. terminals operated by a State’s border police), by – inter alia –
issuing Terminal Certificates. A Document Verifier is therefore a Certification Authority,
authorized by at least the national CVCA to issue certificates for national terminals.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 96 of 106 Version 3.1.19.0
Inspection System
A technical system used by the border control officer of the Receiving State (i) examining
an travel document presented by the traveler and verifying its authenticity and (ii) verifying
the traveler as travel document holder.
Issuing State
The country issuing the travel document.
Issuing Organization
Organization authorized to issue an official travel document.
Receiving State
The country to which the traveler is applying for entry.
Basic Inspection System
An inspection system which implements the terminals part of the Basic Access Control
mechanism and authenticates itself to the travel document’s chip using the document basic
access keys derived from the printed MRZ data for reading the logical travel document.
Basic Inspection System with BAC
Another name of Basic Inspection System.
Basic Inspection System with PACE
An inspection system which implements the terminal’s part of the PACE protocol and
authenticates itself to the travel document using a shared password (PACE password) for
reading the logical travel document.
Extended Inspection System
A role of a terminal as part of an Inspection System which is in addition to Basic Inspection
System authorized by the Issuing State or Organization to read the optional biometric
reference data and supports the terminals part of the Extended Access Control authentication
mechanism.
Card Access Number
Password derived from a short number printed on the front side of the data page.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 97 of 106
Annex E Cryptographic functionality
Table E.1 presents the cryptographic mechanisms supported by the TOE and lists all cryptographic algorithms used by those mechanisms.
Table E.1: Cryptographic functionality
No. Cryptographic mechanism Purpose Used algorithms Key size in
bits
Standard of
implementation
Standard of
application
Comments
Applet configuration, pre-personalization and personalization
1 Symmetric authentication
mechanism
Authentication Triple-DES in CBC mode 168 FIPS PUB 46-3,
FIPS PUB 81
n/a Uses 64-bit
challenges generated
with (2)
2 Random number generator Authentication
challenges
HMAC_DRBG,
HMAC,
SHA-256,
ECDSA key generation
n/a NIST SP 800-90A,
RFC 2104,
FIPS PUB 180-2,
ISO/IEC 15946-1
AIS 20/31,
BSI TR-03116-2
DRG.3, NIST P-256
3 Secure messaginga
Confidentiality Triple-DES in CBC mode 112 FIPS PUB 46-3,
FIPS PUB 81
n/a
Integrity Retail-MAC 112 ISO/IEC 9797-1 n/a
4 Secure messaginga
Confidentiality AES in CBC mode 128, 192, 256 FIPS PUB 197 n/a
Integrity CMAC 128, 192, 256 FIPS PUB 197,
NIST SP 800-38B
n/a
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 98 of 106 Version 3.1.19.0
Table E.1 (continued)
No. Cryptographic mechanism Purpose Used algorithms Key size in
bits
Standard of
implementation
Standard of
application
Comments
Applet operational use
5 Random number generatorb
PACE nonces,
TA challenges
HMAC_DRBG,
HMAC,
SHA-256,
ECDSA key generation
n/a NIST SP 800-90A,
RFC 2104,
FIPS PUB 180-2,
ISO/IEC 15946-1
AIS 20/31,
BSI TR-03116-2
DRG.3, NIST P-256
6 Secure messagingc
Confidentiality Triple-DES in CBC mode 112 FIPS PUB 46-3,
FIPS PUB 81
ICAO SAC
Integrity Retail-MAC 112 ISO/IEC 9797-1 ICAO SAC
7 Secure messagingc
Confidentiality AES in CBC mode 128, 192, 256 FIPS PUB 197 ICAO SAC
Integrity CMAC 128, 192, 256 FIPS PUB 197,
NIST SP 800-38B
ICAO SAC
8 PACEd
Authentication Triple-DES in CBC mode 112 FIPS PUB 46-3,
FIPS PUB 81
ICAO SAC Nonce encryption,
128-bit nonce
generated with (5)
Retail-MAC 112 ISO/IEC 9797-1 ICAO SAC Token calculation
Authentication AES in CBC mode 128, 192, 256 FIPS PUB 197 ICAO SAC Nonce encryption,
128-bit nonce
generated with (5)
CMAC 128, 192, 256 FIPS PUB 197,
NIST SP 800-38B
ICAO SAC Token calculation
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 99 of 106
Table E.1 (continued)
No. Cryptographic mechanism Purpose Used algorithms Key size in
bits
Standard of
implementation
Standard of
application
Comments
8 PACE (continued) Key agreement ECDH key generation 224, 256, 320,
384, 512, 521
BSI TR-03111 ICAO SAC NIST P-224,
BrainpoolP224r1,
NIST P-256,
BrainpoolP256r1,
BrainpoolP320r1,
NIST P-384,
BrainpoolP384r1,
BrainpoolP512r1,
NIST P-521
ECDH 224, 256, 320,
384, 512, 521
IEEE P1363 ICAO SAC NIST P-224,
BrainpoolP224r1,
NIST P-256,
BrainpoolP256r1,
BrainpoolP320r1,
NIST P-384,
BrainpoolP384r1,
BrainpoolP512r1,
NIST P-521
Key derivation SHA-1, SHA-256 n/a FIPS PUB 180-2 ICAO SAC
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 100 of 106 Version 3.1.19.0
Table E.1 (continued)
No. Cryptographic mechanism Purpose Used algorithms Key size in
bits
Standard of
implementation
Standard of
application
Comments
9 Chip Authentication (CA)d
Key agreement ECDH key generation 224, 256, 320,
384, 512, 521
BSI TR-03111 BSI TR-03110 NIST P-224,
BrainpoolP224r1,
NIST P-256,
BrainpoolP256r1,
BrainpoolP320r1,
NIST P-384,
BrainpoolP384r1,
BrainpoolP512r1,
NIST P-521
ECDH 224, 256, 320,
384, 512, 521
IEEE P1363 BSI TR-03110 NIST P-224,
BrainpoolP224r1,
NIST P-256,
BrainpoolP256r1,
BrainpoolP320r1,
NIST P-384,
BrainpoolP384r1,
BrainpoolP512r1,
NIST P-521
Key derivation SHA-1, SHA-256 n/a FIPS PUB 180-2 BSI TR-03110
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 101 of 106
Table E.1 (continued)
No. Cryptographic mechanism Purpose Used algorithms Key size in
bits
Standard of
implementation
Standard of
application
Comments
10 Terminal Authentication (TA) Authentication ECDSA with SHA-1,
ECDSA with SHA-224,
ECDSA with SHA-256,
ECDSA with SHA-384,
ECDSA with SHA-512
224, 256, 320,
384, 512, 521
ISO/IEC 15946-1,
ISO/IEC 15946-2
BSI TR-03110 NIST P-224,
BrainpoolP224r1,
NIST P-256,
BrainpoolP256r1,
BrainpoolP320r1,
NIST P-384,
BrainpoolP384r1,
BrainpoolP512r1,
NIST P-521
Terminal creating
the authentication
token selects elliptic
curve and hash
function.
a) Started on an authenticated user request.
b) CA does not use challenges. It covers initialization of new secure messaging session with session keys generated from the ECDH shared
secret. Neither ECDH nor key derivation requires usage of random challenge.
c) Started after PACE and continued with new session keys after CA.
d) PACE and CA do not encrypt/authenticate data transmitted to or from the TOE. They are used only to derive session keys to be used by
secure messaging described in (6) and (7).
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 102 of 106 Version 3.1.19.0
This page is intentionally left blank.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 103 of 106
Annex F Revision history
Version Changes
3.1.0.1 First draft (sections 8.1 and 8.2 need to be completed)
3.1.1.0 The new platform, i.e. IFX SLJ52GDL128CL, IFX SLJ52GDL160CL
Added SHA-1 in the section 7.5 C.
Added the section 7.7 (SF.ActiveAuthentication)
Added the section 8.1 (Separation of the platform TSF)
Section 8.2 – added Threats
Corrected application note reference in FCS_COP.1/CA_ENC
Verified references of cryptographic standards
Updated bibliography
3.1.2.0 Completed content
T.INTEG-APPLI-CODE.LOAD, T.INTEG-APPLI-DATA.LOAD,
T.IMPERSONATE, T.CONFID-JCS-CODE removed from the list
in the section 8.2.1 and from the Table 8.4.
SO added in the section B.2
3.1.3.0 Addressed comments (from 3.1 to 3.11) from the Observation Report 1
Added the section 7.9 (SF.Configuration)
Updated the Table 7.1 (added mapping for SF.Configuration)
Information on usage of ‘LDS File System’ given in Table 8.1 has been
corrected.
Some editorial changes
3.1.4.0 Corrected mappings in Table 8.2
Addressed comment 3.12 from the Observation Report 1 (added
justifications for mappings given in Table 8.2)
Added Developer note for FDP_RIP.1.
Section 8.2.1 reworked
Addressed comment 3.13 from the Observation Report 1 (added
justifications for mappings given in Table 8.4)
Separated security objectives of the IC and the operating system in the
section 8.2.4
Corrected mappings in Table 8.5
Updated bibliography
3.1.5.0 Added section 2.4.
Application note 3 corrected.
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 104 of 106 Version 3.1.19.0
3.1.6.0 Certification ID is given.
FCS_CKM.1/DH_PACE, FCS_CKM.1/CA,
FCS_COP.1/PACE_ENC, FCS_COP.1/CA_ENC,
FCS_COP.1/PACE_MAC, FCS_COP.1/CA_MAC
and relevant Developer notes have been updated to cover additional
options of secure messaging (Triple-DES, AES-128, AES-192).
Developer notes for FIA_UAU.6/PACE and FIA_UAU.6/EAC have
been updated to cover additional options of secure messaging
(Retail-MAC).
Table 8.1 has been updated – evaluation covers secure messaging based
on Triple-DES.
Annex A containing the list of supported elliptic curves has been
introduced. Other annexes have been renumbered accordingly.
Developer notes for FCS_CKM.1/DH_PACE and FCS_CKM.1/CA have
been updated to cover additional elliptic curves.
FCS_CKM.1/CAPK, FCS_COP.1.1/SIG_VER and relevant Developer
notes have been updated to cover additional elliptic curves.
Sections 7.5 and 7.6 have been updated to cover additional options of
secure messaging and/or additional elliptic curves.
Contents from 7.5(D) and 7.7(A) have been removed for the sake of
clarity.
Developer note in 1.3.2 has been extended to provided additional
information concerning the contact interface blocking and allowed applet
instances.
Table 7.2 has been simplified. Relevant Developer note has been
reworked.
The list of cryptographic algorithms given in 1.3.3 has been updated.
3.1.7.0 Mapping of SFRs in chapter 8.1.2 has been reworked.
3.1.8.0 Editorial changes in row FDP_RIP.1 of Table 8.2
3.1.9.0 Mapping of OT.Identification on O.Identifications (given in 8.2.4) has
been incorrect. It has been removed as TOE identification functionality
is implemented directly in the SmartApp-ID applet.
Developer notes in 1.3.4.1 and 1.3.4.2 have been refined.
The commercial identifiers of the platform (given in Table 1.1) have
been updated according to the recommendations of IFX. It resulted also
with updating of 1.1.2, 1.3.1, 7.9 and Developer note from 1.3.2.
3.1.10.0 Added platform certification ID in 1.1.2
Updated [jTOP_ST] bibliography reference
Reworked developer notes in FCS_COP.1/PACE_MAC and
FCS_COP.1/CA_MAC to clarify usage of Retail-MAC and CMAC with
specific symmetric ciphers.
Added reference to [FIPS180-2] in FCS_COP.1/SIG_VER.
PWPW SmartApp-ID 3.1 (IFX): Security Target PUBLIC
Version 3.1.19.0 Page 105 of 106
Clarified list of supported key lengths for ECC algorithm in Table 8.1.
3.1.11.0 Added information about PACE API to Table 8.1
Reworked mapping of SFRs in 8.1.2 to include relevant SFRs for LDS
FS API
Threats relevant for LDS FS API have been added in 8.2.1.
Organizational security policies relevant for LDS FS API have been
added in 8.2.2.
Assumptions relevant for LDS FS API have been added in 8.2.3.
Security objectives for the TOE relevant for LDS FS API have been
added 8.2.4.
Security objectives for operational environment relevant for LDS FS API
have been added in 8.2.5.
3.1.12.0 Corrected references to Annex A
Corrected mapping of SFRs in Table 8.2
3.1.13.0 Changed FCS_RND SFR in 6.1.1.3 to meet class DRG.3
Updated description of SF.Random in 7.3
Replaced FCS_RND.1-APP SFR of the platform with combination of
FCS_COP.1-APP-SHA and FCS_CKM.1-Key_generation-ALG-EC-FP
in chapter 8
3.1.14.0 Editorial changes in 6.1.1.3, 7 and 8
3.1.15.0 Obsolete references to the jTOP random number generator have been
removed from 1.3.3 and 7.5 A.
Developer note given in 6.1.1 (after Application note 31 from
[PP-PACE]) has been deleted.
Description of SF.Random given in 7.3 has been improved.
SFRs for DRG.3 have been corrected.
Developer note 1 given in 6.1.2.3 (after Application note 35 from
[PP-PACE]) has been deleted.
Comments to mapping of RNG-related SFRs have been improved in
Table 8.2.
3.1.16.0 TOE hardware symbol has been corrected in 1.1.2 from …M11 to …A11
Versions of the e-passport application components have been added in
Table 1.2.
References to platform documentation in Bibliography have been
updated.
ISO/IEC 9791-1 has been corrected to ISO/IEC 9797-1.
List of relevant SFRs from platform documentation has been updated in
8.1.2. Two SFRs have been added and mapped to composite SFRs:
FCS_CKM.1/LDS-Diffie-Hellman-Protocol ECDH (PACE) and
PUBLIC PWPW SmartApp-ID 3.1 (IFX): Security Target
Page 106 of 106 Version 3.1.19.0
FCS_CKM.1/LDS-Diffie-Hellman-Protocol ECDH or DH (Chip
Authentication).
List of relevant threats from platform documentation has been updated in
8.2.1. Two threats have been added and mapped to threats of the
composite ST: T.Information_Leakage and T.Malfunction.
List of relevant assumptions from platform documentation has been
updated in 8.2.3. A.Auth_PKI assumption has been added.
List of relevant security objectives of the operating system has been
updated in 8.2.4. Two security objectives have been added and mapped
to security objectives of the TOE: O.Prot_Inf_Leak and
O.Prot_Malfunction.
List of relevant security objectives of the operational environment
coming from ST of the operating system has been updated in 8.2.5.
OE.Exam_Travel_Document has been renamed to OE.Exam_MRTD.
OE.Prot_Logical_Travel_Document has been renamed to
OE.Prot_Logical_MRTD. OE.Passive_Auth_Verif has been added and
mapped to security objectives of the operational environment coming
from the composite ST.
3.1.17.0 Footnote in 1.3.1 clarifying the identification of the chip has been
reworked.
SFRs concerning usage of LDS FS API for key generation during PACE
and CA (FCS_CKM.1/LDS-Diffie-Hellman-Protocol ECDH (PACE) and
FCS_CKM.1/LDS-Diffie-Hellman-Protocol ECDH or DH (Chip
Authentication)) have been removed from 8.1.2 as not relevant for the
composite ST.
3.1.18.0 The FCS_RND.1 has been updated to include reseeding.
3.1.19.0 Annex E has been added.