This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
SECURITY TARGET LITE
FOR IDEAL PASS V2.0.1 BAC APPLICATION
Reference: 2016_2000023039
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 2/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Date Version Revision
01/12/2016 1.0 Document creation
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 3/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Table of contents
1.1 SECURITY TARGET LITE AND TOE REFERENCE ......................................................................... 8
1.2 GENERAL OVERVIEW OF THE TARGET OF EVALUATION (TOE)....................................................... 8
1.2.1 TOE type............................................................................................................... 8
1.2.2 Usage and major security features of the TOE ......................................................... 9
1.2.3 TOE Boundary ......................................................................................................11
1.2.4 Product architecture..............................................................................................11
1.2.5 TOE life cycle........................................................................................................13
2.1 CONFORMANCE WITH THE COMMON CRITERIA ........................................................................17
2.2 CONFORMANCE WITH AN ASSURANCE PACKAGE ........................................................................17
2.3 CONFORMANCE WITH A PROTECTION PROFILE .........................................................................17
2.3.1 Protection Profile reference....................................................................................17
2.3.2 Protection Profile Claims rationale ..........................................................................17
2.4 CONFORMANCE WITH THE CC SUPPORTING DOCUMENTS ............................................................18
2.4.1 Application of Attack Potential to Smartcards ..........................................................18
2.4.2 Composite product evaluation for Smartcards and similar devices ............................18
3.1 ASSETS.........................................................................................................................20
3.2 USERS / SUBJECTS...........................................................................................................20
3.3 THREATS.......................................................................................................................22
3.4 ORGANISATIONAL SECURITY POLICIES ..................................................................................24
3.5 ASSUMPTIONS ................................................................................................................25
4.1 SECURITY OBJECTIVES FOR THE TOE ...................................................................................27
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT.....................................................30
4.3 SECURITY OBJECTIVES RATIONALE ......................................................................................32
4.3.1 Threats ................................................................................................................32
4.3.2 Organisational Security Policies..............................................................................33
4.3.3 Assumptions .........................................................................................................34
4.3.4 SPD and Security Objectives ..................................................................................35
5.1 DEFINITION OF THE FAMILY FAU_SAS.................................................................................39
5.2 DEFINITION OF THE FAMILY FCS_RND ................................................................................40
5.3 DEFINITION OF THE FAMILY FMT_LIM.................................................................................40
5.4 DEFINITION OF THE FAMILY FPT_EMS.................................................................................42
5.5 DEFINITION OF THE FAMILY FIA_API ..................................................................................44
6.1 SECURITY FUNCTIONAL REQUIREMENTS ................................................................................45
6.2 SECURITY ASSURANCE REQUIREMENTS..................................................................................57
6.3 SECURITY REQUIREMENTS RATIONALE ..................................................................................57
6.3.1 Objectives ............................................................................................................57
6.3.2 Rationale tables of Security Objectives and SFRs.....................................................61
6.3.3 Dependencies .......................................................................................................64
6.3.4 Rationale for the Security Assurance Requirements .................................................69
7.1 TOE SUMMARY SPECIFICATION...........................................................................................71
7.1.1 Chip security functionalities ...................................................................................71
7.1.2 Low level security functionalities ............................................................................72
7.1.3 Operating system security functionalities ................................................................72
7.1.4 Application security functionalities..........................................................................74
7.2 SFRS AND TSS...............................................................................................................75
7.2.1 SFRs and TSS - Rationale ......................................................................................75
7.2.2 Association tables of SFRs and TSS ........................................................................80
8.1 SEPARATION OF THE PLATFORM-TSF....................................................................................83
8.2 STATEMENT OF COMPATIBILITY FOR THE SECURITY ASSURANCE REQUIREMENTS ...............................84
8.3 STATEMENT OF COMPATIBILITY FOR THE SECURITY ENVIRONMENT AND THE OBJECTIVES.....................85
8.3.1 Objectives ............................................................................................................85
8.3.2 Threats ................................................................................................................86
8.3.3 Organisational security policies ..............................................................................86
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 4/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
8.3.4 Assumptions .........................................................................................................86
9.1 ACRONYMS ....................................................................................................................88
9.2 CONVENTIONS USED.........................................................................................................89
9.3 DEFINITIONS..................................................................................................................89
10.1 REFERENCE DOCUMENTS ...................................................................................................98
10.2 APPLICABLE DOCUMENTS...................................................................................................99
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 5/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Table of figures
Figure 1: Architecture of the IDeal Pass V2.0.1 ........................................................12
Figure 2: TOE life cycle .........................................................................................13
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 6/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Table of tables
Table 1 - Threats and Security Objectives - Coverage ...............................................35
Table 2 - Security Objectives and Threats - Coverage ...............................................36
Table 3 - OSPs and Security Objectives - Coverage...................................................36
Table 4 - Security Objectives and OSPs - Coverage...................................................37
Table 5 - Assumptions and Security Objectives for the Operational Environment -
Coverage .......................................................................................................37
Table 6 - Security Objectives for the Operational Environment and Assumptions -
Coverage .......................................................................................................38
Table 7 - Security Objectives and SFRs - Coverage ...................................................61
Table 8 - SFRs and Security Objectives ...................................................................63
Table 9 - SFRs dependencies .................................................................................66
Table 10 - SARs dependencies ...............................................................................69
Table 11 - SFRs and TSS - Coverage.......................................................................82
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 7/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 8/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
1 Introduction
1.1 Security Target Lite and TOE reference
ST Lite reference :
Title : Security Target Lite for IDeal PASS V2.0.1 BAC application
Version : 1.0
Security target Lite identifier : 2016_2000023039
TOE reference :
Chip identifier : Infineon M7892 B11 with optional RSA2048/4096 v1.02.013,
EC v1.02.013, SHA-2 v1.01 and Toolbox v1.02.013 libraries
and with specific IC dedicated software (firmware)
Masked chip reference : IDealPass_v2.0.1N_M7892_1_0_0
Crypto library Toolbox v1.02.013
Chip Component Assurance
Level
EAL6+, augmented with ALC_FLR.1
TOE Identifier IDEALPASSV201SAC/EAC_NTePASSPORT/1.0.0
Administration guidance : 2016_2000017817 - Preparative Procedures
User guidance : 2016_2000017816 - Operational User Guidance
CC compliance :
Version : 3.1
Assurance level : EAL 4 augmented with ALC_DVS.2 ADV_FSP.5, ADV_INT.2,
ADV_TDS.4, ALC_CMS.5, ALC_DVS.2, ALC_TAT.2, ATE_DPT.3
Chip and cryptolibrary certificate
reference
: M7892 : BSI-DSZ-CC-0782-V2-2015
Protection Profile BSI-CC-PP-0055, Version 1.10 [R5]
1.2 General overview of the Target of Evaluation (TOE)
1.2.1 TOE type
The Target of Evaluation (TOE) is a contact/contactless chip programmed according
to the Logical Data Structure (LDS) [R9] (i.e. the MRTD’s chip) and providing the
advanced security methods Basic Access Control (BAC) as defined in the Technical
reports of “ICAO Doc 9303” [R9]. The MRTD’s chip allows the authenticity of the travel
document and the identity of its holder to be checked during a border control, with
the support of an inspection system.
The MRTD’s chips are intended to be inserted into the cover page of traditional
passport booklets. They can be integrated into modules, inlay or datapage. The final
product can be a passport, a plastic card etc…
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 9/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
The Chip Authentication prevents data traces described in [R9] informative appendix
7, A7.3.3. The Chip Authentication is provided by the following steps:
 the inspection system communicates by means of secure messaging established by Basic
Access Control,
 the inspection system reads and verifies by means of the Passive Authentication the
authenticity of the MRTD’s Chip Authentication Public Key using the Document Security Object,
 the inspection system generates an ephemeral key pair, (iv) the TOE and the inspection system
agree on two session keys for secure messaging in ENC_MAC mode according to the Diffie-
Hellman Primitive and
 the inspection system verifies by means of received message authentication codes whether the
MRTD’s chip was able or not to run this protocol properly (i.e. the TOE proves to be in
possession of the Chip Authentication Private Key corresponding to the Chip Authentication
Public Key used for derivation of the session keys).
The Chip Authentication requires collaboration of the TOE and the TOE environment.
1.2.2 Usage and major security features of the TOE
A State or Organization issues MRTDs to be used by the holder for international travel.
The traveler presents a MRTD to the inspection system to prove his or her identity.
The MRTD in context of this protection profile 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 MRTD’s chip according to LDS for contactless
machine reading. The authentication of the traveler is based on (i) the possession of
a valid MRTD personalized for a holder with the claimed identity as given on the
biographical data page and (ii) optional biometrics using the reference data stored in
the TOE description MRTD.
The issuing State or Organization ensures the authenticity of the data of genuine
MRTD’s. The receiving State trusts a genuine MRTD of an issuing State or
Organization.
For this Security Target the MRTD is viewed as unit of
(a) the physical MRTD as travel document in form of paper, plastic and chip. It
presents visual readable data including (but not limited to) personal data of the MRTD
holder
(1) the biographical data on the biographical data page of the passport book,
(2) the printed data in the Machine-Readable Zone (MRZ) and
(3) the printed portrait.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 10/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
(b) the logical MRTD as data of the MRTD holder stored according to the Logical
Data Structure [6] as specified by ICAO on the contactless integrated circuit. It
presents contactless readable data including (but not limited to) personal data of the
MRTD holder
(1) the digital Machine Readable Zone Data (digital MRZ data, EF.DG1),
(2) the digitized portraits (EF.DG2),
(3) the optional biometric reference data of finger(s) (EF.DG3) or iris
image(s) (EF.DG4) or both
(4) the other data according to LDS (EF.DG5 to EF.DG16) and
(5) the Document security object.
The issuing State or Organization implements security features of the MRTD to
maintain the authenticity and integrity of the MRTD and their data. The MRTD as the
passport book and the MRTD’s chip is uniquely identified by the Document Number.
The physical MRTD is protected by physical security measures (e.g. watermark on
paper, security printing), logical (e.g. authentication keys of the MRTD’s chip) and
organizational security measures (e.g. control of materials, personalization
procedures) [6]. These security measures include the binding of the MRTD’s chip to
the passport book.
The logical MRTD 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 MRTD’s chip.
The ICAO defines the baseline security methods Passive Authentication and the
optional advanced security methods Basic Access Control to the logical MRTD, Active
Authentication of the MRTD’s chip, Extended Access Control to and the Data Encryption
of additional sensitive biometrics as optional security measure in the ‘ICAO Doc 9303’
[6]. The Passive Authentication Mechanism and the Data Encryption are performed
completely and independently on the TOE by the TOE environment.
This Security Target addresses the protection of the logical MRTD (i) in integrity by
writeonly-once access control and by physical means, and (ii) in confidentiality by the
Basic Access Control Mechanism. This Security Target addresses the Active
Authentication.
The Basic Access Control is a security feature which is mandatory supported by the
TOE. The inspection system (i) reads optically the MRTD, (ii) authenticates itself as
inspection system by means of Document Basic Access Keys. After successful
authentication of the inspection system the MRTD’s chip provides read access to the
logical MRTD by means of private communication(secure messaging) with this
inspection system [R9], normative appendix 5.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 11/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
1.2.3 TOE Boundary
The Target Of Evaluation (TOE) is the contact/contactless integrated circuit chip of
machine readable travel documents (MRTD’s chip) programmed according to the
Logical Data Structure (LDS) [R9] and providing Basic Access Control according to
the ICAO Doc 9303 [R9].
Only the BAC feature is covered by this ST. The EAC feature is covered by another ST.
The TOE boundary encompasses:
 The ICAO application
 The Active Authentication mechanism according to the ICAO document [R9]
 The Operating System
 The Infineon embedded crypto library : Toolbox v1.02.013
 The Infineon chip: Infineon M7892 B11 with optional RSA2048/4096 v1.02.013, EC v1.02.013,
SHA-2 v1.01 and Toolbox v1.02.013 libraries and with specific IC dedicated software (firmware)
The TOE does not allow any additional applets loading during its operational use.
1.2.4 Product architecture
The Product is embedding two applications:
 NSD (Native Security Domain) Application insures card security during application
personalization. This application is not accessible once in Operational Use phase and is not
in the scope of the TOE.
 The ICAO application, which is compliant with [R9]. The ICAO application may be instantiated
several times.
The product does not allow any additional applets loading during its operational use.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 12/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
The architecture of the IDeal Pass V2.0.1 is given in Figure 1.
Figure 1: Architecture of the IDeal Pass V2.0.1
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 13/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
1.2.5 TOE life cycle
The product’s life cycle is organised as follows:
Phase 1 -Step 1
IC Development
Phase 2 – Step 4
IC Packaging (Modules,
inlay, booklets,…)
IC Pre-personalization
(optional)
Phase 2 – Step 3
IC Manufacturing and test
IC Initialisation
IC Pre-personalization
(optional)
Phase 2 – Step 5 (if not
done on previous phase)
IC Pre-personalization
Phase 3 – Step 6
Personalisation
Phase 4 – Step 7
Operatinal Usage
TOE creation
ALC
AGD
ARES
Development
IC
Manufacturer
Travel
document
manufacturer
Personalisation
Agent
Final User
ARES
Delivery
Phase 5
Erase
Morpho
Phase 1 -Step 2
IC Embedded Software
Development
Figure 2: TOE life cycle
The table below presents the TOE role:
Roles Actors
IC Developer Infineon
IC Manufacturer Infineon
TOE Developer Safran Identity & Security (OSNY-France – Development)
Safran Identity & Security (NOIDA-India – Qualification/Testing only)
Or other
agent
TOE Delivery
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 14/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Roles Actors
Travel Document Manufacturer Safran Identity & Security
Or another agent
Personalization Agent Safran Identity & Security
Or another agent
The table below presents the Actors following TOE life cycle steps in accordance with the
standard smart card life cyce and the Protection Profile lifecycle phases, the TOE delivery
point and the coverage:
Step/Phase Actors Sites Covered by
Phase 1-Step 1 Infineon Dresden ALC (IC certification)
Phase 1-Step 2 Safran Identity &
Security
Osny (development) and
Noida (Qualification/Testing)
ALC R&D site
ALC Qualification site
Phase 2-Step 3 Infineon Dresden ALC (IC certification)
TOE Delivery
Phase 2-Step 4 Travel Document
Manufacturer
AGD_PRE
Phase 2-Step 5 Travel Document
Manufacturer
AGD_PRE
Phase 3-Step 6 Personalizer AGD_PRE
Phase 4-Step 7 End User AGD_OPE
The TOE life cycle is described in the following table:
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 15/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Phase
number
Phase name Description / Authority
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.
(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 IC Embedded
Software (operating system), the MRTD application and the guidance
documentation associated with these TOE components.
The Safran Identity & Security ePassport code is securely delivered
directly from the software developer (Safran Identity & Security) to
the IC manufacturer (Infineon).
2 Manufacturing
(Step3) In a first step the TOE integrated circuit is produced
containing the MRTD’s chip Dedicated Software and the parts of the
MRTD’s chip Embedded Software. The IC manufacturer writes the IC
Identification Data onto the chip to control the IC as MRTD material
during the IC manufacturing and the delivery process to the MRTD
manufacturer.
The ePassport application code will be integrated in the FLASH
memory by the IC manufacturer.
(Step 4) 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),
(iii) the Document security object.
The signing of the Document security object by the Document Signer
[R9] finalizes the personalization of the genuine MRTD for the MRTD
holder. The personalized MRTD (together with appropriate guidance
for TOE use if necessary) is handed over to the MRTD holder for
operational use.
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 [R9]. This approach allows but does not enforce the
separation of these roles.
3
Personalization
agent
(Step6) The personalization of the MRTD includes
(i) the survey of the MRTD holder’s biographical data,
(ii) the enrolment of the MRTD holder biometric
reference data (i.e. the digitized portraits and the
optional biometric reference data),
(iii) the printing of the visual readable data onto the
physical MRTD,
(iv) (iv) the writing of the TOE User Data and TSF Data
into the logical MRTD and
(v) configuration of the TSF if necessary.
4 Operational Use
(Step 7) The TOE is used as MRTD’s chip by the traveller 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.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 16/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Phase
number
Phase name Description / Authority
5 Erase
The erase function is included into the TOE. The access to
this function is granted only and only if Mutal Authentication
with Key set n°1 is successful. After the erase all TOE data
(Sensitive and non sensitive) are Erased. Infineon
Bootloader will be re-activated. The erase function is not
accessible after Phase 3 (Operational Usage)
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 17/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
2 Conformance claims
2.1 Conformance with the Common Criteria
This Security Target claims conformance to:
 Part 1 of the Common Criteria, Version 3.1, Release 4 (see [R1])
 Part 2 of the Common Criteria, Version 3.1, Release 4 (see [R2]),
 Part 3 of the Common Criteria, Version 3.1, Release 4 (see [R3]),
as follows
 Part 2 extended,
 Part 3 conformant.
2.2 Conformance with an assurance package
The level of assurance targeted by this Security Target is EAL4, augmented by the
following component defined in CC part 3 [R3]:
 ADV_FSP.5,
 ADV_INT.2,
 ADV_TDS.4,
 ALC_CMS.5,
 ALC_DVS.2,
 ALC_TAT.2,
 ATE_DPT.3
2.3 Conformance with a protection profile
2.3.1 Protection Profile reference
This Security Target claims strict conformance to the Protection Profile MRTD BAC
[R5].
2.3.2 Protection Profile Claims rationale
The TOE type defined in this security target is the same than the one defined in the
PP MRTD BAC [R5]: an contact/contactless chip with embedded software, and the
MRTD application conformant to ICAO [R9].
The security problem definition, the security objectives, and the security requirements
of this ST contain those of the claimed PP MRTD BAC [R5].
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 18/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
The following elements have been added for the optional Active Authentication
mechanism according to [R9]:
 Objectives for the TOE:
 OT.Chip_Auth_Proof
 SFRs:
 FCS_COP.1/AA_SIGN
 FIA_API.1/AAP
There are additional SAR augmentations performed in this security target comparing
to the PP [R5]. These augmentations are described in the chapter 2.2 .All PP
requirements have been shown to be satisfied in the extended set of requirements
whose completeness, consistency and soundness has been argued in the rationale
sections of the present document.
2.4 Conformance with the CC supporting documents
This security target address a smartcard TOE and therefore, the associated evaluation
shall be performed in compliance with all CC mandatory supporting documents related
to smartcard evaluations:
2.4.1 Application of Attack Potential to Smartcards
This document [R11] shall be used instead of the CEM [R4] when calculating the attack
potential of the successful attack performed during AVA_VAN analysis. This document
impacts only the vulnerability analysis performed by the ITSEF, and is not detailed
here.
2.4.2 Composite product evaluation for Smartcards and similar
devices
This document [R12] shall be used in addition to the CC part 3 [R3] and to the CEM
[R4]. This document specifies the additional information to be provided by a
developer, and the additional checks to be performed by the ITSEF when performing
a “composite evaluation”. This is the case for the current TOE as the underlying IC
M7892 B11 is already evaluated and certified under the reference BSI-DSZ-CC-0782-
V2-2015. Therefore, the following additional assurance requirements apply for this
TOE:
 ASE_COMP.1 for the security target ;
 ALC_COMP.1 for the life cycle support ;
 ADV_COMP.1 for the development activity ;
 ATE_COMP.1 for the tests activity ;
 AVA_COMP.1 for the vulnerability assessment.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 19/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
The "Statement of compatibility” required by ASE_COMP additional requirements can
be found in this security target, chapter 8.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 20/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
3 Security problem definition
3.1 Assets
The logical MRTD data consists of the EF.COM, EF.DG1 to EF.DG16 (with different security
needs) and the Document Security Object EF.SOD according to LDS [R9]. These data are user
data of the TOE. The EF.COM lists the existing elementary files (EF) with the user data. The
EF.DG1 to EF.DG13 and EF.DG 16 contain personal data of the MRTD holder. The Chip
Authentication Public Key (EF.DG 14) is used by the inspection system for the Chip
Authentication. The EF.SOD is used by the inspection system for Passive Authentication of the
logical MRTD.
Due to interoperability reasons as the "ICAO Doc 9303" [R9] the TOE described in this security
target specifies only the BAC mechanisms with resistance against enhanced basic attack
potential granting access to
Logical MRTD standard User Data (i.e. Personal Data) of the MRTD holder (EF.DG1, EF.DG2,
EF.DG5 to EF.DG13, EF.DG16),
Chip Authentication Public Key in EF.DG14,
Active Authentication Public Key in EF.DG15,
Document Security Object (SOD) in EF.SOD,
Common data in EF.COM. The TOE prevents read access to sensitive User Data
Sensitive biometric reference data (EF.DG3, EF.DG4).
Authenticity of the MRTD's chip
The authenticity of the MRTD's chip personalized by the issuing State or
Organization for the MRTD holder is used by the traveler to prove his possession
of a genuine MRTD.
3.2 Users / Subjects
The following individuals and IT systems have access to the TOE:
Manufacturer
"Manufacturer" is the generic term for the IC Manufacturer producing the
integrated circuit as well as for the MRTD Manufacturer completing the IC to the
MRTD's chip. The Manufacturer is the default user of the TOE during the Phase
2 Manufacturing (step 3 to step 5). In this Security Target, the TOE does not
distinguish between the users "IC Manufacturer" and the "MRTD Manufacturer"
using this role Manufacturer.
Personalization Agent
The agent is acting on behalf of the issuing State or Organization to personalize
the MRTD for the holder by:
establishing the identity of the holder for the biographic data in the MRTD,
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 21/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
enrolling the biometric reference data of the MRTD holder i.e. the portrait, the encoded
finger image(s) and/or the encoded iris image(s),
writing these data on the physical and logical MRTD for the holder as defined for global,
international and national interoperability,
writing the initial TSF data and
signing the Document Security Object defined in [R9].
Terminal
A terminal is any technical system communicating with the TOE through its
contactless interface.
Inspection system (IS)
A technical system used by the border control officer of the receiving State:
examining an MRTD presented by the traveler and verifying its authenticity,
verifying the traveler as the MRTD holder.
The Basic Inspection System (BIS):
contains a terminal for the contactless communication with the MRTD's chip,
implements the terminals part of the Basic Access Control Mechanism,
gets the authorization to read the logical MRTD under the Basic Access Control by
optically reading the MRTD or other parts of the passport book providing this
information.
The General Inspection System (GIS) is a Basic Inspection System which
implements additionally the Chip Authentication Mechanism.
The Extended Inspection System (EIS) in addition to the General Inspection
System:
implements the Terminal Authentication Protocol,
is authorized by the issuing State or Organization through the Document Verifier of the
receiving State to read the sensitive biometric reference data. The security attributes
of the EIS are defined by the Inspection System Certificates
Application note:
This security target does not distinguish between the BIS, GIS and EIS because
the Chip Authentication Mechanism and the Extended Access Control is outside
the scope.
MRTD Holder
The rightful holder of the MRTD for whom the issuing State or Organization
personalized the MRTD.
Traveler
Person presenting the MRTD to the inspection system and claiming the identity
of the MRTD holder.
Attacker
A threat agent trying:
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 22/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
to identify and to trace the movement of the MRTD's chip remotely (i.e. without
knowing or optically reading the printed MRZ data),
to read or to manipulate the logical MRTD without authorization, or
to forge a genuine MRTD.
Application note:
An impostor is attacking the inspection system as TOE IT environment
independent on using a genuine, counterfeit or forged MRTD. Therefore the
impostor may use results of successful attacks against the TOE but the attack
itself is not relevant for the TOE.
3.3 Threats
T.Chip_ID
An attacker trying to trace the movement of the MRTD by identifying remotely
the MRTD's chip by establishing or listening to communications through the
contactless communication interface. The attacker cannot read and does not
know the MRZ data printed on the MRTD data page in advance. The targetted
asset is the Anonymity of user.
T.Skimming
An attacker imitates the inspection system to read the logical MRTD or parts of
it via the contactless communication channel of the TOE. The attacker cannot
read and does not know the MRZ data printed on the MRTD data page in
advance. The targetted asset is the confidentiality of logical MRTD data.
T. Eavesdropping
An attacker is listening to the communication between the MRTD's chip and an
inspection system to gain the logical MRTD or parts of it. The inspection system
uses the MRZ data printed on the MRTD data page but the attacker does not
know these data in advance.
Note in case of T.Skimming the attacker is establishing a communication with
the MRTD's chip not knowing the MRZ data printed on the MRTD data page and
without a help of the inspection system which knows these data. In case of
T.Eavesdropping the attacker uses the communication of the inspection system.
The targetted asset is confidentiality of logical MRTD data.
T.Forgery
An attacker alters fraudulently the complete stored logical MRTD or any part of
it including its security related data in order to deceive on an inspection system
by means of the changed MRTD holder's identity or biometric reference data.
This threat comprises several attack scenarios of MRTD forgery. The attacker
may alter the biographical data on the biographical data page of the passport
book, in the printed MRZ and in the digital MRZ to claim another identity of the
traveler. The attacker may alter the printed portrait and the digitized portrait to
overcome the visual inspection of the inspection officer and the automated
biometric authentication mechanism by face recognition. The attacker may alter
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 23/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
the biometric reference data to defeat automated biometric authentication
mechanism of the inspection system. The attacker may combine data groups of
different logical MRTDs to create a new forged MRTD, e.g. the attacker writes
the digitized portrait and optional biometric reference finger data read from the
logical MRTD of a traveler into another MRTD's chip leaving their digital MRZ
unchanged to claim the identity of the holder this MRTD. The attacker may also
copy the complete unchanged logical MRTD to another contactless chip.
The targetted asset is the authenticity of logical MRTD data.
T.Abuse-Func
An attacker may use functions of the TOE which shall not be used in "TOE
operational Use" phase in order
to manipulate User Data,
to manipulate (explore, bypass, deactivate or change) security features or functions of
the TOE or
to disclose or to manipulate TSF Data.
This threat addresses the misuse of the functions for the initialization and the
personalization in the operational state after delivery to MRTD holder.
The targetted asset is confidentiality and authenticity of logical MRTD and TSF
data, correctness of TSF.
T.Information_Leakage
An attacker may exploit information which is leaked from the TOE during its
usage in order to disclose confidential TSF data. The information leakage may
be inherent in the normal operation or caused by the attacker.
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 the Differential Electromagnetic Analysis (DEMA) and the Differential Power
Analysis (DPA). Moreover the attacker may try actively to enforce information
leakage by fault injection (e.g. Differential Fault Analysis).
The targetted asset is confidentiality of logical MRTD and TSF data.
T.Phys-Tamper
An attacker may perform physical probing of the MRTD's chip in order
to disclose TSF Data, or
to disclose/reconstruct the MRTD's chip Embedded Software.
An attacker may physically modify the MRTD's chip in order to
modify security features or functions of the MRTD's chip,
modify security functions of the MRTD's chip Embedded Software,
modify User Data or,
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 24/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
to modify TSF data.
The physical tampering may be focused directly on the disclosure or
manipulation of TOE User Data (e.g. the biometric reference data for the
inspection system) or TSF Data (e.g. authentication key of the MRTD's chip) 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 direct interaction with the MRTD's chip internals.
Techniques commonly employed in IC failure analysis and IC reverse
engineering efforts may be used. Before that, the hardware security
mechanisms and layout characteristics need to be identified. Determination of
software design including treatment of User Data and 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.
The targetted asset is confidentiality and authenticity of logical MRTD and TSF
data, correctness of TSF
T.Malfunction
An attacker may cause a malfunction of TSF or of the MRTD's chip Embedded
Software by applying environmental stress in order to
deactivate or modify security features or functions of the TOE or
circumvent, deactivate or modify security functions of the MRTD's chip Embedded
Software.
This may be achieved e.g. by operating the MRTD's chip outside the normal
operating conditions, exploiting errors in the MRTD's chip Embedded Software
or misusing administration function. To exploit these vulnerabilities an attacker
needs information about the functional operation.
The targetted asset is confidentiality and authenticity of logical MRTD and TSF
data, correctness of TSF.
3.4 Organisational Security Policies
The TOE shall comply with the following Organizational Security Policies (OSP) as security
rules, procedures, practices, or guidelines imposed by an organization upon its operations.
P.Manufact
The Initialization Data are written by the IC Manufacturer to identify the IC
uniquely. The MRTD Manufacturer writes the Pre-personalization Data which
contains at least the Personalization Agent Key.
P.Personalization
The issuing State or Organization guarantees the correctness of the biographical
data, the printed portrait and the digitized portrait, the biometric reference data
and other data of the logical MRTD with respect to the MRTD holder. The
personalization of the MRTD for the holder is performed by an agent authorized
by the issuing State or Organization only.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 25/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
P.Personal_Data
The biographical data and their summary printed in the MRZ and stored on the
MRTD's chip (EF.DG1), the printed portrait and the digitized portrait (EF.DG2),
the biometric reference data of finger(s) (EF.DG3), the biometric reference data
of iris image(s) (EF.DG4) and data according to LDS (EF.DG5 to EF.DG13,
EF.DG16) stored on the MRTD's chip are personal data of the MRTD holder.
These data groups are intended to be used only with agreement of the MRTD
holder by inspection systems to which the MRTD is presented. The MRTD's chip
shall provide the possibility for the Basic Access Control to allow read access to
these data only for terminals successfully authenticated based on knowledge of
the Document Basic Access Keys as defined in [R9].
Application note:
The organizational security policy P.Personal_Data is drawn from the ICAO
"ICAO Doc 9303" [R9]. Note that the Document Basic Access Key is defined by
the TOE environment and loaded to the TOE by the Personalization Agent
3.5 Assumptions
The assumptions describe the security aspects of the environment in which the TOE will be
used or is intended to be used.
A.MRTD_Manufact
It is assumed that appropriate functionality testing of the MRTD is used. It is
assumed that security procedures are used during all manufacturing and test
operations to maintain confidentiality and integrity of the MRTD and of its
manufacturing and test data (to prevent any possible copy, modification,
retention, theft or unauthorized use).
A.MRTD_Delivery
Procedures shall guarantee the control of the TOE delivery and storage process
and conformance to its objectives:
Procedures shall ensure protection of TOE material/information under delivery and
storage.
Procedures shall ensure that corrective actions are taken in case of improper operation
in the delivery process and storage.
Procedures shall ensure that people dealing with the procedure for delivery have got
the required skill.
A.Pers_Agent
The Personalization Agent ensures the correctness of
the logical MRTD with respect to the MRTD holder,
the Document Basic Access Keys,
the Chip Authentication Public Key (EF.DG14) if stored on the MRTD's chip,
the Document Signer Public Key Certificate (if stored on the MRTD's chip).
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 26/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
The Personalization Agent signs the Document Security Object. The
Personalization Agent bears the Personalization Agent Authentication to
authenticate himself to the TOE by symmetric cryptographic mechanisms.
A.Insp_Sys
The Inspection System is used by the border control officer of the receiving
State
Examining an MRTD presented by the traveler and verifying its authenticity and
verifying the traveler as MRTD holder.
The Basic Inspection System for global interoperability
includes the Country Signing CA Public Key and the Document Signer Public Key of
each issuing State or Organization, and
implements the terminal part of the Basic Access Control [R9].
The Basic Inspection System reads the logical MRTD under Basic Access Control
and performs the Passive Authentication to verify the logical MRTD.
Application note:
According to [R9] the support of the Passive Authentication mechanism is
mandatory whereas the Basic Access Control is optional. This ST does not
address Primary Inspection Systems therefore the BAC is mandatory within this
ST.
A.BAC-Keys
The Document Basic Access Control Keys being generated and imported by the
issuing State or Organization have to provide sufficient cryptographic strength.
As a consequence of the "ICAO Doc 9303" [R9], the Document Basic Access
Control Keys are derived from a defined subset of the individual printed MRZ
data. It has to be ensured that these data provide sufficient entropy to withstand
any attack based on the decision that the inspection system has to derive
Document Access Keys from the printed MRZ data with enhanced basic attack
potential.
Application note:
When assessing the MRZ data resp. the BAC keys entropy potential
dependencies between these data (especially single items of the MRZ) have to
be considered and taken into account. E.g. there might be a direct dependency
between the Document Number when chosen consecutively and the issuing
date.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 27/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
4 Security Objectives
4.1 Security Objectives for the TOE
This section describes the security objectives for the TOE addressing the aspects of identified
threats to be countered by the TOE and organizational security policies to be met by the TOE.
OT.AC_Pers
The TOE must ensure that the logical MRTD data in EF.DG1 to EF.DG16, the
Document security object according to LDS [R9] and the TSF data can be written
by authorized Personalization Agents only. The logical MRTD data in EF.DG1 to
EF.DG16 and the TSF data may be written only during and cannot be changed
after its personalization. The Document security object can be updated by
authorized Personalization Agents if data in the data groups EF.DG 3 to EF.DG16
are added.
Application note:
The OT.AC_Pers implies that
the data of the LDS groups written during personalization for MRTD holder (at least
EF.DG1 and EF.DG2) can not be changed by write access after personalization,
the Personalization Agents may:
add (fill) data into the LDS data groups not written yet, and
update and sign the Document Security Object accordingly. The support for adding
data in the "Operational Use" phase is optional.
OT.Data_Int
The TOE must ensure the integrity of the logical MRTD stored on the MRTD's
chip against physical manipulation and unauthorized writing. The TOE must
ensure that the inspection system is able to detect any modification of the
transmitted logical MRTD data.
OT. Data_Conf
The TOE must ensure the confidentiality of the logical MRTD data groups EF.DG1
to EF.DG16. Read access to EF.DG1 to EF.DG16 is granted to terminals
successfully authenticated as Personalization Agent. Read access to EF.DG1,
EF.DG2 and EF.DG5 to EF.DG16 is granted to terminals successfully
authenticated as Basic Inspection System. The Basic Inspection System shall
authenticate itself by means of the Basic Access Control based on knowledge of
the Document Basic Access Key. The TOE must ensure the confidentiality of the
logical MRTD data during their transmission to the Basic Inspection System.
Application note:
The traveler grants the authorization for reading the personal data in EF.DG1,
EF.DG2 and EF.DG5 to EF.DG16 to the inspection system by presenting the
MRTD. The MRTD's chip shall provide read access to these data for terminals
successfully authenticated by means of the Basic Access Control based on
knowledge of the Document Basic Access Keys. The security objective
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 28/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
OT.Data_Conf requires the TOE to ensure the strength of the security function
Basic Access Control Authentication. The Document Basic Access Keys are
derived from the MRZ data defined by the TOE environment and are loaded into
the TOE by the Personalization Agent. Therefore the sufficient quality of these
keys has to result from the MRZ data's entropy. Any attack based on decision
of the "ICAO Doc 9303" [R9] that the inspection system derives Document Basic
Access is ensured by OE.BAC-Keys. Note that the authorization for reading the
biometric data in EF.DG3 and EF.DG4 is only granted after successful Enhanced
Access Control not covered by this security target. Thus the read access must
be prevented even in case of a successful BAC Authentication.
OT.Identification
The TOE must provide means to store IC Identification and Pre-Personalization
Data in its non-volatile memory. The IC Identification Data must provide a
unique identification of the IC during Phase 2 "Manufacturing" and Phase 3
"Personalization of the MRTD". The storage of the Pre-Personalization data
includes writing of the Personalization Agent Authentication key(s).). In Phase
4 "Operational Use" the TOE shall identify itself only to a successful
authenticated Basic Inspection System or Personalization Agent.
Application note:
The TOE security objective OT.Identification addresses security features of the
TOE to support the life cycle security in the manufacturing and personalization
phases. The IC Identification Data are used for TOE identification in Phase 2
"Manufacturing" and for traceability and/or to secure shipment of the TOE from
Phase 2 "Manufacturing" into the Phase 3 "Personalization of the MRTD". The
OT.Identification addresses security features of the TOE to be used by the TOE
manufacturing. In the Phase 4 "Operational Use" the TOE is identified by the
Document Number as part of the printed and digital MRZ. The OT.Identification
forbids the output of any other IC (e.g. integrated circuit card serial number
ICCSN) or MRTD identifier through the contactless interface before successful
authentication as Basic Inspection System or as Personalization Agent.
The following TOE security objectives address the protection provided by the
MRTD's chip independent of the TOE environment.
OT.Prot_Abuse-Func
After delivery of the TOE to the MRTD Holder, the TOE must prevent the abuse
of test and support functions that may be maliciously used to
disclose critical User Data,
manipulate critical User Data of the IC Embedded Software,
manipulate Soft-coded IC Embedded Software or
bypass, deactivate, change or explore security features or functions of the TOE.
Details of the relevant attack scenarios depend, for instance, on the capabilities
of the Test Features provided by the IC Dedicated Test Software which are not
specified here.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 29/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
OT.Prot_Inf_Leak
The TOE must provide protection against disclosure of confidential TSF data
stored and/or processed in the MRTD's chip
by measurement and analysis of the shape and amplitude of signals or the time
between events found by measuring signals on the electromagnetic field, power
consumption, clock, or I/O lines and
by forcing a malfunction of the TOE and/or
by a physical manipulation of the TOE.
Application note:
This objective pertains to measurements with subsequent complex signal
processing due to normal operation of the TOE or operations enforced by an
attacker. Details correspond to an analysis of attack scenarios which is not given
here.
OT.Prot_Phys-Tamper
The TOE must provide protection of the confidentiality and integrity of the User
Data, the TSF Data, and the MRTD's chip Embedded Software. This includes
protection against attacks with enhanced basic attack potential by means of
measuring through galvanic contacts which is direct physical probing on the chips
surface except on pads being bonded (using standard tools for measuring voltage
and current) or
measuring not using galvanic contacts but other types of physical interaction between
charges (using tools used in solid-state physics research and IC failure analysis)
manipulation of the hardware and its security features, as well as
controlled manipulation of memory contents (User Data, TSF Data)
with a prior
reverse-engineering to understand the design and its properties and functions.
OT.Prot_Malfunction
The TOE must ensure its correct operation. The TOE must prevent its operation
outside the normal operating conditions where reliability and secure operation
has not been proven or tested. This is to prevent errors. The environmental
conditions may include external energy (esp. electromagnetic) fields, voltage
(on any contacts), clock frequency, or temperature.
Application note:
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 objective OT.Prot_Phys-Tamper) provided that detailed knowledge about
the TOE's internals.
Additional Security Objective for AA
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 30/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
OT.Chip_Auth_Proof
The TOE must support the Basic and General Inspection Systems, to verify the
identity and authenticity of the MRTD's chip as issued by the identified issuing
State or Organization by means of the Active Authentication as defined in [R9].
The authenticity prove provided by MRTD's chip shall be protected against
attacks with high attack potential.
4.2 Security objectives for the Operational Environment
OE.MRTD_Manufact
Appropriate functionality testing of the TOE shall be used in step 4 to 6.
During all manufacturing and test operations, security procedures shall be used
through phases 4, 5 and 6 to maintain confidentiality and integrity of the TOE
and its manufacturing and test data.
OE.MRTD_ Delivery
Procedures shall ensure protection of TOE material/information under delivery
including the following objectives:
non-disclosure of any security relevant information,
identification of the element under delivery,
meet confidentiality rules (confidentiality level, transmittal form, reception
acknowledgment),
physical protection to prevent external damage,
secure storage and handling procedures (including rejected TOE's),
traceability of TOE during delivery including the following parameters:
origin and shipment details,
reception, reception acknowledgement,
location material/information.
Procedures shall ensure that corrective actions are taken in case of improper
operation in the delivery process (including if applicable any non-conformance
to the confidentiality convention) and highlight all non-conformance to this
process.
Procedures shall ensure that people (shipping department, carrier, reception
department) dealing with the procedure for delivery have got the required skill,
training and knowledge to meet the procedure requirements and be able to act
fully in accordance with the above expectations.
OE.Personalization
The issuing State or Organization
establish the correct identity of the holder and create biographical data for the MRTD,
enroll the biometric reference data of the MRTD holder i.e. the portrait, the encoded
finger image(s) and/or the encoded iris image(s) and
personalize the MRTD for the holder together with the defined physical and logical
security measures to protect the confidentiality and integrity of these data.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 31/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
OE.Pass_Auth_Sign
The issuing State or Organization must
generate a cryptographic secure Country Signing CA Key Pair,
ensure the secrecy of the Country Signing CA Private Key and sign Document Signer
Certificates in a secure operational environment, and
distribute the Certificate of the Country Signing CA Public Key to receiving States and
Organizations maintaining its authenticity and integrity.
The issuing State or Organization must
generate a cryptographic secure Document Signer Key Pair and ensure the secrecy of
the Document Signer Private Keys,
sign Document Security Objects of genuine MRTD in a secure operational environment
only and
distribute the Certificate of the Document Signer Public Key to receiving States and
Organizations.
The digital signature in the Document Security Object EF.SOD relates to all data
in the data in EF.DG1 to EF.DG16 if stored in the LDS according to [R9].
OE.BAC-Keys
The Document Basic Access Control Keys being generated and imported by the
issuing State or Organization have to provide sufficient cryptographic strength.
As a consequence of the "ICAO Doc 9303" [R9] the Document Basic Access
Control Keys are derived from a defined subset of the individual printed MRZ
data. It has to be ensured that these data provide sufficient entropy to withstand
any attack based on the decision that the inspection system has to derive
Document Basic Access Keys from the printed MRZ data with enhanced basic
attack potential.
OE.Exam_MRTD
The inspection system of the receiving State or Organization must examine the
MRTD presented by the traveler to verify its authenticity by means of the
physical security measures and to detect any manipulation of the physical
MRTD. The Basic Inspection System for global interoperability
includes the Country Signing Public Key and the Document Signer Public Key of each
issuing State or Organization, and
implements the terminal part of the Basic Access Control [R9].
OE.Passive_Auth_Verif
The border control officer of the receiving State uses the inspection system to
verify the traveler as MRTD holder. The inspection systems must have
successfully verified the signature of Document Security Objects and the
integrity data elements of the logical MRTD before they are used. The receiving
States and Organizations must manage the Country Signing CA Public Key and
the Document Signer Public Key maintaining their authenticity and availability
in all inspection systems.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 32/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
OE.Prot_Logical_MRTD
The inspection system of the receiving State or Organization ensures the
confidentiality and integrity of the data read from the logical MRTD. The
receiving State examining the logical MRTD being under Basic Access Control
will use inspection systems which implement the terminal part of the Basic
Access Control and use the secure messaging with fresh generated keys for the
protection of the transmitted data (i.e. Basic Inspection Systems).
4.3 Security Objectives Rationale
4.3.1 Threats
T.Chip_ID The threat T.Chip_ID "Identification of MRTD's chip" addresses the
trace of the MRTD movement by identifying remotely the MRTD's chip through
the contactless communication interface. This threat is countered as described
by the security objective OT.Identification by Basic Access Control using
sufficiently strong derived keys as required by the security objective for the
environment OE.BAC-Keys.
T.Skimming The threat T.Skimming "Skimming digital MRZ data or the digital
portrait" is countered by the security objective OT. Data_Conf "Confidentiality
of personal data" through Basic Access Control using sufficiently strong derived
keys as required by the security objective for the environment OE.BAC-Keys.
T. Eavesdropping This threat T. Eavesdropping is countered by the security
objective OT. Data_Conf "Confidentiality of personal data" through Basic
Access Control using sufficiently strong derived keys.
T.Forgery The threat T.Forgery "Forgery of data on MRTD's chip" addresses the
fraudulent alteration of the complete stored logical MRTD or any part of it. The
security objective OT.AC_Pers "Access Control for Personalization of logical
MRTD" requires the TOE to limit the write access for the logical MRTD to the
trustworthy Personalization Agent (cf. OE.Personalization). The TOE will protect
the integrity of the stored logical MRTD according the security objective
OT.Data_Int "Integrity of personal data" and OT.Prot_Phys-Tamper
"Protection against Physical Tampering". The TOE will protect the identity and
authenticity of the MRTD’s chip as issued by the identified issuing state or
organisation by means of the chip according the security objective
OT.chip_auth_Proof. The examination of the presented MRTD passport book
according to OE.Exam_MRTD "Examination of the MRTD passport book" shall
ensure that passport book does not contain a sensitive contactless chip which
may present the complete unchanged logical MRTD. The TOE environment will
detect partly forged logical MRTD data by means of digital signature which will
be created according to OE.Pass_Auth_Sign "Authentication of logical MRTD
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 33/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
by Signature" and verified by the inspection system according to
OE.Passive_Auth_Verif "Verification by Passive Authentication".
T.Abuse-Func The threat T.Abuse Func "Abuse of Functionality" addresses
attacks using the MRTD's chip as production material for the MRTD and misuse
of the functions for personalization in the operational state after delivery to
MRTD holder to disclose or to manipulate the logical MRTD. This threat is
countered by OT.Prot_Abuse-Func "Protection against Abuse of
Functionality". Additionally this objective is supported by the security objective
for the TOE environment: OE.Personalization "Personalization of logical
MRTD" ensuring that the TOE security functions for the initialization and the
personalization are disabled and the security functions for the operational state
after delivery to MRTD holder are enabled according to the intended use of the
TOE.
T.Information_Leakage The threats T.Information_Leakage "Information
Leakage from MRTD's chip" is typical for integrated circuits like smart cards
under direct attack with high attack potential.this threat is countered by the
directly related security objectif OT.Prot_Inf_Leak "Protection against
Information Leakage".
T.Phys-Tamper The threat T.Phys-Tamper "Physical Tampering" is typical for
integrated circuits like smart cards under direct attack with high attack
potential. The protection of the TOE against this threat is addressed by the
directly related security objectif OT.Prot_Phys-Tamper "Protection against
Physical Tampering".
T.Malfunction The threat T.Malfunction "Malfunction due to Environmental
Stress" is typical for integrated circuits like smart cards under direct attack with
high attack potential. The protection of the TOE against this threat is addressed
by the directly related security objectif OT.Prot_Malfunction "Protection
against Malfunctions".
4.3.2 Organisational Security Policies
P.Manufact The OSP P.Manufact "Manufacturing of the MRTD's chip" requires a
unique identification of the IC by means of the Initialization Data and the writing
of the Prepersonalization Data as being fulfilled by OT.Identification.
P.Personalization The OSP P.Personalization "Personalization of the MRTD by
issuing State or Organization only" addresses the:
the enrolment of the logical MRTD by the Personalization Agent as described in the
security objective for the TOE environment OE.Personalization "Personalization
of logical MRTD", and
the access control for the user data and TSF data as described by the security objective
OT.AC_Pers "Access Control for Personalization of logical MRTD".
Note the manufacturer equips the TOE with the Personalization Agent
Authentication key(s) according to OT.Identification "Identification and
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 34/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Authentication of the TOE". The security objective OT.AC_Pers limits the
management of TSF data and the management of TSF to the Personalization
Agent.
P.Personal_Data The OSP P.Personal_Data "Personal data protection policy"
requires the TOE:
to support the protection of the confidentiality of the logical MRTD by means of the
Basic Access Control and
enforce the access control for reading as decided by the issuing State or Organization.
This policy is implemented by the security objectives OT.Data_Int "Integrity of
personal data" describing the unconditional protection of the integrity of the stored
data and during transmission. The security objective OT. Data_Conf
"Confidentiality of personal data" describes the protection of the confidentiality.
4.3.3 Assumptions
A.MRTD_Manufact The assumption A.MRTD_Manufact "MRTD manufacturing
on step 4 to 6" is covered by the security objective for the TOE environment
OE.MRTD_Manufact "Protection of the MRTD Manufacturing" that requires to
use security procedures during all manufacturing steps.
A.MRTD_Delivery The assumption A.MRTD_ Delivery "MRTD delivery during
step 4 to 6" is covered by the security objective for the TOE environment
OE.MRTD_ Delivery "Protection of the MRTD delivery" that requires to use
security procedures during delivery steps of the MRTD.
A.Pers_Agent The assumption A.Pers_Agent "Personalization of the MRTD's
chip" is covered by the security objective for the TOE environment
OE.Personalization "Personalization of logical MRTD" including the enrolment,
the protection with digital signature and the storage of the MRTD holder
personal data.
A.Insp_Sys The examination of the MRTD passport book addressed by the
assumption A.Insp_Sys "Inspection Systems for global interoperability" is
covered by the security objectives for the TOE environment OE.Exam_MRTD
"Examination of the MRTD passport book". The security objectives for the TOE
environment OE.Prot_Logical_MRTD "Protection of data from the logical
MRTD" will require the Basic Inspection System to implement the Basic Access
Control and to protect the logical MRTD data during the transmission and the
internal handling.
A.BAC-Keys The assumption A.BAC-Keys "Cryptographic quality of Basic Access
Control Keys" is directly covered by the security objective for the TOE
environment OE.BAC-Keys "Cryptographic quality of Basic Access Control
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 35/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Keys" ensuring the sufficient key quality to be provided by the issuing State or
Organization.
4.3.4 SPD and Security Objectives
Threats Security Objectives Rationale
T.Chip_ID OT.Identification, OE.BAC-Keys Section 4.3.1
T.Skimming OE.BAC-Keys, OT. Data_Conf Section 4.3.1
T. Eavesdropping OT. Data_Conf Section 4.3.1
T.Forgery
OT.AC_Pers, OT.Data_Int, OT.Prot_Phys-
Tamper, OE.Pass_Auth_Sign,
OE.Exam_MRTD,
OE.Passive_Auth_Verif,
OT.Chip_Auth_Proof
Section 4.3.1
T.Abuse-Func OT.Prot_Abuse-Func, OE.Personalization Section 4.3.1
T.Information_Leakage OT.Prot_Inf_Leak Section 4.3.1
T.Phys-Tamper OT.Prot_Phys-Tamper Section 4.3.1
T.Malfunction OT.Prot_Malfunction Section 4.3.1
Table 1 - Threats and Security Objectives - Coverage
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 36/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Security Objectives Threats Rationale
OT.AC_Pers T.Forgery
OT.Data_Int T.Forgery
OT. Data_Conf T.Skimming, T. Eavesdropping
OT.Identification T.Chip_ID
OT.Prot_Abuse-Func T.Abuse-Func
OT.Prot_Inf_Leak T.Information_Leakage
OT.Prot_Phys-Tamper T.Forgery, T.Phys-Tamper
OT.Prot_Malfunction T.Malfunction
OT.Chip_Auth_Proof T.Forgery
OE.MRTD_Manufact
OE.MRTD_ Delivery
OE.Personalization T.Abuse-Func
OE.Pass_Auth_Sign T.Forgery
OE.BAC-Keys T.Chip_ID, T.Skimming
OE.Exam_MRTD T.Forgery
OE.Passive_Auth_Verif T.Forgery
OE.Prot_Logical_MRTD
Table 2 - Security Objectives and Threats - Coverage
Organisational Security
Policies
Security Objectives Rationale
P.Manufact OT.Identification Section 4.3.2
P.Personalization OT.AC_Pers, OT.Identification,
OE.Personalization
Section 4.3.2
P.Personal_Data OT.Data_Int, OT. Data_Conf Section 4.3.2
Table 3 - OSPs and Security Objectives - Coverage
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 37/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Security Objectives Organisational Security Policies Rationale
OT.AC_Pers P.Personalization
OT.Data_Int P.Personal_Data
OT. Data_Conf P.Personal_Data
OT.Identification P.Manufact, P.Personalization
OT.Prot_Abuse-Func
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfunction
OT.Chip_Auth_Proof
OE.MRTD_Manufact
OE.MRTD_ Delivery
OE.Personalization P.Personalization
OE.Pass_Auth_Sign
OE.BAC-Keys
OE.Exam_MRTD
OE.Passive_Auth_Verif
OE.Prot_Logical_MRTD
Table 4 - Security Objectives and OSPs - Coverage
Assumptions Security objectives for the Operational
Environment
Rationale
A.MRTD_Manufact OE.MRTD_Manufact Section 4.3.3
A.MRTD_Delivery OE.MRTD_ Delivery Section 4.3.3
A.Pers_Agent OE.Personalization Section 4.3.3
A.Insp_Sys OE.Exam_MRTD, OE.Prot_Logical_MRTD Section 4.3.3
A.BAC-Keys OE.BAC-Keys Section 4.3.3
Table 5 - Assumptions and Security Objectives for the Operational Environment -
Coverage
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 38/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Security objectives for the Operational
Environment
Assumptions Rationale
OE.MRTD_Manufact A.MRTD_Manufact
OE.MRTD_ Delivery A.MRTD_Delivery
OE.Personalization A.Pers_Agent
OE.Pass_Auth_Sign
OE.BAC-Keys A.BAC-Keys
OE.Exam_MRTD A.Insp_Sys
OE.Passive_Auth_Verif
OE.Prot_Logical_MRTD A.Insp_Sys
Table 6 - Security Objectives for the Operational Environment and Assumptions -
Coverage
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 39/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
5 Extended requirements
5.1 Definition of the Family FAU_SAS
To define the security functional requirements of the TOE a sensitive family (FAU_SAS)
of the Class FAU (Security Audit) is defined here. This family describes the functional
requirements for the storage of audit data. It has a more general approach than
FAU_GEN, because it does not necessarily require the data to be generated by the
TOE itself and because it does not give specific details of the content of the audit
records.
The family “Audit data storage (FAU_SAS)” is specified as follows.
FAU_SAS Audit data storage
Family behaviour
This family defines functional requirements for the storage of audit data.
Component levelling
FAU_SAS.1 Requires the TOE to provide the possibility to store audit data.
Management: FAU_SAS.1
There are no management activities foreseen.
Audit: FAU_SAS.1
There are no actions defined to be auditable.
FAU_SAS.1 Audit storage
Hierarchical to: No other components.
Dependencies: No dependencies.
FAU_SAS.1.1 The TSF shall provide [assignment: authorized users] with the capability to store
[assignment: list of audit information] in the audit records.
FAU_SAS Audit data storage 1
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 40/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
5.2 Definition of the Family FCS_RND
To define the IT security functional requirements of the TOE an additional family
(FCS_RND) of the Class FCS (cryptographic support) is defined here. This family
describes the functional requirements for random number generation used for
cryptographic purposes. The component FCS_RND is not limited to generation of
cryptographic keys unlike the component FCS_CKM.1. The similar component
FIA_SOS.2 is intended for non-cryptographic use.
The family “Generation of random numbers (FCS_RND)” is specified as follows.
FCS_RND Generation of random numbers
Family behaviour
This family defines quality requirements for the generation of random numbers which
are intended to be use for cryptographic purposes.
Component leveling:
FCS_RND.1 Generation of random numbers requires that random numbers meet
a defined quality metric.
Management: FCS_RND.1
There are no management activities foreseen.
Audit: FCS_RND.1
There are no actions defined to be auditable.
FCS_RND.1 Quality metric for random numbers ration
Hierarchical to: No other components.
Dependencies: No dependencies.
FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers that meet
[assignment: a defined quality metric].
5.3 Definition of the Family FMT_LIM
The family FMT_LIM describes the functional requirements for the Test Features of the
TOE. The new functional requirements were defined in the class FMT because this class
addresses the management of functions of the TSF. The examples of the technical
FCS_RND Generation of random numbers 1
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 41/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
mechanism used in the TOE show that no other class is appropriate to address the
specific issues of preventing the abuse of functions by limiting the capabilities of the
functions and by limiting their availability.
The family “Limited capabilities and availability (FMT_LIM)” is specified as follows.
FMT_LIM Limited capabilities and availability
Family behaviour
This family defines requirements that limit the capabilities and availability of functions
in a combined manner. Note that FDP_ACF restricts the access to functions whereas
the Limited capability of this family requires the functions themselves to be designed
in a specific manner.
Component levelling
FMT_LIM.1 Limited capabilities requires that the TSF is built to provide only the capabilities
(perform action, gather information) necessary for its genuine purpose.
FMT_LIM.2 Limited availability requires that the TSF restrict the use of functions (refer to
Limited capabilities (FMT_LIM.1)). This can be achieved, for instance, by
removing or by disabling functions in a specific phase of the TOE’s life-cycle.
Management: FMT_LIM.1, FMT_LIM.2
There are no management activities foreseen.
Audit: FMT_LIM.1, FMT_LIM.2
There are no actions defined to be auditable.
To define the IT security functional requirements of the TOE a sensitive family
(FMT_LIM) of the Class FMT (Security Management) is defined here. This family
describes the functional requirements for the Test Features of the TOE. The new
functional requirements were defined in the class FMT because this class addresses
the management of functions of the TSF. The examples of the technical mechanism
used in the TOE show that no other class is appropriate to address the specific issues
of preventing the abuse of functions by limiting the capabilities of the functions and
by limiting their availability
FMT_LIM Limited capabilities and availability
2
1
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 42/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
The TOE Functional Requirement “Limited capabilities (FMT_LIM.1)” is specified as
follows.
FMT_LIM.1 Limited capabilities.
Hierarchical to: No other components.
Dependencies: FMT_LIM.2 Limited availability.
FMT_LIM.1.1 The TSF shall be designed and implemented in a manner that limits its
capabilities so that in conjunction with “Limited availability (FMT_LIM.2)” the
following policy is enforced [assignment: Limited capability and availability
policy].
The TOE Functional Requirement “Limited availability (FMT_LIM.2)” is specified as
follows.
FMT_LIM.2 Limited availability.
Hierarchical to: No other components.
Dependencies: FMT_LIM.1 Limited capabilities.
FMT_LIM.2.1 The TSF shall be designed in a manner that limits its availability so that in
conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is
enforced [assignment: Limited capability and availability policy].
Application note 1: The functional requirements FMT_LIM.1 and FMT_LIM.2 assume
that there are two types of mechanisms (limited capabilities and limited availability)
which together shall provide protection in order to enforce the policy. This also allows
that
 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
 the TSF is designed with test and support functionality that is removed from, or disabled in,
the product prior to the Operational Use Phase.
The combination of both requirements shall enforce the policy.
5.4 Definition of the Family FPT_EMS
The sensitive family FPT_EMS (TOE Emanation) of the Class FPT (Protection of the
TSF) is defined here to describe the IT security functional requirement of the TOE. The
TOE shall prevent attacks against the TOE and other secret data where the attack is
based on external observable physical phenomena of the TOE. Examples of such
attacks are evaluation of TOE’s electromagnetic radiation, simple power analysis
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 43/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
(SPA), differential power analysis (DPA), timing attacks, etc. This family describes the
functional requirements for the limitation of intelligible emanations which are not
directly addressed by any other component of CC part 2 [R2].
The family “TOE Emanation (FPT_EMS)” is specified as follows.
FPT_EMS TOE emanation
Family behaviour
This family defines requirements to mitigate intelligible emanations.
Component leveling
FPT_EMS.1 TOE emanation has two constituents:
FPT_EMS.1.1 Limit of Emissions requires to not emit intelligible emissions enabling access to
TSF data or user data.
FPT_EMS.1.2 Interface Emanation requires to not emit interface emanation enabling access
to TSF data or user data.
Management: FPT_EMS.1
There are no management activities foreseen.
Audit: FPT_EMS.1
There are no actions defined to be auditable.
FPT_EMS.1 TOE emanation
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMS.1.1 The TOE shall not emit [assignment: types of emissions] in excess of
[assignment: specified limits] enabling access to [assignment: list of types of
TSF data] and [assignment: list of types of user data].
FPT_EMS.1.2 The TSF shall ensure [assignment: type of users] are unable to use the following
interface [assignment: type of connection] to gain access to [assignment: list of
types of TSF data] and [assignment: list of types of user data].
FPT_EMS TOE emanation 1
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 44/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
5.5 Definition of the Family FIA_API
To describe the security functional requirements of the TOE a sensitive family
(FIA_API) of the class FIA (Identification and Authentication) is defined here. This
family describes the functional requirements for the proof of the claimed identity for
the authentication verification by an external entity where the other families of the
class FIA address the verification of the identity of an external entity.
The family “TOE Emanation (FPT_EMS)” is specified as follows.
FIA_API Authentication Proof of Identity
Family behaviour
This family defines functions provided by the TOE to prove their identity and to be
verified by an external entity in the TOE IT environment.
Component leveling
FIA_API.1 Authentication Proof of Identity
Management: FIA_API.1
The following actions should be considered for the management functions in
FMT: Management of authentication information used to prove the claimed
identity.
Audit: There are no actions defined to be auditable.
FIA_API.1 Authentication Proof of Identity
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism] to prove the
identity of the [assignment: authorized used or role].
FIA_API Authentication Proof of Identity 1
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 45/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
6 Security Functional Requirements
6.1 Security Functional Requirements
This section identifies the security functional requirements for the TOE. Some
refinement/selection/assignment operations in the SFRs are determined in the PP MRTD BAC
[R5], some are let with unspecified values. Assignments made by the PP MRTD BAC [R5]
authors are marked as bold text, while assignments made by the ST author are marked as
bold text and in italics. The iteration operation is used when a component is repeated with
varying operations. Iteration is denoted by showing a slash "/", and the iteration indicator after
the component identifier.
FCS_CKM.1 Cryptographic key generation
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm Document Basic Access Key
Derivation Algorithm and specified cryptographic key sizes 112 bit that meet
the following: [R9], normative appendix 5.
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method Overwriting with random
data that meets the following: none.
Application note:
The TOE shall destroy the Triple-DES encryption key and the Retail-MAC message
authentication keys for secure messaging
FCS_COP.1/SHA Cryptographic operation
FCS_COP.1.1/SHA The TSF shall perform hashing in accordance with a specified
cryptographic algorithm SHA-1, SHA224, SHA-256,SHA 384 and SHA 512
and cryptographic key sizes none that meet the following: FIPS 180-2.
Application note:
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 46/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
This SFR requires the TOE to implement the hash function SHA-1 for the cryptographic
primitive of the Basic Access Control Authentication Mechanism (see also FIA_UAU.4)
according to [R9].
FCS_COP.1/ENC Cryptographic operation
FCS_COP.1.1/ENC The TSF shall perform secure messaging (BAC) -
encryption and decryption
in accordance with a specified cryptographic algorithm Triple-DES CBC and
cryptographic key sizes 112 bits that meet the following: 46-3 [R14] and
[R9], normative appendix 5, A5.3.
Application note:
This SFR requires the TOE to implement the cryptographic primitive for secure messaging with
encryption of the transmitted data. The keys are agreed between the TOE and the terminal as
part of the Basic Access Control Authentication Mechanism according to the FCS_CKM.1 and
FIA_UAU.4.
FCS_COP.1/AUTH Cryptographic operation
FCS_COP.1.1/AUTH The TSF shall perform symmetric authentication -
encryption and decryption
in accordance with a specified cryptographic algorithm Triple-DES in CBC
mode and cryptographic key sizes 112 bits that meet the following: FIPS 46-
3 [R14].
Application note:
This SFR requires the TOE to implement the cryptographic primitive for authentication attempt
of a terminal as Personalization Agent by means of the symmetric authentication mechanism
(cf. FIA_UAU.4).
FCS_COP.1/MAC Cryptographic operation
FCS_COP.1.1/MAC The TSF shall perform secure messaging - message
authentication code
in accordance with a specified cryptographic algorithm Retail MAC and
cryptographic key sizes 112 bits that meet the following: ISO 9797 (MAC
algorithm 3, block cipher DES, Sequence Message Counter, padding
mode 2).
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 47/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Application note:
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 the Basic Access Control Authentication Mechanism according to the
FCS_CKM.1 and FIA_UAU.4.
FIA_UID.1 Timing of identification
FIA_UID.1.1 The TSF shall allow
(1) to read the Initialization Data in Phase 2 "Manufacturing",
(2) to read the random identifier in Phase 3 "Personalization of the
MRTD",
(3) to read the random identifier in Phase 4 "Operational Use" on behalf
of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
Application note:
The IC manufacturer and the MRTD manufacturer write the Initialization Data and/or Pre-
personalization Data in the audit records of the IC during the Phase 2 "Manufacturing". The
audit records can be written only in the Phase 2 Manufacturing of the TOE. At this time the
Manufacturer is the only user role available for the TOE. The MRTD manufacturer may create
the user role Personalization Agent for transition from Phase 2 to Phase 3 "Personalization of
the MRTD". The users in role Personalization Agent identify themselves by means of selecting
the authentication key. After personalization in the Phase 3 (i.e. writing the digital MRZ and
the Document Basic Access Keys) the user role Basic Inspection System is created by writing
the Document Basic Access Keys. The Basic Inspection System is identified as default user
after power up or reset of the TOE i.e. the TOE will use the Document Basic Access Key to
authenticate the user as Basic Inspection System.
In the "Operational Use" phase the MRTD must not allow anybody to read the ICCSN, the
MRTD identifier or any other unique identification before the user is authenticated as Basic
Inspection System (cf. T.Chip_ID). Note that the terminal and the MRTD's chip use a (randomly
chosen) identifier for the communication channel to allow the terminal to communicate with
more then one RFID. If this identifier is randomly selected it will not violate the
OT.Identification.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 48/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
FIA_UAU.1 Timing of authentication
FIA_UAU.1.1 The TSF shall allow
(1) to read the Initialization Data in Phase 2 "Manufacturing",
(2) to read the random identifier in Phase 3 "Personalization of the
MRTD",
(3) identify themselves by selection of the authentication key on behalf
of the user to be performed before the user is authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of that user.
Application note:
The Basic Inspection System and the Personalization Agent authenticate themselves. The TOE
shall meet the requirements of "Single-use authentication mechanisms (FIA_UAU.4)" as
specified below (Common Criteria Part 2).
FIA_UAU.4 Single-use authentication mechanisms
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to
(1) Basic Access Control Authentication Mechanism,
(2) Authentication Mechanism based on Triple-DES.
Application note:
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 Personalisation Agent may rely on
other mechanisms ensuring protection against replay attacks, such as the use of an internal
counter as a diversifier.
The Basic Access Control Mechanism is a mutual device authentication mechanism defined in
[R9]. In the first step the terminal authenticates itself to the MRTD's chip and the MRTD's chip
authenticates to the terminal in the second step. In this second step the MRTD's chip provides
the terminal with a challenge-response-pair which allows a unique identification of the MRTD's
chip with some probability depending on the entropy of the Document Basic Access Keys.
Therefore the TOE shall stop further communications if the terminal is not successfully
authenticated in the first step of the protocol to fulfill the security objective OT.Identification
and to prevent T.Chip_ID. The TOE shall meet the requirement "Multiple authentication
mechanisms (FIA_UAU.5)" as specified below (Common Criteria Part 2).
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 49/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
FIA_UAU.5 Multiple authentication mechanisms
FIA_UAU.5.1 The TSF shall provide
(1) Basic Access Control Authentication Mechanism,
(2) Symmetric Authentication Mechanism based on Triple-DES to
support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user's claimed identity according to
the
(1) The TOE accepts the authentication attempt as Personalization
Agent by the Symmetric Authentication Mechanism with the
Personalization Agent Key during personalization phase of the
product's life cycle (phase 3),
(2) the TOE accepts the authentication attempt as Basic Inspection
System only by means of the Basic Access Control Authentication
Mechanism with the Document Basic Access Keys.
Application note:
In case the "Common Criteria Protection Profile Machine Readable Travel Document with
"ICAO Application", Extended Access Control" [R6] should also be fulfilled the Personalization
Agent should not be authenticated by using the BAC or the symmetric authentication
mechanism as they base on the two-key Triple-DES. The authentication of the personalization
agent is only possible during phase 3 of the life-cycle, using symetric authentication
mechanism. This can be considered as a refinement of the SFR FIA_UAU.5 of the PP. However,
this refinement is more restrictive than the PP, increase the level off security and therefore,
do not impact the conformity to the PP.
The Basic Access Control Mechanism includes the secure messaging for all commands
exchanged after successful authentication of the inspection system. The Personalization Agent
may use Symmetric Authentication Mechanism without secure messaging mechanism as well
if the personalization environment prevents eavesdropping to the communication between
TOE and personalization terminal. The Basic Inspection System may use the Basic Access
Control Authentication Mechanism with the Document Basic Access Keys. The TOE shall meet
the requirement "Re-authenticating (FIA_UAU.6)" as specified below (Common Criteria Part
2).
FIA_UAU.6 Re-authenticating
FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions each
command sent to the TOE during a BAC mechanism based
communication after successful authentication of the terminal with
Basic Access Control Authentication Mechanism.
Application note:
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 50/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
The Basic Access Control Mechanism specified in [R9] includes the 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 Retail-MAC whether
it was sent by the successfully authenticated terminal (see FCS_COP.1/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 BAC user.
Note that in case the TOE should also fulfill [R6] the BAC communication might be followed
by a Chip Authentication mechanism establishing a new secure messaging that is distinct from
the BAC based communication. In this case the condition in FIA_UAU.6 above should not
contradict to the option that commands are sent to the TOE that are no longer meeting the
BAC communication but are protected by a more secure communication channel established
after a more advanced authentication process. The TOE shall meet the requirement «
Authentication failure handling (FIA_AFL.1) » as specified below (Common Criteria Part 2).
FIA_AFL.1 Authentication failure handling
FIA_AFL.1.1 The TSF shall detect when 3 unsuccessful authentication attempts
occur related to Failure of a TDES based Authentication attempt.
FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts
has been met, the TSF shall consecutively increase the reaction time of
the TOE before a new authentication attempt
FDP_ACC.1 Subset access control
FDP_ACC.1.1 The TSF shall enforce the Basic Access Control SFP on terminals
gaining write, read and modification access to data in the EF.COM,
EF.SOD, EF.DG1 to EF.DG16 of the logical MRTD.
FDP_ACF.1 Security attribute based access control
FDP_ACF.1.1 The TSF shall enforce the Basic Access Control SFP to objects
based on the following:
Subjects:
Personalization Agent,
Basic Inspection System
Terminal,
Objects:
data EF.DG1 to EF.DG16 of the logical MRTD,
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 51/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Data in EF.COM,
Data in EF.SOD.
Security attributes:
Authentication status of terminals.
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed:
(1) the successfully authenticated Personalization Agent is allowed to
write and to read the data of the EF.COM, EF.SOD, EF.DG1 to EF.DG16
of the logical MRTD,
(2) the successfully authenticated Basic Inspection System is allowed
to read the data in EF.COM, EF.SOD, EF.DG1, EF.DG2 and EF.DG5 to
EF.DG16 of the logical MRTD and perform Active Authentication.
FDP_ACF.1.3 The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: none.
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on
the following additional rules:
(1) Any terminal is not allowed to modify any of the EF.DG1 to EF.DG16
of the logical MRTD,
(2) Any terminal is not allowed to read any of the EF.DG1 to EF.DG16
of the logical MRTD,
(3) The Basic Inspection System is not allowed to read the data in
EF.DG3 and EF.DG4.
Application note:
The inspection system needs special authentication and authorization for read access to DG3
and DG4 not defined in this security target (cf. [R6] for details).
FDP_UCT.1 Basic data exchange confidentiality
FDP_UCT.1.1 The TSF shall enforce the Basic Access Control SFP to transmit
and receive user data in a manner protected from unauthorised disclosure.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 52/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
FDP_UIT.1 Data exchange integrity
FDP_UIT.1.1 The TSF shall enforce the Basic Access Control SFP to transmit
and receive user data in a manner protected from modification, deletion,
insertion and replay errors.
FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether
modification, deletion, insertion and replay has occurred.
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) Personalization,
(3) Configuration.
Application note:
The configuration capabilities of the TOE are available during the pre-personalization
(initialization) and personalization phases.
FMT_SMR.1 Security roles
FMT_SMR.1.1 The TSF shall maintain the roles
(1) Manufacturer,
(2) Personalization Agent,
(3) Basic Inspection System.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Application note:
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. The TOE shall meet the
requirement "Limited capabilities (FMT_LIM.1)" as specified below (Common Criteria Part 2
extended).
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 53/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
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 does not allow:
(1) User Data to be disclosed or manipulated,
(2) TSF data to be disclosed or manipulated,
(3) Software to be reconstructed and
(4) Substantial information about construction of TSF to be gathered
which may enable other attacks
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 does not allow,
(1) User Data to be disclosed or manipulated,
(2) TSF data to be disclosed or manipulated
(3) software to be reconstructed and
(4) substantial information about construction of TSF to be gathered
which may enable other attacks
Application note:
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 provide an optional approach to enforce the same policy.
FMT_MTD.1/INI_ENA Management of TSF 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
FMT_MTD.1.1/INI_DIS The TSF shall restrict the ability to disable read access
for users to the Initialization Data to the Personalization Agent.
Application note:
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 54/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
According to P.Manufact the IC Manufacturer and the MRTD Manufacturer are the default
users assumed by the TOE in the role Manufacturer during the Phase 2 "Manufacturing" but
the TOE is not requested to distinguish between these users within the role Manufacturer. The
TOE may restrict the ability to write the Initialization Data and the Pre-personalization Data by
allowing to write these data only once and
blocking the role Manufacturer at the end of the Phase 2. The IC Manufacturer may write
the Initialization Data which includes but are not limited to the IC Identifier as required
by FAU_SAS.1. The Initialization Data provides a unique identification of the IC which is
used to trace the IC in the Phase 2 and 3 "personalization" but is not needed and may
be misused in the Phase 4 "Operational Use". Therefore the external read access shall
be blocked. The MRTD Manufacturer will write the Pre-personalization Data.
FMT_MTD.1/KEY_WRITE Management of TSF data
FMT_MTD.1.1/KEY_WRITE The TSF shall restrict the ability to write the
Document Basic Access Keys
Active Authenticate Keys to the Personalization Agent.
Application note:
According to P.Manufact the IC Manufacturer and the MRTD Manufacturer are the default
users assumed by the TOE in the role Manufacturer during the Phase 2 "Manufacturing" but
the TOE is not requested to distinguish between these users within the role Manufacturer. The
TOE may restrict the ability to write the Initialization Data and the Pre-personalization Data by
allowing to write these data only once and
blocking the role Manufacturer at the end of the Phase 2. The IC Manufacturer may write
the Initialization Data which includes but are not limited to the IC Identifier as required
by FAU_SAS.1. The Initialization Data provides a unique identification of the IC which is
used to trace the IC in the Phase 2 and 3 "personalization" but is not needed and may
be misused in the Phase 4 "Operational Use". Therefore the external read access shall
be blocked. The MRTD Manufacturer will write the Pre-personalization Data.
FMT_MTD.1/KEY_READ Management of TSF data
FMT_MTD.1.1/KEY_READ The TSF shall restrict the ability to read the
(1) Document Basic Access Keys,
(2) Personalization Agent Keys,
(3) Active Authenticate Keys to none.
Application note:
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 55/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
The Personalization Agent generates, stores and ensures the correctness of the Document
Basic Access Keys.
FPT_EMS.1 TOE Emanation
FPT_EMS.1.1 The TOE shall not emit side channel in excess of limits of the
state of the art enabling access to Personalization Agent Authentication
Keys and Active Authentication Private Keys and none
FPT_EMS.1.2 The TSF shall ensure any unauthorized users are unable to use
the following interface smart card circuit contacts to gain access to
Personalization Agent Authentication Keys and none.
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 out-of-range operating conditions where therefore a
malfunction could occur,
(2) Failure detected by TSF according to FPT_TST.1.
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:
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
assuming that there might be an attack at any time and
countermeasures are provided at any time.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 56/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
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 TSF data.
FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify
the integrity of TSF data.
FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify
the integrity of stored TSF executable code.
Application note:
the FPT_TST.1 requirement describes requirement for the Personalization and Operational Use
phases. Self-tests during the Manufacturing phase are described in the chip security target
and have been evaluated during the chip evaluation.
FAU_SAS.1 Audit storage
FAU_SAS.1.1 The TSF shall provide the Manufacturer with the capability to
store the IC Identification Data in the audit records.
Application note:
The Manufacturer role is the default user identity assumed by the TOE in the Phase 2
Manufacturing. The IC manufacturer and the MRTD manufacturer in the Manufacturer role
write the Initialization Data and/or Pre-personalization Data as TSF Data of the TOE. The audit
records are write-only-once data of the MRTD's chip (see FMT_MTD.1/INI_DIS).
FCS_RND.1 Quality metric for random numbers
FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers
with a reprocessing algorithmic that meet AIS31 Class P2 quality metric.
Application note:
This SFR requires the TOE to generate random numbers used for the authentication protocols
as required by FIA_UAU.4.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 57/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Additional SFRs for AA
FIA_API.1/AAP Authentication Proof of Identity
FIA_API.1.1/AAP The TSF shall provide a Active Authentication Protocol
according to R9 to prove the identity of the TOE.
FCS_COP.1/AA_SIGN Cryptographic operation
FCS_COP.1.1/AA_SIGN The TSF shall perform:
- digital signature generation in accordance with a specified
cryptographic algorithm ECDSA and cryptographic key sizes 192, 224,
256, 320, 384, 512, and 521 bits for ECDSA that meet the following:
ISO15946-2 specified in [R13] for ECDSA in combination with SHA1,
SHA224, SHA 256, SHA384 and SHA512
- digital signature generation in accordance with a specified
cryptographic algorithm RSA and cryptographic key sizes 1536, 1792,
2048, 2560 and 3072 bits for RSA and 1536 that meet the following:
ISO15946-2 specified in [R12] for RSA in combination with SHA1,
SHA224, SHA 256, SHA384 and SHA512
Application note:
This SFR has been added to this ST in order to support the signing of challenges generated by
the Inspection System as part of the optional Active Authentication protocol specified in [R9].
6.2 Security Assurance Requirements
The security assurance requirement level is EAL4 augmented with ALC_DVS.2, ADV_FSP.5,
ADV_INT.2, ADV_TDS.4, ALC_CMS.5, ALC_TAT.2 and ATE_DPT.3.
6.3 Security Requirements Rationale
6.3.1 Objectives
6.3.1.1 Security Objectives for the TOE
OT.AC_Pers The security objective OT.AC_Pers "Access Control for
Personalization of logical MRTD" addresses the access control of the writing the
logical MRTD. The write access to the logical MRTD data are defined by the SFR
FDP_ACC.1 and FDP_ACF.1 as follows: only the successfully authenticated
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 58/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Personalization Agent is allowed to write the data of the groups EF.DG1 to
EF.DG16 of the logical MRTD only once.
The authentication of the terminal as Personalization Agent shall be performed
by TSF according to SRF FIA_UAU.4 and FIA_UAU.5. The Personalization Agent
can be authenticated either by using the BAC mechanism (FCS_CKM.1,
FCS_COP.1/SHA, FCS_RND.1 (for key generation), and FCS_COP.1/ENC as well
as FCS_COP.1/MAC) with the personalization key or for reasons of
interoperability with the [R6] by using the symmetric authentication mechanism
(FCS_COP.1/AUTH). In case of using the BAC mechanism the SFR FIA_UAU.6
describes the re-authentication and FDP_UCT.1 and FDP_UIT.1 the protection
of the transmitted data by means of secure messaging implemented by the
cryptographic functions according to FCS_CKM.1, FCS_COP.1/SHA, FCS_RND.1
(for key generation), and FCS_COP.1/ENC as well as FCS_COP.1/MAC for the
ENC_MAC_Mode.
The SFR FMT_SMR.1 lists the roles (including Personalization Agent) and the
SFR FMT_SMF.1 lists the TSF management functions (including Personalization)
setting the Document Basic Access Keys according to the SFR
FMT_MTD.1/KEY_WRITE as authentication reference data. The SFR
FMT_MTD.1/KEY_READ prevents read access to the secret key of the
Personalization Agent Keys and ensure together with the SFR FCS_CKM.4,
FPT_EMS.1, FPT_FLS.1 and FPT_PHP.3 the confidentially of these keys.
OT.Data_Int The security objective OT.Data_Int "Integrity of personal data"
requires the TOE to protect the integrity of the logical MRTD stored on the
MRTD's chip against physical manipulation and unauthorized writing. The write
access to the logical MRTD data is defined by the SFR FDP_ACC.1 and
FDP_ACF.1 in the same way: only the Personalization Agent is allowed to write
the data of the groups EF.DG1 to EF.DG16 of the logical MRTD (FDP_ACF.1.2,
rule 1) and terminals are not allowed to modify any of the data groups EF.DG1
to EF.DG16 of the logical MRTD (cf. FDP_ACF.1.4). The SFR FMT_SMR.1 lists the
roles (including Personalization Agent) and the SFR FMT_SMF.1 lists the TSF
management functions (including Personalization). The authentication of the
terminal as Personalization Agent shall be performed by TSF according to SRF
FIA_UAU.4, FIA_UAU.5 and FIA_UAU.6 using either FCS_COP.1/ENC and
FCS_COP.1/MAC or FCS_COP.1/AUTH.
The security objective OT.Data_Int "Integrity of personal data" requires the
TOE to ensure that the inspection system is able to detect any modification of
the transmitted logical MRTD data by means of the BAC mechanism. The SFR
FIA_UAU.6, FDP_UCT.1 and FDP_UIT.1 requires the protection of the
transmitted data by means of secure messaging implemented by the
cryptographic functions according to FCS_CKM.1, FCS_COP.1/SHA, FCS_RND.1
(for key generation), and FCS_COP.1/ENC and FCS_COP.1/MAC for the
ENC_MAC_Mode. The SFR FMT_MTD.1/KEY_WRITE requires the Personalization
Agent to establish the Document Basic Access Keys in a way that they cannot
be read by anyone in accordance to FMT_MTD.1/KEY_READ.
OT. Data_Conf The security objective OT.Data_Conf "Confidentiality of personal
data" requires the TOE to ensure the confidentiality of the logical MRTD data
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 59/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
groups EF.DG1 to EF.DG16. The SFR FIA_UID.1 and FIA_UAU.1 allow only those
actions before identification respective authentication which do not violate
OT.Data_Conf. The read access to the logical MRTD data is defined by the
FDP_ACC.1 and FDP_ACF.1.2: the successful authenticated Personalization
Agent is allowed to read the data of the logical MRTD (EF.DG1 to EF.DG16).
FIA_AFL.1 will block the authentication key after 32 failed authentications to
prevent from a brute force attack. The successful authenticated Basic Inspection
System is allowed to read the data of the logical MRTD (EF.DG1, EF.DG2 and
EF.DG5 to EF.DG16). The SFR FMT_SMR.1 lists the roles (including
Personalization Agent and Basic Inspection System) and the SFR FMT_SMF.1
lists the TSF management functions (including Personalization for the key
management for the Document Basic Access Keys).
The SFR FIA_UAU.4 prevents reuse of authentication data to strengthen the
authentication of the user. The SFR FIA_UAU.5 enforces the TOE to accept the
authentication attempt as Basic Inspection System only by means of the Basic
Access Control Authentication Mechanism with the Document Basic Access Keys.
Moreover, the SFR FIA_UAU.6 requests secure messaging after successful
authentication of the terminal with Basic Access Control Authentication
Mechanism which includes the protection of the transmitted data in
ENC_MAC_Mode by means of the cryptographic functions according to
FCS_COP.1/ENC and FCS_COP.1/MAC (cf. the SFR FDP_UCT.1 and FDP_UIT.1).
(for key generation), and FCS_COP.1/ENC and FCS_COP.1/MAC for the
ENC_MAC_Mode. The SFR FCS_CKM.1, FCS_CKM.4, FCS_COP.1/SHA and
FCS_RND.1 establish the key management for the secure messaging keys. The
SFR FMT_MTD.1/KEY_WRITE addresses the key management and
FMT_MTD.1/KEY_READ prevents reading of the Document Basic Access Keys.
Note, neither the security objective OT.Data_Conf nor the SFR FIA_UAU.5
requires the Personalization Agent to use the Basic Access Control
Authentication Mechanism or secure messaging.
OT.Identification The security objective OT.Identification "Identification and
Authentication of the TOE" address the storage of the IC Identification Data
uniquely identifying the MRTD's chip in its non-volatile memory. This will be
ensured by TSF according to SFR FAU_SAS.1.
Furthermore, the TOE shall identify itself only to a successful authenticated
Basic Inspection System in Phase 4 "Operational Use". The SFR
FMT_MTD.1/INI_ENA allows only the Manufacturer to write Initialization Data
and Pre-personalization Data (including the Personalization Agent key). The SFR
FMT_MTD.1/INI_DIS allows the Personalization Agent to disable Initialization
Data if their usage in the phase 4 "Operational Use" violates the security
objective OT.Identification. FIA_AFL.1 will block the authentication key after 32
failed authentications to prevent from a brute force attack. The SFR FIA_UID.1
and FIA_UAU.1 do not allow reading of any data uniquely identifying the MRTD's
chip before successful authentication of the Basic Inspection Terminal and will
stop communication after unsuccessful authentication attempt.
OT.Prot_Abuse-Func The security objective OT.Prot_Abuse Func "Protection
against Abuse of Functionality" is ensured by the SFR FMT_LIM.1 and FMT_LIM.2
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 60/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
which prevent misuse of test functionality of the TOE or other which may not be
used after TOE Delivery.
OT.Prot_Inf_Leak The security objective OT.Prot_Inf_Leak "Protection against
Information Leakage" requires the TOE to protect confidential TSF data stored
and/or processed in the MRTD's chip against disclosure:
by measurement and analysis of the shape and amplitude of signals or the time
between events found by measuring signals on the electromagnetic field, power
consumption, clock, or I/O lines, which is addressed by the SFR FPT_EMS.1,
by forcing a malfunction of the TOE, which is addressed by the SFR FPT_FLS.1 and
FPT_TST.1, and/or
by a physical manipulation of the TOE, which is addressed by the SFR FPT_PHP.3.
OT.Prot_Phys-Tamper The security objective OT.Prot_Phys-Tamper
"Protection against Physical Tampering" is covered by the SFR FPT_PHP.3.
OT.Prot_Malfunction The security objective OT.Prot_Malfunction "Protection
against Malfunctions" is covered by
the SFR FPT_TST.1 which requires self tests to demonstrate the correct operation and
tests of authorized users to verify the integrity of TSF data and TSF code, and
the SFR FPT_FLS.1 which requires a secure state in case of detected failure or operating
conditions possibly causing a malfunction.
OT.Chip_Auth_Proof The security objective "OT.Chip_Auth_Proof" is ensured by
Active Authentication defined by FCS_COP.1/AA_SIGN, FIA_API.1/AAP and by
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 61/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
FCS_COP.1/SHA, FMT_MTD.1/KEY_WRITE and FMT_MTD.1/KEY_READ for the
generation of the RSA and ECDSA Signature.
6.3.2 Rationale tables of Security Objectives and SFRs
Security Objectives Security Functional Requirements Rationale
OT.AC_Pers FCS_CKM.1, FCS_CKM.4, FCS_COP.1/SHA,
FCS_COP.1/ENC, FCS_COP.1/AUTH,
FCS_COP.1/MAC, FIA_UAU.4, FIA_UAU.5,
FIA_UAU.6, FDP_ACC.1, FDP_ACF.1,
FDP_UCT.1, FDP_UIT.1, FMT_SMF.1,
FMT_SMR.1, FMT_MTD.1/KEY_WRITE,
FMT_MTD.1/KEY_READ, FPT_FLS.1,
FPT_PHP.3, FCS_RND.1, FPT_EMS.1
Section 6.3.1.1
OT.Data_Int FCS_CKM.1, FCS_COP.1/SHA,
FCS_COP.1/ENC, FCS_COP.1/AUTH,
FCS_COP.1/MAC, FIA_UAU.4, FIA_UAU.5,
FIA_UAU.6, FDP_ACC.1, FDP_ACF.1,
FDP_UCT.1, FDP_UIT.1, FMT_SMF.1,
FMT_SMR.1, FMT_MTD.1/KEY_WRITE,
FMT_MTD.1/KEY_READ, FCS_RND.1
Section 6.3.1.1
OT. Data_Conf FCS_CKM.1, FCS_CKM.4, FCS_COP.1/SHA,
FCS_COP.1/ENC, FCS_COP.1/MAC,
FIA_UID.1, FIA_AFL.1, FIA_UAU.1,
FIA_UAU.4, FIA_UAU.5, FIA_UAU.6,
FDP_ACC.1, FDP_ACF.1, FDP_UCT.1,
FDP_UIT.1, FMT_SMF.1, FMT_SMR.1,
FMT_MTD.1/KEY_WRITE,
FMT_MTD.1/KEY_READ, FCS_RND.1
Section 6.3.1.1
OT.Identification FIA_UID.1, FIA_AFL.1, FIA_UAU.1,
FMT_MTD.1/INI_ENA,
FMT_MTD.1/INI_DIS, FAU_SAS.1
Section 6.3.1.1
OT.Prot_Abuse-
Func
FMT_LIM.1, FMT_LIM.2 Section 6.3.1.1
OT.Prot_Inf_Leak FPT_FLS.1, FPT_PHP.3, FPT_TST.1,
FPT_EMS.1
Section 6.3.1.1
OT.Prot_Phys-
Tamper
FPT_PHP.3 Section 6.3.1.1
OT.Prot_Malfunction FPT_FLS.1, FPT_TST.1 Section 6.3.1.1
OT.Chip_Auth_Proof FCS_COP.1/SHA, FMT_MTD.1/KEY_WRITE,
FMT_MTD.1/KEY_READ,
FCS_COP.1/AA_SIGN, FIA_API.1/AAP
Section 6.3.1.1
Table 7 - Security Objectives and SFRs - Coverage
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 62/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Security Functional
Requirements
Security Objectives Rationale
FCS_CKM.1 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FCS_CKM.4 OT.AC_Pers, OT. Data_Conf
FCS_COP.1/SHA OT.AC_Pers, OT.Data_Int, OT.
Data_Conf, OT.Chip_Auth_Proof
FCS_COP.1/ENC OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FCS_COP.1/AUTH OT.AC_Pers, OT.Data_Int
FCS_COP.1/MAC OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FIA_UID.1 OT. Data_Conf, OT.Identification
FIA_UAU.1 OT. Data_Conf, OT.Identification
FIA_UAU.4 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FIA_UAU.5 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FIA_UAU.6 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FIA_AFL.1 OT. Data_Conf, OT.Identification
FIA_API.1/AAP OT.Chip_Auth_Proof
FDP_ACC.1 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FDP_ACF.1 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FDP_UCT.1 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FDP_UIT.1 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FMT_SMF.1 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FMT_SMR.1 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FMT_LIM.1 OT.Prot_Abuse-Func
FMT_LIM.2 OT.Prot_Abuse-Func
FMT_MTD.1/INI_ENA OT.Identification
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 63/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Security Functional
Requirements
Security Objectives Rationale
FMT_MTD.1/INI_DIS OT.Identification
FMT_MTD.1/KEY_WRITE OT.AC_Pers, OT.Data_Int, OT.
Data_Conf, OT.Chip_Auth_Proof
FMT_MTD.1/KEY_READ OT.AC_Pers, OT.Data_Int, OT.
Data_Conf, OT.Chip_Auth_Proof
FPT_EMS.1 OT.AC_Pers, OT.Prot_Inf_Leak
FPT_FLS.1 OT.AC_Pers, OT.Prot_Inf_Leak,
OT.Prot_Malfunction
FPT_PHP.3 OT.AC_Pers, OT.Prot_Inf_Leak,
OT.Prot_Phys-Tamper
FPT_TST.1 OT.Prot_Inf_Leak, OT.Prot_Malfunction
FAU_SAS.1 OT.Identification
FCS_RND.1 OT.AC_Pers, OT.Data_Int, OT.
Data_Conf
FCS_COP.1/AA_SIGN OT.Chip_Auth_Proof
Table 8 - SFRs and Security Objectives
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 64/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
6.3.3 Dependencies
6.3.3.1 SFRs dependencies
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 65/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Requirements CC Dependencies Satisfied Dependencies
FCS_CKM.1 (FCS_CKM.2 or
FCS_COP.1) and
(FCS_CKM.4)
FCS_CKM.4, FCS_COP.1/SHA,
FCS_COP.1/ENC,
FCS_COP.1/AUTH,
FCS_COP.1/MAC
FCS_CKM.4 (FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2)
FCS_CKM.1
FCS_COP.1/SHA (FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1, FCS_CKM.4
FCS_COP.1/ENC (FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1, FCS_CKM.4
FCS_COP.1/AUTH (FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_COP.1/MAC (FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1, FCS_CKM.4
FIA_UID.1 No dependencies
FIA_UAU.1 (FIA_UID.1) FIA_UID.1
FIA_UAU.4 No dependencies
FIA_UAU.5 No dependencies
FIA_UAU.6 No dependencies
FIA_AFL.1 (FIA_UAU.1) FIA_UAU.1
FIA_API.1/AAP No dependencies
FDP_ACC.1 (FDP_ACF.1) FDP_ACF.1
FDP_ACF.1 (FDP_ACC.1) and
(FMT_MSA.3)
FDP_ACC.1
FDP_UCT.1 (FDP_ACC.1 or
FDP_IFC.1) and
(FTP_ITC.1 or
FTP_TRP.1)
FDP_ACC.1
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 66/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Requirements CC Dependencies Satisfied Dependencies
FDP_UIT.1 (FDP_ACC.1 or
FDP_IFC.1) and
(FTP_ITC.1 or
FTP_TRP.1)
FDP_ACC.1
FMT_SMF.1 No dependencies
FMT_SMR.1 (FIA_UID.1) FIA_UID.1
FMT_LIM.1 (FMT_LIM.1) FMT_LIM.1
FMT_LIM.2 (FMT_LIM.1) FMT_LIM.1
FMT_MTD.1/INI_ENA (FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1, FMT_SMR.1
FMT_MTD.1/INI_DIS (FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1, FMT_SMR.1
FMT_MTD.1/KEY_WRITE (FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1, FMT_SMR.1
FMT_MTD.1/KEY_READ (FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1, FMT_SMR.1
FPT_EMS.1 No dependencies
FPT_FLS.1 No dependencies
FPT_PHP.3 No dependencies
FPT_TST.1 No dependencies
FAU_SAS.1 No dependencies
FCS_RND.1 No dependencies
FCS_COP.1/AA_SIGN (FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1, FCS_CKM.4
Table 9 - SFRs dependencies
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 67/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Rationale for the exclusion of dependencies
The dependency FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 of
FCS_COP.1/AUTH is unsupported. The SFR FCS_COP.1/AUTH uses the
symmetric Personalization Key permanently stored during the Pre-
Personalization process (cf. FMT_MTD.1/INI_ENA) by the manufacturer. Thus
there is neither the necessity to generate or import a key during the addressed
TOE lifecycle by the means of FCS_CKM.1 or FDP_ITC.
The dependency FCS_CKM.4 of FCS_COP.1/AUTH is unsupported. Since the
key is permanently stored within the TOE there is no need for FCS_CKM.4, too.
The dependency FMT_MSA.3 of FDP_ACF.1 is unsupported. The access
control TSF according to FDP_ACF.1 uses security attributes which are defined
during the personalization and are fixed over the whole life time of the TOE. No
management of these security attribute (i.e. SFR FMT_MSA.1 and FMT_MSA.2)
is necessary here.
The dependency FTP_ITC.1 or FTP_TRP.1 of FDP_UCT.1 is
unsupported. The SFR FDP_UCT.1 requires the use secure messaging between
the MRTD and the BIS. There is no need for sensitive SFR FTP_ITC.1, e.g. to
require this communication channel to be logically distinct from other
communication channels since there is only one channel.
The dependency FTP_ITC.1 or FTP_TRP.1 of FDP_UIT.1 is
unsupported. The FDP_UIT.1 requires the use secure messaging between the
MRTD and the BIS. There is no need for sensitive SFR FTP_ITC.1, e.g. to require
this communication channel to be logically distinct from other communication
channels since there is only one channel.
6.3.3.2 SARs dependencies
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 68/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Requirements CC Dependencies Satisfied Dependencies
ALC_DVS.2 No dependencies
ADV_FSP.5 (ADV_IMP.1) and (ADV_TDS.1) ADV_IMP.1, ADV_TDS.4
ADV_INT.2 (ADV_IMP.1) and (ADV_TDS.3) and
(ALC_TAT.1)
ADV_IMP.1, ADV_TDS.4,
ALC_TAT.2
ADV_TDS.4 (ADV_FSP.5) ADV_FSP.5
ALC_CMS.5 No dependencies
ALC_TAT.2 (ADV_IMP.1) ADV_IMP.1
ATE_DPT.3 (ADV_ARC.1) and (ADV_TDS.4)
and (ATE_FUN.1)
ADV_ARC.1, ADV_TDS.4,
ATE_FUN.1
ADV_ARC.1 (ADV_FSP.1) and (ADV_TDS.1) ADV_FSP.5, ADV_TDS.4
ADV_IMP.1 (ADV_TDS.3) and (ALC_TAT.1) ADV_TDS.4, ALC_TAT.2
AGD_OPE.1 (ADV_FSP.1) ADV_FSP.5
AGD_PRE.1 No dependencies
ALC_CMC.4 (ALC_CMS.1) and (ALC_DVS.1) and
(ALC_LCD.1)
ALC_DVS.2, ALC_LCD.1,
ALC_CMS.5
ALC_DEL.1 No dependencies
ALC_LCD.1 No dependencies
ASE_CCL.1 (ASE_ECD.1) and (ASE_INT.1) and
(ASE_REQ.1)
ASE_ECD.1, ASE_INT.1,
ASE_REQ.2
ASE_ECD.1 No dependencies
ASE_INT.1 No dependencies
ASE_OBJ.2 (ASE_SPD.1) ASE_SPD.1
ASE_REQ.2 (ASE_ECD.1) and (ASE_OBJ.2) ASE_ECD.1, ASE_OBJ.2
ASE_SPD.1 No dependencies
ASE_TSS.1 (ADV_FSP.1) and (ASE_INT.1) and
(ASE_REQ.1)
ASE_INT.1, ASE_REQ.2,
ADV_FSP.5
ATE_COV.2 (ADV_FSP.2) and (ATE_FUN.1) ATE_FUN.1, ADV_FSP.5
ATE_FUN.1 (ATE_COV.1) ATE_COV.2
ATE_IND.2 (ADV_FSP.2) and (AGD_OPE.1) and
(AGD_PRE.1) and (ATE_COV.1) and
(ATE_FUN.1)
AGD_OPE.1, AGD_PRE.1,
ATE_COV.2, ATE_FUN.1,
ADV_FSP.5
AVA_VAN.3 (ADV_ARC.1) and (ADV_FSP.4) and
(ADV_IMP.1) and (ADV_TDS.3) and
(AGD_OPE.1) and (AGD_PRE.1)
and (ATE_DPT.1)
ADV_ARC.1, ADV_IMP.1,
AGD_OPE.1, AGD_PRE.1,
ADV_FSP.5, ADV_TDS.4,
ATE_DPT.3
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 69/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Table 10 - SARs dependencies
6.3.4 Rationale for the Security Assurance Requirements
The assurance evaluation level is directly drawn from the Protection Profile for MRTD [R5] and
the rationale is directly available in the associated document ([R5]). There is no refinement
performed on security assurance requirements. The rational is the following: The EAL4 was
chosen to permit a developer to gain maximum assurance from positive security engineering
based on good commercial development practices which, though rigorous, do not require
substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at which
it is likely to be economically feasible to retrofit to an existing product line. EAL4 is applicable
in those circumstances where developers or users require a moderate to high level of
independently assured security in conventional commodity TOEs and are prepared to incur
sensitive security specific engineering costs. The selection of the component ALC_DVS.2
provides a higher assurance of the security of the MRTD's development and manufacturing
especially for the secure handling of the MRTD's material. The component ALC_DVS.2
augmented to EAL4 has no dependencies to other security requirements. The components
augmented to EAL4 are due to the EAL 5 level of the EAC security target.
6.3.4.1 ALC_DVS.2 Sufficiency of security measures
The selection of the component ALC_DVS.2 provides a higher assurance of the security of the
MRTD's development and manufacturing especially for the secure handling of the MRTD's
material. The component ALC_DVS.2 augmented to EAL4 has no dependencies to other
security requirements.
6.3.4.2 ADV_FSP.5 Complete semi-formal functional specification
with additional error information
The selection of the component ADV_FSP.5 provides a complete semiformal functional
specification of the TOE with additional error information. This component describes all direct
error messages that result from an invocation of an external interface of the TOE and all error
messages that does not result form an invocation of an external interface of the TOE.
6.3.4.3 ADV_INT.2 Well-structured internals
This component is a part of ADV_TDS.4 and chosen to provide to the developer a low-level
description of the design in detail in terms of the function they provide aiming to create an
implementation of the TSF from the description.
6.3.4.4 ADV_TDS.4 Semiformal modular design
The selection of the component ADV_TDS.4 provides a semiformal modular design of the TOE,
supported by informal and explanatory text.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 70/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
6.3.4.5 ALC_CMS.5 Development tools CM coverage
This component was chosen to provide a configuration list for the TOE, including the TOE
itself, the SARs, the implementation representation, security flaw reports and resolution status,
and the development tools and related information.
6.3.4.6 ALC_TAT.2 Compliance with implementation standards
This component was chosen to provide the documentation identifying each development tool
being used for the TOE, the selected implementation dependent options of each development
tool and the implementation standards that are being applied by the developer.
6.3.4.7 ATE_DPT.3 Testing: modular design
This component was chosen to demonstrate that all TSF modules in the design have been
tested.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 71/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
7 TOE Summary Specification
7.1 TOE Summary Specification
7.1.1 Chip security functionalities
TSF_DPM
The chip identification data (O.Identification) is stored in a in the not changeable
configuration page area and non-volatile memory. In the same area further TOE
configuration data is stored. In addition, user initialization data can be stored in
the non-volatile memory during the production phase as well. During the
production phase (phase 3 and 4) or after the delivery to the customer (phase
5 or phase 6), the TOE provides the possibility to download, after a successful
authentication process, a user specific encryption key and user code and data
into the empty (erased) Infineon® SOLID FLASH memory area as specified by
the associated control information of the Flash Loader software. The integrity of
the loaded data is checked with a signature process. The data to be loaded may
be transferred optionally in encrypted form. After finishing the load operation,
the Flash Loader can be permanently deactivated, so that no further load
operation with the Flash Loader is possible. During operation within a phase the
accesses to memories are granted by the MMU controlled access rights and
related privilege level. In addition, during each start-up of the TOE the address
ranges and access rights are initialized by the STS with predefined values.
During the testing phase in production within the secure environment the entire
Infineon® SOLID FLASH is deleted.
TSF_PS
All contents of all memories of the TOE are encrypted on chip to protect against
data analysis on stored data as well as on internally transmitted data. In addition
the data transferred over the busses, the SFRs and the peripheral devices (CRC,
RNG and Timer) are encrypted as well. The memory content and bus encryption
is done by the MED using a complex key management and by the memories
Infineon® SOLID FLASH, RAM, CACHE and the bus are entirely encrypted. Note
that the FLASH contains the firmware only and no user data. Therefore, no data
in plain are handled anywhere on the TOE and thus also the two CPUs compute
entirely masked. The symmetric cryptographic co-processor is entirely masked
as well. The user can define his own key for an Infineon® SOLID FLASH area to
protect his data. This user individually chosen key is then delivered by the
operating system and included in the dynamic Infineon® SOLID FLASH
encryption. The user specified Infineon® SOLID FLASH area is then encrypted
with his key and another component.
TSF_PMA
The TOE is equipped with an error detection code (EDC) which covers the
memory system of RAM, FLASH and Infineon® SOLID FLASH and includes also
the MED, MMU and the bus system. Thus introduced failures are detected and
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 72/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
in certain errors are also automatically corrected. In order to prevent accidental
bit faults during production in the FLASH, over the data stored in FLASH an EDC
value is calculated. If a user tears the card resulting in a power off situation
during an Infineon® SOLID FLASH programming operation or if other
perturbation is applied, no data or content loss occurs and the TOE restarts
power on.
TSF_PLA
The memory access control of the TOE uses a memory management unit (MMU)
to control the access to the available physical memory by using virtual memory
addresses and to segregate the code and data to a privilege level model. The
MMU controls the address permissions of the privileged levels and gives the
software the possibility to define different access rights. The address
permissions of the privilege levels are controlled by the MMU. In case of an
access violation the MMU will trigger a reset and then a trap service routine can
react on the access violation. The policy of setting up the MMU and specifying
the memory ranges, to a certain extend, for the privilege levels with the
exception of the IFX level - is defined from the user software (OS).
TSF_CS
The TOE is equipped with several hardware accelerators and software modules
to support the standard symmetric and asymmetric cryptographic operations.
This security function is introduced to include the cryptographic operation in the
scope of the evaluation as the cryptographic function respectively mathematic
algorithm itself is not used from the TOE security policy. On the other hand
these functions are of special interest for the use of the hardware as platform
for the software. The components are a co-processor supporting the DES and
AES algorithms and a combination of a co-processor and software modules to
support RSA cryptography, RSA key generation, ECDSA signature generation
and verification, ECDH key agreement and EC public key calculation and public
key testing.
7.1.2 Low level security functionalities
TSF_EXECUTION_ENVIRONMENT
This security functionality provides a secure execution environment based on
the secure operation of CPU that controls the execution flow, detects and reacts
to potential security violations. After start-up, this function calls
TSF_BOOT_AT_POWER_UP and waits for a terminal command.
7.1.3 Operating system security functionalities
TSF_MEMORY_MANAGEMENT
This security functionality manages the persistent and volatile memories of the
product according to the capacities of the underlying security IC, so as to control
access to sensitive content protected by the TOE. TSF_MEMORY_MANAGEMENT
manages the access to objects (files, directories, data and secrets) stored in
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 73/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
FLASH. Access for read or write to RAM and FLASH is impossible from the
outside, refer to TSF_IO_MANAGEMENT for more information.
Moreover, this security functionality uses TSF_CRYPTO_OPERATION to perform
cryptographic operations in order to verify the integrity.
TSF_BOOT_AT_POWER_UP
This security functionality manages the initialization of the TOE that happens
after each reset warm or cold. This security feature performs the following
operations:
Test of the following items:
FLASH memory segment
RAM memory
Random Number Generator
Crypto-processor
ATR issuing
Initialization of all modules and applications initialization.
TSF_LIFE_CYCLE_MANAGEMENT
This security functionality manages the life cycle of the product and provides a
secure transition mechanism between states. The various phases to be
recognized are pre-personalization, personalization, usage and end of life. The
management of the life cycle is performed by writing information in the One-
Time Programmable (OTP) memory. The life cycle of the product is composed
of 7 phases, more information is available in the dedicated paragraph 3.2 At the
end of the fabrication phase, after a test phase, chip test mode is inhibited in a
non-reversible way: the data (system or user) are completely under the control
of the card operating system. This is true for read, write or modify operations.
Tests done during fabrication phase can not be used anymore.
TSF_CPLC
This security functionality manages the CPLC area. The CPLC area contains
Manufacturing data, pre-personalization data and Personalization data.
Manufacturing data are written by the Manufacturer during the Manufacturing
phase and contain identification data such as founder ID, chip ID and operating
system ID. Pre-Personalization data are written by the Manufacturer and also
contains identification data such as the module ID. The CPLC area is a write-
only-once area and write access is subject to Manufacturer or Personalization
Agent authentication. Read access to the CPLC area is allowed during
Personalization phase. During Operational Use phase, the CPLC area read access
is only possible after BAC authentication.
TSF_MONITORING
This Security Functionality monitors all the events generated by the security IC
physical detectors:
Bad CPU usage
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 74/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
integrity loss in FLASH, OTP or RAM,
code signature alarm,
fault injection attempt,
watchdog timeout,
access attempt to unavailable or reserved memory areas,
MPU errors,
clock and voltage supply operating changes by the environment,
TOE physical integrity abuse.
Executable code integrity is controlled during its execution through the addition
of code redundancies and specific tests. Code consistency is then ensured.
TSF_IO_MANAGEMENT
This security functionality manages Input/Output interfaces by way of contact
and contactless. Two protocols are used to communicate:
T=0 protocol, asynchronous, character-oriented half-duplex transmission protocol
T=CL, specific to the contactless, asynchronous, block-oriented half-duplex
transmission protocol
A buffer is used for inputs and outputs. It is a reserved memory zone for the
communication. Other memories can not be accessed. During a cryp- tographic
operation, the access to this buffer is blocked, once the operation is finished,
the integrity of the buffer is verified by a CRC.
TSF_ALEA
This security functionality provides random numbers. The random number
generation is in conformance to the quality requirements of the french national
schemes:
A random number generator compliant with the French Scheme ANSSI requirements
for RNG
A random generator of n bytes.
The chip security functionality is compliant with the AIS31 standard. Conforming
to the French Scheme ANSSI requirement for RNG, post-treatment is effectued
on the RNG chip output, directly by the chip. The RNG chip output provided by
the chip s submitted to a posttreatment in order to provide a random number
of n bytes.
7.1.4 Application security functionalities
TSF_KEY_MANAGEMENT
This security functionality provides secure generation, destruction, replacement
and storage of cryptographic keys (KEY, PIN) according to the specification of
the product. Each secret is identified by a unique identifier and only manipulated
with the help of this identifier by the cryptographic module.
Each secret is associated to a ratification counter. The management of these
lasts is made by read/write control of the management of the maximum number
of attempts.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 75/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
TSF_BAC_AUTH
This security functionality manages the authentication of the Inspection system
to the TOE, based on the Document Basic Access Keys. TSF_BAC_AUTH
performs the Basic Access Control mechanism, as described in [R9], in order to
authenticate the Inspection System. TSF_BAC_AUTH calls
TSF_CRYPTO_OPERATION in order to perform the related cryptographic
operations.
TSF_SYM_AUTH
This security functionality manages the authentication of a user to the TOE,
based on the TDES or AES keys related to this user, during the personalization
phase. TSF_SYM_AUTH performs an authentication mechanism based on TDES
or AES. TSF_SYM_AUTH calls TSF_CRYPTO_OPERATION in order to perform the
related cryptographic operations.
TSF_CRYPTO_OPERATION
This security functionality performs high level cryptographic operations:
Encryption/decryption;
Integrity verification;
Secret decryption;
Authentication cryptogram creation/verification;
Key derivation;
Hash value calculation.
TSF_ACTIVE_AUTH
This security function manages the capability of the TOE to authenticate itself
to the terminal using the Active Authentication Protocol as defined in R9.
TSF_ACTIVE_AUTH calls TSF_CRYPTO_OPERATION in order to perform the
related cryptographic operations
7.2 SFRs and TSS
7.2.1 SFRs and TSS - Rationale
7.2.1.1 Security Functional Requirements
FCS_CKM.1 is met by TSF_CRYPTO_OPERATION, which performs, as described in
[R9], normative appendix 5 Document Basic Access Key Derivation Algorithm
to generate session keys of 112 bits. FCS_CKM.1 is also met by
TSF_KEY_MANAGEMENT, which ensures the protection of the keys during
generation.
FCS_CKM.4 is met by TSF_KEY_MANAGEMENT and by
TSF_MEMORY_MANAGEMENT, as TSF_KEY_MANAGEMENT manages the secure
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 76/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
destruction of secret by calling TSF_MEMORY_MANAGEMENT, and
TSF_MEMORY_MANAGEMENT manages E²PROM erasure.
FCS_COP.1/SHA is met by TSF_CS, TSF_CRYPTO_OPERATION, which performs
the SHA-1, SHA-224 and SHA-256 ,SHA 384 and SHA 512 algorithms in
conformance with [R16] to calculate a hash value, as required by
FCS_COP.1/SHA.
FCS_COP.1/ENC is met by TSF_CS, TSF_CRYPTO_OPERATION, which performs
TDES encryption and decryption, in conformance with FIPS 46-3 [R14]] and
[R9] normative appendix 5, A5.3, in order to achieve secure messaging -
confidentiality, as required by FCS_COP.1/ENC.
FCS_COP.1/AUTH is met by TSF_CS, TSF_CRYPTO_OPERATION and
TSF_SYM_AUTH, which performs symmetric authentication - encryption and
decryption, in order to achieve the authentication of the user during
personalization phase, as required by FCS_COP.1/AUTH.
FCS_COP.1/MAC is met by TSF_CS, TSF_CRYPTO_OPERATION, which performs
Retail MAC in conformance with ISO 9797 (MAC algorithm 3, block cipher DES,
Sequence Message Counter, padding mode 2) in order to achieve secure
messaging - integrity, as required by FCS_COP.1/MAC.
FIA_UID.1 is met by TSF_BOOT_AT_POWER_UP, which manage the initialization
of the communication with the card and by TSF_LIFE_CYCLE_MANAGEMENT,
which manages the card life cycle, and TSF_CPLC, which manages the CPLC
area where the initialization and pre-personalization data are stored.
FIA_UAU.1 is met by TSF_BOOT_AT_POWER_UP and
TSF_EXECUTION_ENVIRONMENT, which manage the initialization of the
communication with the card, by TSF_CPLC, which manages the area where the
initialization and pre-personalization data are stored and by TSF_BAC_AUTH and
TSF_SYM_AUTHwhich manage user authentication (and thus key selection).
FIA_UAU.4 is met TSF_BAC_AUTH and TSF_SYM_AUTH,
TSF_CRYPTO_OPERATION and TSF_ALEA which ensure that each authentication
of a user is performed using a random challenge, which prevents reuse of the
authentication data.
FIA_UAU.5 is met by TSF_BAC_AUTH, TSF_SYM_AUTH and
TSF_CRYPTO_OPERATION, which support all the authentication mechanisms
required by FIA_UAU.5, and by TSF_EXECUTION_ENVIRONMENT which ensures
that only commands consistent with the security state of the card are accepted.
FIA_UAU.6 is met by TSF_CRYPTO_OPERATION, which provide the re-
authentication mechanism by means of the secure messaging, and by
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 77/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
TSF_EXECUTION_ENVIRONMENT which ensures that only commands consistent
with the security state of the card are accepted.
FIA_AFL.1 is met by TSF_KEY_MANAGEMENT, which ensures, when a counter is
related to an authentication key, that the counter is incremented in case of
authentication failure, that the counter is reinitialized in case of authentication
success and that the authentication key is blocked in case of 32 successive
authentication attempts.
FIA_API.1/AAP is met by TSF_ACTIVE_AUTH, which supports TOE
authentication to the terminal using the Active Authentication Protocol as
defined in R9. FIA_API.1/AAP is met by TSF_CRYPTO_OPERATION which
supports the SFR by providing cryptographic features.
Class FDP User Data Protection
FDP_ACC.1 is met by TSF_PLA, TSF_IO_MANAGEMENT, which ensures that all
the access conditions, such as user authentication or secure messaging, are
fulfilled before authorizing access to an object, and by
TSF_EXECUTION_ENVIRONMENT, which verify that each received command
security status is consistent with the security status of the TOE.
FDP_ACF.1 is met by TSF_PLA, TSF_IO_MANAGEMENT, which ensures that all the
access conditions, such as user authentication or secure messaging, are fulfilled
before authorizing access to an object, and by
TSF_EXECUTION_ENVIRONMENT, which verify that each received command
security status is consistent with the security status of the TOE.
FDP_UCT.1 is met by TSF_BAC_AUTH and TSF_CRYPTO_OPERATION, which
ensures that a secure messaging in integrity and confidentiality is established
after BAC Authentication, therefore enabling to protect transmitted and received
data from disclosure and by TSF_EXECUTION_ENVIRONMENT, which verifies the
security status of the received command, and will therefore detect if secure
messaging is interrupted.
FDP_UIT.1 is met by TSF_BAC_AUTH and TSF_CRYPTO_OPERATION, which
ensures that a secure messaging in integrity and confidentiality is established
after BAC Authentication, therefore enabling to protect transmitted and received
data from modification and by TSF_EXECUTION_ENVIRONMENT, which verifies
the security status of the received command, and will therefore detects if secure
messaging is interrupted.
FMT_SMF.1 is met by TSF_LIFE_CYCLE_MANAGEMENT, which manages a life
cycle that includes a pre-personalization (initialization) and a personalization
phase, and by TSF_PLA, TSF_EXECUTION_ENVIRONMENT, which ensures that
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 78/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
only the AIP application is selectable in pre-personalization (initialization) and
personalization phases.
FMT_SMR.1 is met by TSF_BAC_AUTH and TSF_SYM_AUTH, which provide user
authentication mechanism and by TSF_KEY_MANAGEMENT, which manages the
identification number of the secret, therefore allowing the TOE to maintain
different user roles.
FMT_LIM.1 is met by TSF_PS, TSF_EXECUTION_ENVIRONMENT and
TSF_BOOT_AT_POWER_UP as those security functions provide test features of
the TOE after TOE delivery, which do not allow disclosure or unauthorized
manipulation of TSF data, user data, software or any other substantial
information.
FMT_LIM.2 is met by TSF_PS, TSF_EXECUTION_ENVIRONMENT and
TSF_BOOT_AT_POWER_UP as those security functions provide test features of
the TOE after TOE delivery, which do not allow disclosure or unauthorized
manipulation of TSF data, user data, software or any other substantial
information.
FMT_MTD.1/INI_ENA is met by TSF_CPLC, which manages the area where the
initialization and pre-personalization data are written.
FMT_MTD.1/INI_DIS is met by TSF_CPLC, which manages the area where
initialization and pre-personalization data are written and also ensures that no
access to those data is allowed during Operational Use phase before BAC
authentication, by TSF_LIFE_CYCLE_MANAGEMENT, which manages the area
where the life cycle phase is written, and by TSF_SYM_AUTH, which ensures
that the Personalization Agent is authenticated during the personalization
phase: when the Personalization Agent switches the card from Personalization
phase to Operational Use phase, he will disable free external access to the CPLC
area.
FMT_MTD.1/KEY_WRITE is met by TSF_IO_MANAGEMENT which ensures that
all the access conditions, such as user authentication, are fulfilled before
authorizing access to an object, and by TSF_SYM_AUTH, which ensures that the
personalization Agent is authenticated.
FMT_MTD.1/KEY_READ is met by TSF_IO_MANAGEMENT which ensures that all
the access conditions to an object, such as never for instance, are respected.
FMT_MTD.1/KEY_READ is also supported by TSF_KEY_MANAGEMENT which
ensures that operations on secret keys do not allow any read access to those
keys.
FPT_EMS.1 is met by TSF_PMA, TSF_EXECUTION_ENVIRONMENT which provides
interruption in order to avoid information leakage trough observation of
emanation. FPT_EMS.1 is also met by TSF_CRYPTO_OPERATION and
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 79/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
TSF_KEY_MANAGEMENT which ensure secure execution of cryptographic
operations on keys such as the Personalization Agent Authentication Key.
FPT_FLS.1 is met by TSF_DPM and TSF_MONITORING which ensure that a secure
state of the TOE (whether by reset or card termination) is maintained whenever
a default or an anomaly is detected. FPT_FLS.1 is also met by
TSF_EXECUTION_ENVIRONMENT which ensures the detection of a tampering
attempt, of a default or of an anomaly.
FPT_PHP.3 is met by TSF_EXECUTION_ENVIRONMENT, TSF_MONITORING,
TSF_DPM and TSF_PMA which monitor the TOE and react when a security event
is detected, therefore protecting the TOE from probing or physical manipulation.
FPT_TST.1 is met by TSF_BOOT_AT_POWER_UP which automatically performs
testing of critical elements of the TOE at power-up. FPT_TST.1 is also met by
TSF_EXECUTION_ENVIRONMENT which tests the integrity of accessed objects.
FAU_SAS.1 is met by TSF_LIFE_CYCLE_MANAGEMENT, which manages the write-
only-once OTP area where TOE parameters, such as the life phase, are written,
and by TSF_CPLC, which manages the write-only-once CPLC area where TOE
identification data are written.
FCS_RND.1 FCS_RND.1 is met by TSF_ALEA which generates random numbers
using a random number generator that complies with the AIS31 Class P2 quality
metric.
FCS_COP.1/AA_SIGN is met by TSF_CRYPTO_OPERATION which performs the
SHA-1, SHA-224 and SHA-256 , SHA 384 and SHA 512 algorithms in
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 80/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
conformance with [R16] to calculate a hash value, as required by
FCS_COP.1/SHA.
7.2.2 Association tables of SFRs and TSS
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 81/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Security Functional
Requirements
TOE Summary Specification
FCS_CKM.1 TSF_CRYPTO_OPERATION, TSF_KEY_MANAGEMENT
FCS_CKM.4 TSF_KEY_MANAGEMENT, TSF_MEMORY_MANAGEMENT
FCS_COP.1/SHA TSF_CRYPTO_OPERATION, TSF_CS
FCS_COP.1/ENC TSF_CRYPTO_OPERATION, TSF_CS
FCS_COP.1/AUTH TSF_SYM_AUTH, TSF_CRYPTO_OPERATION,
TSF_CS
FCS_COP.1/MAC TSF_CRYPTO_OPERATION, TSF_CS
FIA_UID.1 TSF_BOOT_AT_POWER_UP,
TSF_LIFE_CYCLE_MANAGEMENT, TSF_CPLC
FIA_UAU.1 TSF_EXECUTION_ENVIRONMENT,
TSF_BOOT_AT_POWER_UP, TSF_BAC_AUTH,
TSF_SYM_AUTH
FIA_UAU.4 TSF_BAC_AUTH, TSF_ALEA, TSF_SYM_AUTH,
TSF_CRYPTO_OPERATION
FIA_UAU.5 TSF_BAC_AUTH, TSF_SYM_AUTH,
TSF_CRYPTO_OPERATION,
TSF_EXECUTION_ENVIRONMENT
FIA_UAU.6 TSF_EXECUTION_ENVIRONMENT,
TSF_CRYPTO_OPERATION
FIA_AFL.1 TSF_KEY_MANAGEMENT
FIA_API.1/AAP
TSF_CRYPTO_OPERATION, TSF_ACTIVE_AUTH
FDP_ACC.1 TSF_IO_MANAGEMENT,
TSF_EXECUTION_ENVIRONMENT, TSF_PLA
FDP_ACF.1 TSF_EXECUTION_ENVIRONMENT,
TSF_IO_MANAGEMENT, TSF_PLA
FDP_UCT.1 TSF_EXECUTION_ENVIRONMENT, TSF_BAC_AUTH,
TSF_CRYPTO_OPERATION
FDP_UIT.1 TSF_CRYPTO_OPERATION, TSF_BAC_AUTH,
TSF_EXECUTION_ENVIRONMENT
FMT_SMF.1 TSF_EXECUTION_ENVIRONMENT,
TSF_LIFE_CYCLE_MANAGEMENT, TSF_PLA
FMT_SMR.1 TSF_BAC_AUTH, TSF_SYM_AUTH,
TSF_KEY_MANAGEMENT
FMT_LIM.1 TSF_EXECUTION_ENVIRONMENT,
TSF_BOOT_AT_POWER_UP, TSF_PS
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 82/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Security Functional
Requirements
TOE Summary Specification
FMT_LIM.2 TSF_EXECUTION_ENVIRONMENT,
TSF_BOOT_AT_POWER_UP
FMT_MTD.1/INI_ENA TSF_CPLC
FMT_MTD.1/INI_DIS TSF_CPLC, TSF_LIFE_CYCLE_MANAGEMENT,
TSF_SYM_AUTH
FMT_MTD.1/KEY_WRITE TSF_IO_MANAGEMENT, TSF_SYM_AUTH
FMT_MTD.1/KEY_READ TSF_MEMORY_MANAGEMENT
FPT_EMS.1 TSF_EXECUTION_ENVIRONMENT,
TSF_KEY_MANAGEMENT, TSF_CRYPTO_OPERATION,
TSF_PMA
FPT_FLS.1 TSF_EXECUTION_ENVIRONMENT,
TSF_MONITORING, TSF_DPM
FPT_PHP.3 TSF_EXECUTION_ENVIRONMENT,
TSF_MONITORING, TSF_PMA, TSF_DPM
FPT_TST.1 TSF_BOOT_AT_POWER_UP,
TSF_EXECUTION_ENVIRONMENT
FAU_SAS.1 TSF_LIFE_CYCLE_MANAGEMENT, TSF_CPLC
FCS_RND.1 TSF_ALEA
FCS_COP.1/AA_SIGN TSF_CRYPTO_OPERATION
Table 11 - SFRs and TSS - Coverage
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 83/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
8 Statement of compatibility
The statement of compatibility address the specific requirements for composite
evaluation as stated in the document “Composite product evaluation for Smartcards
and similar devices” [R12]. The rational explaining how these specific requirements
are addressed is presented in the same logical order than the work item stated in
[R12].
8.1 Separation of the Platform-TSF
This section describes the separation of relevant security functionality described in the ST of the
Infineon Technologies M7892 B11 platform with specific IC dedicated software and optional
RSAv1.02.013, EC v1.02.013, SHA-2 v1.01 and Toolbox v1.02.013 libraries being used by this
ST. The security functionality provided by the IC platform is summarized in [R8], chapter 7. The
following table lists the relevant security functionality of the platform regarding cryptography with
regards to those of the composite TOE defined in the present ST.
Platform functionality Usage by the composite TOE
Device Phase
Management
This functionality is automatically triggered at start’up. The
composite TOE takes over with its functionality TSF_CPLC.
Protection against
Logical Attacks
This functionality is directly identified by the composite TOE
through its security functionalities TSF_BAC_AUTH,
TSF_SYM_AUTH, TSF_ACTIVE_AUTH
Protection against
Snooping
This functionality is used by the composite TOE functionality
TSF_KEY_MANAGEMENT, as a hardware underlying
mechanism.
Protection against
Modifying Attacks
This functionality is directly identified by the composite TOE
through its functionalities TSF_EXECUTION_ENVIRONMENT
and TSF_MONITORING
Cryptographic Support The TDES functionality is directly identified by the composite TOE
through its functionality TSF_CS which is used by
TSF_CRYPTO_OPERATION. The SHA functionality is directly
identified by the composite TOE through its functionality TSF_CS
which is used by TSF_CRYPTO_OPERATION.
The TRNG functionality is directly identified by the composite TOE
through its functionality TSF_CS and used by
TSF_CRYPTO_OPERATION.
The AES functionality is not used. RSA and Elliptic Curve
functionalities are not used.
Table 1: Coverage of IC platform functionality
In the following table the SFRs of the IC platform are designated as “relevant” or “used
by this composite ST”. The table also lists explicitly irrelevant Platform-SFRs not being
used by the Composite-ST.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 84/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Platform SFRs Usage by TOE, TOE-SFR
FRU_FLT.2 Internal IC mechanism. Supporting TSF_PMA
FPT_FLS.1 TSF_PS, TSF_PMA, TSF_PLA, TSF_CS
FMT_LIM.1 TSF_DPM
FMT_LIM.2 TSF_DPM
FAU_SAS.1 TSF_DPM, , TSF_CPLC ,FAU_SAS.1
FPT_PHP.3 TSF_DPM, TSF_PS, TSF_PMA, TSF_PLA, TSF_CS, TSF_PHY
/ FPT_PHP.3
FDP_ITT.1 Internal IC mechanism. Supporting TSF_DPM, TSF_PS,
TSF_PMA, TSF_PLA, TSF_CS, TSF_CRYPTO_OPERATION
FPT_ITT.1 Internal IC mechanism. Supporting TSF_DPM, TSF_PS,
TSF_PMA, TSF_CRYPTO_OPERATION
FDP_IFC.1 Internal IC mechanism. Supporting
TSF_PS, TSF_PMA, TSF_PLA, TSF_CRYPTO_OPERATION
FCS_RNG.1 TSF_ALEAS / FCS_RND.1
FPT_TST.2 TSF_PMA, TSF_CS
FDP_ACC.1 TSF_DPM, TSF_PMA, TSF_PLA, FDP_ACC.1
FDP_ACF.1 TSF_DPM, TSF_PMA, TSF_PLA, FDP_ACF.1
FMT_SMF.1 TSF_DPM, TSF_PMA, TSF_PLA,, FMT_SMF.1
FCS_COP.1 TSF_CS
FCS_CKM.1 Irrelevant. Unused for TOE SFRs
FDP_SDI.1 TSF_PMA
FDP_SDI.2 TSF_PMA
FMT_MSA.3 Irrelevant. Unused for TOE SFRs.
FMT_MSA.1 Irrelevant. Unused for TOE SFRs.
Table 2: Coverage of IC platform SFRs
8.2 Statement of compatibility for the security assurance
requirements
This statement of compatibility address the requirement specified in [R12] for the
security assurance requirements.
The security requirement for the underlying IC M7892 B11 specified in its security
target [R8] is EAL6 augmented with the following component: ALC_FLR.1 where the
security assurance requirement for the composite TOE is EAL4+ augmented with the
following components:
 ADV_FSP.5,
 ADV_INT.2,
 ADV_TDS.4,
 ALC_CMS.5,
 ALC_DVS.2,
 ALC_TAT.2,
 ATE_DPT.3
.
Therefore, the security assurance requirements for the composite TOE represent a
subset of the security assurance requirements of the underlying platform.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 85/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
8.3 Statement of compatibility for the security
environment and the objectives
8.3.1 Objectives
There is no conflict between security objectives of the Composite Security Target and
the IC Security Target. All IC platform objectives are relevant, even if some of them
are partially used (O.Add-Functions and O.Mem-Access).
Objectives for the IC Objectives for the composite
TOE
Remarks
O.Leak-Inherent OT.Prot_Inf_Leak Objective covering also
O.Leak-Forced
O.Phys-Probing OT.Prot_Phys-Tamper Objective covering also
O.Phys-Manipulation
O.Malfunction OT.Prot_Malfunction Full coverage
O.Phys-Manipulation OT.Prot_Phys-Tamper Objective covering also
O.Phys-Probing
O.Leak-Forced OT.Prot_Inf_Leak Objective covering also
O.Leak-Inherent
O.Abuse-Func OT.Prot_Abuse-Func Full coverage
O.Identification OT.Identification Full coverage
O.RND No equivalent as the final
composite TOE does not aim to
offer random number generation,
but to use the one offered by the
IC
O.Add-Functions No equivalent as the final
composite TOE does not aim to
offer cryptographic services, but to
use the ones offered by the IC
O.Add-Functions
contributes to :
OT_Data_Conf
O.Mem Access No equivalent as the final
composite TOE uses the hardware
functionality for a final purpose :
enforce the Extended Access
Control specified through :
OT.Sens_Data_Conf.
O.Mem-Access contributes
to OT.Data_Conf and
OT.AC_Pers
OE.Plat-Appl Covered through ADV. Not
an objective on the
operational environment
OE.Resp-Appl Covered through
ADV/ALC/ATE/AVA. Not an
objective on the operational
environment
OE.Process-Sec-IC OE.MRTD_Manufact,
OE.MRTD_ Delivery
Full coverage
Table 3: Coverage of IC platform objectives
Note that all additional objectives on the environment for the composite TOE are for
the operational environment, and do not contradict the IC objectives.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 86/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
8.3.2 Threats
There is no conflict between threats of the Composite Security Target and the IC
Security Target.
Threats for the IC Threats for the composite TOE Remarks
T.Leak-Inherent T.Information_Leakage Threats also including
T.Leak-Forced
T.Phys-Probing T.Phys-Tamper Threats also including
T.Phys-Manipulation
T.Malfunction T.Malfunction Full match
T.Phys-Manipulation T.Phys-Tamper Threats also including
T.Phys-Probing
T.Leak-Forced T.Information_Leakage Threats also including
T.Leak-Inherent
T.Abuse-Func T.Abuse-Func Full match
T.RND No equivalent as this threats is
already covered by the IC internal
mechanism (O.RND and
FCS_RNG.1)
T.Mem-Access T.Skimming, T.Forgery The two identified threats
for the composite TOE
address a more specific
risk, however, the main
principle remain the same.
Table 4: Coverage of threats
8.3.3 Organisational security policies
There is no conflict between OSPs of the Composite Security Target and the IC Security
Target.
OSPs for the IC OSPs for the composite TOE Remarks
P.Process-TOE No equivalent but this OSP covers
the development and
manufacturing environment
(covered by ALC class)
P.Add-Functions As for O.Add-Functions, there is no
equivalent as the final composite
TOE does not aim to offer
cryptographic services, but to use
the ones offered by the IC
contributes to :
OT.Data_Conf
Table 5: Coverage of OSPs
The P.Add-functions introduces the IC cryptographic services to be used by the
embedded software. There is no contradiction with the threats or objectives for the
composite TOE.
8.3.4 Assumptions
There is no conflict between assumption of the Composite Security Target and the IC
Security Target.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 87/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Assumption for
the IC
Assumptions/Objectives/SAR for the
composite TOE
Remarks
A.Process-Sec-IC A.MRTD_Manufact
A.MRTD_Delivery
A.Pers_Agent
This assumptions is
significant for the composite
TOE
A.Plat-Appl Covered through assurance class ADV.
Not an assumption on the operational
environment
assumptions not significant
for the composite TOE
A.Resp-Appl Covered through assurance class
ADV/ALC/ATE/AVA. Not an assumption
on the operational environment
assumptions not significant
for the composite TOE
A.Key-Function OE.Plat-Appl
OE.Resp-Appl
Table 6: Coverage of assumptions
There is only one significant assumption for the composite TOE that is fully addressed
by the current composite security target.
Note that all additional assumptions for the composite TOE are for the operational
environment, and do not contradict the IC threats.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 88/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
9 Definitions, Glossary and acronyms
9.1 Acronyms
BIS Basic Inspection System
CC Common Criteria
EAL Evaluation Assurance Level
EFElementary File
EIS Extended Inspection System
GIS General Inspection System
IAS Identité Authentification Signature
ICAO International Civil Aviation Organization
ICCSN Integrated Circuit Card Serial Number
IT Information Technology
JCRE Java Card Runtime Environment
JVM Java Virtual Machine
MF Master File
MRTD Machine Readable Travel Document
n.a. Not applicable
OSP Organizational security policy
PPProtection Profile
RAD Reference Authentication Data
RNG Random Number Generator
SAR Security assurance requirements
SDO Signed Data Object
SFP Security Function Policy
SFR Security functional requirement
ST Security Target
TOE Target of Evaluation
TSF TOE Security Functions
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 89/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
TSP TOE Security Policy
VAD Verification Authentication Data
VGP Visa Global Platform
9.2 Conventions used
The following list shows the roots used for the various elements.
Root Elements described by this root
T. Threats relative to the TOE and the TOE operational environment
OSP. Organisational security policy
A. Assumption
OT. Security objectives for the TOE
OE. Security objectives for the operational environment
9.3 Definitions
Active Authentication
Security mechanism defined in [5] option by which means the MRTD’s chip proves and
the inspection system verifies the identity and authenticity of the MRTD’s chip as part
of a genuine MRTD issued by a known State of Organization.
Application note
Optional informative part of the PP containing sensitive supporting information that is
considered relevant or useful for the construction, evaluation, or use of the TOE.
Audit records
Write-only-once non-volatile memory area of the MRTDs chip to store the Initialization
Data and Pre-personalization Data.
Authenticity
Ability to confirm the MRTD and its data elements on the MRTD’s chip were created
by the issuing State or Organization.
Basic Access Control (BAC)
Security mechanism defined in [R9]] by which means the MRTD’s chip proves and the
inspection system protects their communication by means of secure messaging with
Document Basic Access Keys (see there).
Basic Inspection System (BIS)
An inspection system which implements the terminals part of the Basic Access Control
Mechanism and authenticates itself to the MRTD’s chip using the Document Basic
Access Keys derived from the printed MRZ data for reading the logical MRTD.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 90/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Biographical data (biodata)
The personalized details of the MRTD holder appearing as text in the visual and
machine readable zones on the biographical data page of a passport book or on a
travel card or visa. [R9].
Biometric reference data
Data stored for biometric authentication of the MRTD holder in the MRTD’s chip as (i)
digital portrait and (ii) optional biometric reference data.
Certificate chain
Hierarchical sequence of Inspection System Certificate (lowest level), Document
Verifier Certificate and Country Verifying Certification Authority Certificates (highest
level), where the certificate of a lower lever is signed with the private key
corresponding to the public key in the certificate of the next higher level. The Country
Verifying Certification Authority Certificate is signed with the private key
corresponding to the public key it contains (selfsigned certificate).
Chip
An integrated circuit and its embedded software as it come out of the IC manufacturing
step.
Counterfeit
An unauthorized copy or reproduction of a genuine security document made by
whatever means. [R9]
Country Signing CA Certificate (CCSCA)
Certificate of the Country Signing Certification Authority Public Key (KPuCSCA) issued by
Country Signing Certification Authority stored in the inspection system.
Country Verifying Certification Authority
The country specific root of the PKI of Inspection Systems and creates the Document
Verifier Certificates within this PKI. It enforces the Privacy policy of the issuing State
or Organization in respect to the protection of sensitive biometric reference data stored
in the MRTD.
Current date
The maximum of the effective dates of valid CVCA, DV and domestic Inspection
System certificates known to the TOE. It is used the validate card verifiable
certificates.
CVCA link Certificate
Certificate of the new public key of the Country Verifying Certification Authority signed
with the old public key of the Country Verifying Certification Authority where the
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 91/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
certificate effective date for the new key is before the certificate expiration date of the
certificate for the old key.
Document Basic Access Key Derivation Algorithm
The [R9], normative appendix 5, A5.1 describes the Document Basic Access Key
Derivation Algorithm on how terminals may derive the Document Basic Access Keys
from the second line of the printed MRZ data.
Document Basic Access Keys
Pair of symmetric (two-key) Triple-DES keys used for secure messaging with
encryption (key KENC) and message authentication (key KMAC) of data transmitted
between the MRTD’s chip and the inspection system [R9]. It is drawn from the printed
MRZ of the passport book to authenticate an entity able to read the printed MRZ of
the passport book.
Document Security Object (SOD)
A RFC3369 CMS Signed Data Structure, signed by the Document Signer (DS). Carries
the hash values of the LDS Data Groups. It is stored in the MRTD’s chip. It may carry
the Document Signer Certificate (CDS). [R9]
Document Verifier
Certification authority creating the Inspection System Certificates and managing the
authorization of the Extended Inspection Systems for the sensitive data of the MRTD
in the limits provided by the issuing States or Organizations.
Eavesdropper
A threat agent with Enhanced-Basic attack potential reading the communication
between the MRTD’s chip and the inspection system to gain the data on the MRTD’s
chip.
Enrolment
The process of collecting biometric samples from a person and the subsequent
preparation and storage of biometric reference templates representing that person's
identity. [R9]
Extended Access Control
Security mechanism identified in [R9] by which means the MRTD’s chip (i) verifies the
authentication of the inspection systems authorized to read the optional biometric
reference data, (ii) controls the access to the optional biometric reference data and
(iii) protects the confidentiality and integrity of the optional biometric reference data
during their transmission to the inspection system by secure messaging. The
Personalization Agent may use the same mechanism to authenticate themselves with
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 92/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Personalization Agent Authentication Private Key and to get write and read access to
the logical MRTD and TSF data.
Extended Inspection System
A General Inspection System which (i) implements the Chip Authentication
Mechanism, (ii) implements the Terminal Authentication Protocol and (iii) is authorized
by the issuing State or Organization through the Document Verifier of the receiving
State to read the sensitive biometric reference data.
Extended Inspection System (EIS)
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.
Forgery
Fraudulent alteration of any part of the genuine document, e.g. changes to the
biographical data or the portrait. [R9]
General Inspection System
A Basic Inspection System which implements sensitively the Chip Authentication
Mechanism.
Global Interoperability
The capability of inspection systems (either manual or automated) in different States
throughout the world to exchange data, to process data received from systems in
other States, and to utilize that data in inspection operations in their respective States.
Global interoperability is a major objective of the standardized specifications for
placement of both eye-readable and machine readable data in all MRTDs. [R9]
IC Dedicated Support Software
That part of the IC Dedicated Software (refer to above) which provides functions after
TOE Delivery. The usage of parts of the IC Dedicated Software might be restricted to
certain phases.
IC Dedicated Test Software
That part of the IC Dedicated Software (refer to above) which is used to test the TOE
before TOE Delivery but which does not provide any functionality thereafter.
Initialisation Data
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 93/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Any data defined by the TOE Manufacturer and injected into the non-volatile memory
by the Integrated Circuits manufacturer (Phase 2). These data are for instance used
for traceability and for IC identification as MRTD’s material (IC identification data).
Inspection
The act of a State examining an MRTD presented to it by a traveler (the MRTD holder)
and verifying its authenticity. [R9]
Inspection system (IS)
A technical system used by the border control officer of the receiving State (i)
examining an MRTD presented by the traveler and verifying its authenticity and (ii)
verifying the traveler as MRTD holder.
Integrated circuit (IC)
Electronic component(s) designed to perform processing and/or memory functions.
The MRTD’s chip is built on an integrated circuit.
Integrity
Ability to confirm the MRTD and its data elements on the MRTD’s chip have not been
altered from that created by the issuing State or Organization.
Issuing Organization
Organization authorized to issue an official travel document (e.g. the United Nations
Organization, issuer of the Laissez-passer). [R9]
Issuing State
The Country issuing the MRTD. [R9]
Logical Data Structure (LDS)
The collection of groupings of Data Elements stored in the optional capacity expansion
technology [R9]. The capacity expansion technology used is the MRTD’s chip.
Logical MRTD
Data of the MRTD holder stored according to the Logical Data Structure [R9] as
specified by ICAO on the MRTD’s chip. It presents readable data including (but not
limited to)
(1) personal data of the MRTD holder
(2) the digital Machine Readable Zone Data (digital MRZ data, EF.DG1),
(3) the digitized portraits (EF.DG2),
(4) the biometric reference data of finger(s) (EF.DG3) or iris image(s) (EF.DG4) or
both and
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 94/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
(5) the other data according to LDS (EF.DG5 to EF.DG16).
(6) EF.COM and EF.SOD
Logical travel document
Data stored according to the Logical Data Structure as specified by ICAO in the
integrated circuit including (but not limited to)
(1) data contained in the machine-readable zone (mandatory),
(2) digitized photographic image (mandatory) and
(3) fingerprint image(s) and/or iris image(s) (optional).
Machine readable travel document (MRTD)
Official document issued by a State or Organization which is used by the holder for
international travel (e.g. passport, visa, official document of identity) and which
contains mandatory visual (eye readable) data and a separate mandatory data
summary, intended for global use, reflecting essential data elements capable of being
machine read. [R9]
Machine readable zone (MRZ)
Fixed dimensional area located on the front of the MRTD or MRP Data Page or, in the
case of the TD1, the back of the MRTD, containing mandatory and optional data for
machine reading using OCR methods. [R9]
MRTD application
Non-executable data defining the functionality of the operating system on the IC as
the MRTD’s chip. It includes
 the file structure implementing the LDS [R9]
 the definition of the User Data, but does not include the User Data itself (i.e. content of EF.DG1
to EF.DG13 and EF.DG16, EF.COM and EF.SOD) and
 the TSF Data including the definition the authentication data but except
 the authentication data itself.
MRTD Basic Access Control
Mutual authentication protocol followed by secure messaging between the inspection
system and the MRTD’s chip based on MRZ information as key seed and access
condition to data stored on MRTD’s chip according to LDS.
MRTD holder
The rightful holder of the MRTD for whom the issuing State or Organization
personalized the MRTD.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 95/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
MRTD’s Chip
A chip programmed according to the Logical Data Structure as specified by [R9] and
ready for personalisation.
MRTD’s chip Embedded Software
Software embedded in a MRTD’s chip and not being developed by the IC Designer.
The MRTD’s chip Embedded Software is designed in Step 1 and embedded into the
MRTD’s chip in Step 3 of the TOE life-cycle.
Optional biometric reference data
Data stored for biometric authentication of the MRTD holder in the MRTD’s chip as (i)
encoded finger image(s) (EF.DG3) or (ii) encoded iris image(s) (EF.DG4) or (iii) both.
Note, that the European commission decided to use only fingerprint and not to use iris
images as optional biometric reference data.
Passive authentication
(i) verification of the digital signature of the Document Security Object and
(ii) comparing the hash values of the read LDS data fields with the hash values
contained in the Document Security Object.
Personalization
The process by which the portrait, signature and biographical data are applied to the
document. This may also include the optional biometric data collected during the
“Enrolment”. [R9]
Personalization Agent
The agent acting on the behalf of the issuing State or Organization to personalize the
MRTD for the holder by (i) establishing the identity the holder for the biographic data
in the MRTD, (ii) enrolling the biometric reference data of the MRTD holder i.e. the
portrait, the encoded finger image(s) or (ii) the encoded iris image(s) and (iii) writing
these data on the physical and logical MRTD for the holder.
Personalization Agent Authentication Information
TSF data used for authentication proof and verification of the Personalization Agent.
Personalization Agent Authentication Key
Symmetric cryptographic key used (i) by the Personalization Agent to prove their
identity and get access to the logical MRTD and (ii) by the MRTD’s chip to verify the
authentication attempt of a terminal as Personalization Agent.
Physical travel document
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 96/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Travel document in form of paper, plastic and chip using secure printing to present
data including (but not limited to)
(1) biographical data,
(2) data of the machine-readable zone,
(3) photographic image and
(4) other data.
Pre-personalization Data
Any data that is injected into the non-volatile memory of the TOE by the MRTD
Manufacturer (Phase 2) for traceability of non-personalized MRTD’s and/or to secure
shipment within or between life cycle phases 2 and 3. It contains (but is not limited
to) the Active Authentication Key Pair and the Personalization Agent Key Pair.
Pre-personalized MRTD’s chip
MRTD’s chip equipped with a unique identifier and a unique asymmetric Active
Authentication Key Pair of the chip.
Receiving State
The Country to which the Traveler is applying for entry. [R9]
Reference data
Data enrolled for a known identity and used by the verifier to check the verification
data provided by an entity to prove this identity in an authentication attempt.
Secure messaging in encrypted mode
Secure messaging using encryption and message authentication code according to
ISO/IEC 7816-4.
Skimming
Imitation of the inspection system to read the logical MRTD or parts of it via the
contactless communication channel of the TOE without knowledge of the printed MRZ
data.
Security Target (ST)
Reference document for the TOE evaluation: the certificate awarded by the DCSSI will
attest conformity of the product and its documentation with the (functional and
assurance) requirements formulated in the security target.
Target of Evaluation (TOE)
The product to be evaluated and its associated documentation.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 97/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Terminal Authorization
Intersection of the Certificate Holder Authorizations defined by the Inspection System
Certificate, the Document Verifier Certificate and Country Verifying Certification
Authority which shall be all valid for the Current Date.
TOE Security Functionality (TSF)
A set consisting of all hardware, software and firmware of the TOE that must be relied
upon for the correct enforcement of the TSP.
TOE Security Policy (TSP)
Set of rules stipulating how to manage, protect and distribute assets within a TOE.
Travel document
A passport or other official document of identity issued by a State or Organization
which may be used by the rightful holder for international travel. [R9]
Traveler
Person presenting the MRTD to the inspection system and claiming the identity of the
MRTD holder.
TSF data
Data created by and for the TOE that might affect the operation of the TOE (CC part
1 [R1]).
Unpersonalized MRTD
The MRTD that contains the MRTD Chip holding only Initialization Data and Pre-
personalization Data as delivered to the Personalisation Agent from the Manufacturer.
User data
Data created by and for the user that does not affect the operation of the TSF (CC
part 1 [R1]).
Verification
The process of comparing a submitted biometric sample against the biometric
reference template of a single enrollee whose identity is being claimed, to determine
whether it matches the enrollee’s template. [R9]
Verification data
Data provided by an entity in an authentication attempt to prove their identity to the
verifier. The verifier checks whether the verification data match the reference data
known for the claimed identity.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 98/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
10 Reference and applicable documents
10.1 Reference Documents
Designation Reference Title Revision Date
Common Criteria
[R1] CCMB-2006-09-001 Common Criteria for Information
Technology Security Evaluation, Part 1:
Introduction and general model
Version
3.1,
Revision
4
September
2012
[R2] CCMB-2007-09-002 Common Criteria for Information
Technology Security Evaluation, Part 2:
Security Functional Components
Version
3.1,
Revision
4
September
2012
[R3] CCMB-2007-09-003 Common Criteria for Information
Technology Security Evaluation, Part 3:
Security Assurance Components
Version
3.1,
Revision
4
September
2012
[R4] CCMB-2007-09-004 Common Methodology for Information
Technology Security Evaluation,
Evaluation Methodology
Version
3.1,
Revision
4
September
2012
Protection Profiles and Security Target
[R5] BSI-CC-PP-0055 Common Criteria Protection Profile -
Machine Readable Travel Document
with “ICAO Application", Basic Access
Control
Version
1.10
March 2009
[R6] BSI-CC-PP-0056 Common Criteria Protection Profile -
Machine Readable Travel Document
with “ICAO Application", Extended Access
Control
Version
1.10
March 2009
[R7] BSI-PP-0035-2007 Protection Profile, Security IC Platform
Protection Profile. Certified by BSI
(Bundesamt für Sicherheit in der
Informationstechnik).
Version
1.0
June 2007
[R8] INFINEON-ST-CHIP-B11-
2015-10-13
BSI-DSZ-CC-0782-V2-
2015
Security Target (ST) M7892 B11
BSI, Certification Report, BSI-DSZ-CC-
0782-V2-2015, Infineon Security
Controller M7892 B11 withoptional
RSA2048/4096 v1.02.013, EC
v1.02.013,SHA-2 v1.01 and Toolbox
v1.02.013 libraries andwith specific IC
dedicated software (firmware) from
Infineon Technologies AG
Rev 0.3 2015-10-13
2015-11-03
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 99/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Designation Reference Title Revision Date
E-passport specifications
[R9] ICAO Doc 9303 part 1 volume 1, Sixth edition, 2006,
Passports with Machine Readable Data
Stored in Optical Character Recognition
Format;
part 1 volume 2, Sixth edition, 2006,
Specifications for Electronically Enabled
Passports with Biometric Identification
Capability.
Sixth
edition
2006
[R10] TR-03110 Technical Guideline Advanced Security
Mechanisms for Machine Readable
Travel Documents – Extended Access
Control (EAC)
Version
2.10
CC supporting document
[R11] CCDB-2008-04-001 Supporting Document - Mandatory
Technical Document - Application of
Attack Potential to Smartcards
V2.5, R1 April 2008
[R12] CCDB-2007-09-001 Supporting Document - Mandatory
Technical Document - Composite product
evaluation for Smartcards and similar
devices
V1.0, R1 September
2007
10.2 Applicable Documents
Designation Reference Title Revision Date
Cryptography
[R13] Technical Guideline :Elliptic Curve
Cryptography according to ISO 15946.TR-
ECC, BSI
2006
[R14] FIPS PUB 46-3 Federal Information Processing Standards
Publication FIPS PUB 46-3, Data
Encryption Standards (DES), U.S.
Department Of Commerce / National
Institute of Standards and Technology.
Reaffirmed
1999 October
25
[R15] ANSI X9.31 American Bankers Association, Digital
Signatures Using Reversible Public Key
Cryptography for the Financial Services
Industry (rDSA), ANSI X9.31-1998 -
Appendix A.2.4
1998
[R16] Federal Information Processing Standards
Publication 180-2 SECURE HASH
STANDARD (+ Change Notice to include
SHA-224), U.S. DEPARTMENT OF
COMMERCE/National Institute of
Standards and Technology
2002 August
1
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 100/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 101/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
Index
A
A.BAC-Keys........................................................ 26
A.Insp_Sys........................................................... 26
A.MRTD_Delivery .............................................. 25
A.MRTD_Manufact............................................. 25
A.Pers_Agent....................................................... 25
Attacker................................................................ 21
Authenticity__of__the__MRTD's__chip............. 20
F
FAU_SAS.1 ......................................................... 56
FCS_CKM.1 ........................................................ 45
FCS_CKM.4 ........................................................ 45
FCS_COP.1/AUTH.............................................. 46
FCS_COP.1/ENC................................................. 46
FCS_COP.1/MAC ............................................... 46
FCS_COP.1/SHA................................................. 45
FCS_RND.1......................................................... 56
FDP_ACC.1................................................... 50, 57
FDP_ACF.1 ......................................................... 50
FDP_UCT.1 ......................................................... 51
FDP_UIT.1........................................................... 51
FIA_AFL.1........................................................... 50
FIA_UAU.1 ......................................................... 47
FIA_UAU.4 ......................................................... 48
FIA_UAU.5 ......................................................... 48
FIA_UAU.6 ......................................................... 49
FIA_UID.1........................................................... 47
FMT_LIM.1......................................................... 52
FMT_LIM.2......................................................... 53
FMT_MTD.1/INI_DIS ........................................ 53
FMT_MTD.1/INI_ENA....................................... 53
FMT_MTD.1/KEY_READ ................................. 54
FMT_MTD.1/KEY_WRITE................................ 54
FMT_SMF.1 ........................................................ 52
FMT_SMR.1........................................................ 52
FPT_EMS.1 ......................................................... 55
FPT_FLS.1........................................................... 55
FPT_PHP.3 .......................................................... 55
FPT_TST.1........................................................... 55
I
Inspection__system__(IS).................................... 21
M
Manufacturer........................................................ 20
MRTD__Holder................................................... 21
O
OE.BAC-Keys ..................................................... 31
OE.Exam_MRTD ................................................ 31
OE.MRTD___Delivery........................................ 30
OE.MRTD_Manufact .......................................... 30
OE.Pass_Auth_Sign............................................. 31
OE.Passive_Auth_Verif....................................... 31
OE.Personalization............................................... 30
OE.Prot_Logical_MRTD..................................... 32
OT.__Data_Conf.................................................. 27
OT.AC_Pers......................................................... 27
OT.Chip_Auth_Proof..................................... 30, 35
OT.Data_Int ......................................................... 27
OT.Identification.................................................. 28
OT.Prot_Abuse-Func........................................... 28
OT.Prot_Inf_Leak................................................ 29
OT.Prot_Malfunction........................................... 29
OT.Prot_Phys-Tamper......................................... 29
P
P.Manufact........................................................... 24
P.Personal_Data................................................... 25
P.Personalization.................................................. 24
Personalization__Agent ....................................... 20
T
T.__Eavesdropping .............................................. 22
T.Abuse-Func ...................................................... 23
T.Chip_ID............................................................ 22
T.Forgery ............................................................. 22
T.Information_Leakage ....................................... 23
T.Malfunction ...................................................... 24
T.Phys-Tamper .................................................... 23
T.Skimming ......................................................... 22
Terminal............................................................... 21
Traveler................................................................ 21
TSF_ACTIVE_AUTH................................... 76, 82
TSF_ALEA.......................................................... 75
TSF_BAC_AUTH ............................................... 76
TSF_BOOT_AT_POWER_UP ........................... 74
TSF_CPLC........................................................... 74
TSF_CRYPTO_OPERATION ............................ 76
TSF_CS................................................................ 73
TSF_DPM............................................................ 72
TSF_EXECUTION_ENVIRONMENT............... 73
TSF_IO_MANAGEMENT.................................. 75
TSF_KEY_MANAGEMENT.............................. 75
TSF_LIFE_CYCLE_MANAGEMENT .............. 74
TSF_MEMORY_MANAGEMENT.................... 73
Security target Lite for
IDealPass v2.0.1 BAC Application
Ref.: 2016_2000023039
Page: 102/102
This document and the information it contains is the property of Safran Identity & Security. It may not be used, reproduced or
transmitted to a third party without prior written approval.
TSF_MONITORING........................................... 74
TSF_PLA............................................................. 73
TSF_PMA............................................................ 72
TSF_PS................................................................ 72
TSF_TDES_AUTH.............................................. 76