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
MICAO 1.1.3 ON IDEALCITIZTM
OS 2.1
SAC/EAC CONFIGURATION
Reference: 2016_2000022974
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 2/119
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.
DOCUMENT EVOLUTION
Date Index Revision
06/12/2016 1.0 Final version
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 3/119
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 ST LITE IDENTIFICATION ................................................................................................... 7
1.2 TOE REFERENCE.............................................................................................................. 7
1.3 TOE OVERVIEW............................................................................................................... 8
1.4 TOE DESCRIPTION ........................................................................................................... 8
1.4.1 TOE Definition ....................................................................................................... 8
1.4.2 TOE usage and security features for operational use ...............................................10
1.4.3 TOE life cycle........................................................................................................13
2.1 CC CONFORMANCE CLAIM .................................................................................................18
2.2 PP CLAIM......................................................................................................................18
2.3 PACKAGE CLAIM..............................................................................................................18
2.4 PP CONFORMANCE RATIONALE ...........................................................................................19
3.1 ASSETS.........................................................................................................................20
3.1.1 Primary Assets travel document .............................................................................20
3.1.2 Secondary Assets travel document .........................................................................21
3.1.3 Additionals Assets .................................................................................................22
3.2 USERS / SUBJECTS...........................................................................................................22
3.2.1 Subjects listed in PP PACE .....................................................................................22
3.2.2 Additional Subjects................................................................................................24
3.3 THREATS.......................................................................................................................25
3.3.1 Threats listed in PP PACE.......................................................................................25
3.3.2 Additional Threats.................................................................................................27
3.4 ORGANISATIONAL SECURITY POLICIES ..................................................................................28
3.4.1 OSP listed in PP PACE............................................................................................28
3.4.2 Additional OSPs from PP EAC.................................................................................30
3.5 ASSUMPTIONS ................................................................................................................30
4.1 SECURITY OBJECTIVES FOR THE TOE ...................................................................................32
4.1.1 Security Objectives listed in PP PACE......................................................................32
4.1.2 Additional Security Objectives from PP EAC ............................................................34
4.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................35
4.2.1 Issuing State or Organisation.................................................................................35
4.2.2 Travel document Issuer and CSCA: travel document PKI (issuing) branch ................36
4.2.3 Terminal operator: Terminal receiving branch.........................................................37
4.2.4 Travel document holder Obligations .......................................................................37
4.2.5 Receiving State or Organisation .............................................................................37
4.3 SECURITY OBJECTIVES RATIONALE ......................................................................................39
4.3.1 Threats ................................................................................................................39
4.3.2 Organisational Security Policies..............................................................................41
4.3.3 Assumptions .........................................................................................................42
4.3.4 SPD and Security Objectives ..................................................................................43
5.1 EXTENDED FAMILY FCS_RND - GENERATION OF RANDOM NUMBERS ............................................47
5.2 EXTENDED FAMILY FPT_EMS - TOE EMANATION....................................................................48
5.3 EXTENDED FAMILY FAU_SAS - AUDIT DATA STORAGE..............................................................49
5.4 EXTENDED FAMILY FIA_API - AUTHENTICATION PROOF OF IDENTITY ..........................................50
5.5 EXTENDED FAMILY FMT_LIM - LIMITED CAPABILITIES AND AVAILABILITY......................................51
6.1 SECURITY FUNCTIONAL REQUIREMENTS ................................................................................53
6.1.1 Class Cryptographic Support (FCS).........................................................................55
7.1.1 Class FIA Identification and Authentication .............................................................58
7.1.2 Class FDP User Data Protection..............................................................................61
7.1.3 Class FTP Trusted Path/Channels ...........................................................................63
7.1.4 Class FAU Security Audit........................................................................................63
7.1.5 Class FMT Security Management............................................................................64
7.1.6 Class FPT Protection of the Security Functions ........................................................68
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 4/119
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.2 SECURITY ASSURANCE REQUIREMENTS..................................................................................69
7.3 SECURITY REQUIREMENTS RATIONALE ..................................................................................69
7.3.1 Objectives ............................................................................................................69
7.3.2 Rationale tables of Security Objectives and SFRs.....................................................73
7.3.3 Dependencies .......................................................................................................78
7.3.4 Rationale for the Security Assurance Requirements .................................................81
7.3.5 AVA_VAN.5 Advanced methodical vulnerability analysis ...........................................81
7.3.6 ALC_DVS.2 Sufficiency of security measures...........................................................81
8.1 TOE SUMMARY SPECIFICATION...........................................................................................82
8.1.1 SF.IA Identification and Authentication...................................................................82
8.1.2 SF.CF Cryptographic functions support ...................................................................83
8.1.3 SF.ILTB Protection against interference, logical tampering and bypass .....................83
8.1.4 SF.AC Access control / Storage and protection of logical travel document data .........83
8.1.5 SF.SM Secure Messaging .......................................................................................84
8.1.6 SF.LCM Security and life cycle management ...........................................................84
8.2 SFRS AND TSS...............................................................................................................86
8.2.1 SFRs and TSS - Rationale ......................................................................................86
9.1 SEPARATION OF THE PLATFORM TSF ....................................................................................91
9.2 COMPATIBILITY BETWEEN THE COMPOSITE SECURITY TARGET AND THE PLATFORM SECURITY TARGET.102
9.3 COMPATIBILITY OF ASSURANCE REQUIREMENTS ....................................................................105
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 5/119
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: TOE ......................................................................................................10
Figure 2: TOE life-cycle .........................................................................................13
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 6/119
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.................................................43
Table 2 Security Objectives and Threats - Coverage.................................................44
Table 3 OSPs and Security Objectives - Coverage....................................................44
Table 4 Security Objectives and OSPs - Coverage....................................................45
Table 5 Assumptions and Security Objectives for the Operational Environment -
Coverage .......................................................................................................45
Table 6 Security Objectives for the Operational Environment and Assumptions -
Coverage .......................................................................................................46
Table 7 Security Objectives and SFRs - Coverage ....................................................75
Table 8 SFRs and Security Objectives.....................................................................77
Table 9 SFRs Dependencies ..................................................................................80
Table 10 SARs Dependencies ................................................................................81
Table 11: Compatibility between platform SFRs and the composite ST – Firewall Policy .92
Table 12: Compatibility between platform SFRs and the composite ST – Firewall Policy .93
Table 13: Compatibility between platform SFRs and the composite ST – Application
Programming Interface....................................................................................96
Table 14: Compatibility between platform SFRs and the composite ST – Card Security
Management ..................................................................................................96
Table 15: Compatibility between platform SFRs and the composite ST – AID Management
....................................................................................................................97
Table 16: Compatibility between platform SFRs and the composite ST – INSTG Security
Functional Requirements..................................................................................97
Table 17: Compatibility between platform SFRs and the composite ST – ADELG Security
Functional Requirements..................................................................................98
Table 18: Compatibility between platform SFRs and the composite ST – ODELG Security
Functional Requirements..................................................................................98
Table 19: Compatibility between platform SFRs and the composite ST – CARG Security
Functional Requirements..................................................................................99
Table 20: Compatibility between platform SFRs and the composite ST – PACE Functional
Requirements .................................................................................................99
Table 21: Compatibility between platform SFRs and the composite ST - OSG Security
Functional Requirements................................................................................100
Table 22: Compatibility between platform SFRs and the composite ST - LifeCycle Security
Functional Requirements................................................................................100
Table 23: Compatibility between platform and composite ST....................................105
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 7/119
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 ST Lite Introduction
The aim of this document is to describe the Security Target Lite for MICAO, the
Machine Readable Travel Document (MRTD) with the ICAO application, Password
Authenticated Connection Establishment and Extended Access Control on IDeal
Citiz v2.1 open platform.
1.1 ST Lite Identification
Title
Security Target Lite Product Citiz 2.1 : MICAO 1.1.3 on
IDealCitiz OS 2.1, SAC/EAC configuration
Reference 2016_2000022974
Version 1.0
Certification
Body
ANSSI
Author SAFRAN I&S
CC Version 3.1 Revision 4
Assurance
Level
EAL5 augmented with ALC_DVS.2 and AVA_VAN.5
Protection
Profiles
Protection Profile Machine Readable Travel Document with
„ICAO Application”, Extended Access Control with PACE (EAC
PP) BSI-CC-PP-0056-V2-2012, Version 1.3.2, 5th December
2012 [EAC-PP-V2]
Protection Profile Machine Readable Travel Document using
Standard Inspection Procedure with PACE, BSI-CC-PP-0068-V2-
2011, Version 1.0.1, 22 July 2014, BSI [PACE-PP].
1.2 TOE Reference
TOE name Project name
TOE version
number
1.1.3
Name of
Platform
IdealCitizTM
v2.1 open platform
Version of
Platform
2.1.0
IC Identifiers
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)
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 8/119
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.3 TOE Overview
The Security Target (ST) Lite defines the security objectives and requirements
for a contact or contactless based chip of machine readable travel documents
(MRTD) based on the requirements and recommendations of the International
Civil Aviation Organization (ICAO) and EU requirements for Extended Access
Control v1 with PACE.
The main features and their origin are the following:
 Password Authenticated Connection Establishment (PACE)
according to ICAO Technical Report “Supplemental Access Control” [ICAO-
SAC] and strictly conform to BSI-CC-PP-0068-V2 [PACE-PP] for protection of
the communication between terminal and chip.
 Chip Authentication v1
according to BSI TR-03110 parts 1 and 3 [TR-03110-1], [TR-03110-3] and
strictly conform to BSI-CC-PP-0056-V2-2012 [EAC-PP-V2], authenticates the
travel document’s chip to the inspection system.
 Terminal Authentication v1
according to BSI TR-03110 parts 1 and 3 [TR-03110-1], [TR-03110-3] and
strictly conform to BSI-CC-PP-0056-V2-2012 [EAC-PP-V2], authenticates the
inspection system to travel document’s chip and protects the confidentiality
and integrity of the sensitive biometric reference data during their
transmission from the TOE to the inspection system.
As a feature that can be optionally configured the TOE supports:
 Active Authentication
which according to [ICAO-9303] prevents copying the SOD and proves that it
has been read from the authentic chip. It proves that the chip has not been
substituted.
1.4 TOE Description
1.4.1 TOE Definition
The Target of Evaluation (TOE) addressed by the current security target is an
electronic travel document representing a contactless / contact smart card
programmed according to ICAO Technical Report “Supplemental Access Control”
[ICAO-SAC] (which means amongst others according to the Logical Data
Structure (LDS) defined in [ICAO-9303]) and additionally providing the Extended
Access Control according to the ‘ICAO Doc 9303’ [ICAO-9303] BSI TR-03110 part
1 [TR-03110-1] and part 3 [TR-03110-3] and Active Authentication according to
[ICAO-9303]. The communication between terminal and chip shall be protected
by Password Authenticated Connection Establishment (PACE) according to
Electronic Passport using Standard Inspection Procedure with PACE (PACE PP),
BSI-CC-PP-0068-V2 [PACE-PP].
The TOE (Project name) is composed of
 the Ideal Citiz v2.1 open platform, composed of
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 9/119
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.
o the circuitry of the MRTD’s chip (the Infineon Security Controller M7892
B11 integrated circuit) with hardware for the contact and contactless
interface;
o the IC Dedicated Software with the parts IC Dedicated Test Software
and IC Dedicated Support Software;
o the IC Embedded Software (operating system): Safran I&S OS ID JC;
 the MRTD application Product Citiz 2.1 : MICAO 1.1.3 on IDealCitiz OS 2.1,
SAC/EAC configuration Applet loaded in FLASH;
 the associated guidance documentation.
The TOE utilizes the evaluation of the underlying platform, which includes the
Infineon chip, the IC Dedicated Software and the Safran I&S OS ID JC operating
system certified by the ANSSI Certification Body. The hardware platform Infineon
Security Controller M7892 B11 has been certified by BSI (BSI-DSZ-CC-0782-
2012) including the crypto libraries in the hardware.
A schematic overview of the TOE is shown in Figure 1:
 The MRTD’s chip circuitry and the IC dedicated software forming the Smart
Card Platform (Hardware Platform and Hardware Abstraction Layer);
 The IC embedded software running on the Smart Card Platform consisting of
o Java Card virtual machine, ensuring language-level security;
o Java Card runtime environment, providing additional security features
for Java card technology enabled devices;
o Java card API, providing access to card’s resources for the Applet;
o Global Platform Card Manager, responsible for management of Applets
on the card.
o Native Mifare application, for this TOE the Mifare application is disabled.
 The Applet Layer is Project name.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 10/119
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.
Figure 1: TOE
1.4.2 TOE usage and security features for operational use
A State or Organisation issues travel documents to be used by the holder for
international travel. The traveller presents a travel document to the inspection
system to prove his or her identity. The travel document in context of this
Security Target contains (i) visual (eye
readable) biographical data and portrait of the holder, (ii) a separate data
summary (MRZ data) for visual and machine reading using OCR methods in the
Machine readable zone (MRZ) and (iii) data elements on the travel document’s
chip according to LDS in case of contactless machine reading. The authentication
of the traveller is based on (i) the possession of a valid travel document
personalized for a holder with the claimed identity as given on the biographical
data page and (ii) biometrics using the reference data stored in the travel
document. The issuing State or Organization ensures the authenticity of the data
of genuine travel documents. The receiving State trusts a genuine travel
document of an issuing State or Organization.
For this Security Target the travel document is viewed as unit of
(i) the physical part of the travel document in form of paper and/or plastic
and chip. It presents visual readable data including (but not limited to)
personal data of the travel document holder
(a) the biographical data on the biographical data page of the travel
document surface,
(b) the printed data in the Machine Readable Zone (MRZ) and
(c) the printed portrait.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 11/119
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.
(ii) the logical travel document as data of the travel document holder stored
according to the Logical Data Structure as defined in [ICAO-9303] as specified
by ICAO on the contact based or contactless integrated circuit. It presents
contact based or contactless readable data including(but not limited to)
personal data of the travel document holder
(a) the digital Machine Readable Zone Data (digital MRZ data, EF.DG1),
(b) the digitized portraits (EF.DG2),
(c) the biometric reference data of finger(s) (EF.DG3) or iris image(s)
(EF.DG4) or both1
,
(d) the other data according to LDS (EF.DG5 to EF.DG16) and
(e) the Document Security Object (SOD).
The issuing State or Organisation implements security features of the travel
document to maintain the authenticity and integrity of the travel document and
their data. The physical part of the travel document and the travel document’s
chip are identified by the Document Number.
The physical part of the travel document is protected by physical security
measures (e.g. watermark, security printing), logical (e.g. authentication keys of
the travel document’s chip)and organisational security measures (e.g. control of
materials, personalisation procedures) [ICAO-9303].These security measures can
include the binding of the travel document’s chip to the travel document.
The logical travel document is protected in authenticity and integrity by a digital
signature created by the document signer acting for the issuing State or
Organisation and the security features of the travel document’s chip.
The ICAO defines the baseline security methods Passive Authentication and the
optional advanced security methods Basic Access Control to the logical travel
document, Active Authentication of the travel document’s chip, Extended Access
Control to and the Data Encryption of sensitive biometrics as optional security
measure in the ICAO Doc 9303 [ICAO-9303] and Password Authenticated
Connection Establishment [ICAO-SAC]. The Passive Authentication Mechanism is
performed completely and independently of the TOE by the TOE environment.
This Security Target addresses the protection of the logical travel document (i) in
integrity by write-only-once access control and by physical means, and (ii) in
confidentiality by the Extended Access Control Mechanism. This Security Target
addresses the Chip Authentication Version 1 described in [TR-03110-1] as an
alternative to the Active Authentication stated in [ICAO-9303] as well Active
Authentication itself.
For Basic Access Control (BAC) supported by the product, a separate evaluation
and certification is performed with ST [ST-BAC].
1
These biometric reference data are optional according to [ICAO-9303]. This ST assumes that the issuing State or
Organisation uses this option and protects these data by means of extended access control.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 12/119
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 confidentiality by Password Authenticated Connection Establishment (PACE)
is a mandatory security feature of the TOE. The travel document shall strictly
conform to the ‘Common Criteria Protection Profile Machine Readable Travel
Document using Standard Inspection Procedure with PACE [PACE-PP]. Note that
[PACE-PP] considers high attack potential.
For the PACE protocol according to [ICAO-SAC], the following steps shall be
performed:
(i) the travel document's chip encrypts a nonce with the shared password,
derived from the MRZ resp. CAN data and transmits the encrypted nonce
together with the domain parameters to the terminal.
(ii) The terminal recovers the nonce using the shared password, by
(physically) reading the MRZ resp. CAN data.
(iii) The travel document's chip and terminal computer perform a Diffie-
Hellmann key agreement together with the ephemeral domain parameters
to create a shared secret. Both parties derive the session keys KMAC and
KENC from the shared secret.
(iv) Each party generates an authentication token, sends it to the other party
and verifies the received token.
After successful key negotiation the terminal and the travel document's chip
provide private communication (secure messaging) [TR-03110-1], [ICAO-SAC].
This Security Target requires the TOE to implement the Extended Access Control
as defined in [TR-03110-1]. The Extended Access Control consists of two parts
(i) the Chip Authentication Protocol Version 1 and
(ii) the Terminal Authentication Protocol Version 1 (v.1).
The Chip Authentication Protocol v.1
(i) authenticates the travel document’s chip to the inspection system and
(ii) establishes secure messaging which is used by Terminal Authentication v.1
to protect the confidentiality and integrity of the sensitive biometric
reference data during their transmission from the TOE to the inspection
system. Therefore Terminal Authentication v.1 can only be performed if
Chip Authentication v.1has been successfully executed.
The Terminal Authentication Protocolv.1 consists of
(i) the authentication of the inspection system as entity authorized by the
receiving State or Organisation through the issuing State, and
(ii) an access control by the TOE to allow reading the sensitive biometric
reference data only to successfully authenticated authorized inspection
systems.
Active Authentication may be optionally configured.
The issuing State or Organisation authorizes the receiving State by means of
certification the authentication public keys of Document Verifiers who create
Inspection System Certificates.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 13/119
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.4.3 TOE life cycle
The TOE life cycle is described in terms of its four life cycle phases. (With respect
to the [SIC-PP], the TOE life-cycle is additionally subdivided into 7 steps in the
ST. These steps are denoted too in the following although the sequence of the
steps differs for the TOE life cycle)
Figure 2: TOE life-cycle
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 14/119
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.
Actors :
IC Developer, IC Manufacturer Infineon
Software Developer Safran I&S (Osny)
Travel document manufacturer Infineon or Safran I&S (Ostrava)
1.4.3.1 Phase 1 “Development”
(Step1) The TOE is developed in phase 1. The IC developer develops the
integrated circuit, the IC Dedicated Software and the guidance documentation
associated with these TOE components.
(Step2) The software developer uses the guidance documentation for the
integrated circuit and the guidance documentation for relevant parts of the Ideal
Citiz v2.1 open platform and develops the MICAO ePassport application and the
guidance documentation associated with this TOE component.
The MICAO ePassport application is integrated in FLASH memory of the chip.
Depending on the intention
(a)the ePassport application is securely delivered directly from the software
developer (Safran I&S) to the IC manufacturer (Infineon). The applet code
will be integrated into the FLASH code by the IC manufacturer, or
(b)either the ePassport application and the guidance documentation is
securely delivered directly from the software developer (Safran I&S) to the
travel document manufacturer (Safran I&S).
1.4.3.2 Phase 2 “Manufacturing”
(Step3) In a first step the TOE integrated circuit is produced containing the travel
document’s chip Dedicated Software, the parts of the travel document’s chip
Embedded Software, and in case of alternative a) the ePassport application in the
non-volatile non-programmable memories (FLASH). The IC manufacturer writes
the IC Identification Data onto the chip to control the IC as travel document
material during the IC manufacturing and the delivery process to the travel
document manufacturer. The IC is securely delivered from the IC manufacturer
to the travel document manufacturer.
If necessary the IC manufacturer adds the parts of the IC Embedded Software in
the non-volatile programmable memories (for instance EEPROM).
(Step4 optional) The travel document manufacturer combines the IC with
hardware for the contact based / contactless interface in the travel document
unless the travel document consist of the chip only.
(Step5) The travel document manufacturer
(i) adds the IC Embedded Software or part of it in the non-volatile
programmable memories (for instance FLASH) if necessary and in case of
alternative (b), loads the ePassport application into the non-volatile
programmable memories (for instance FLASH) if necessary,
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 15/119
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.
(ii)creates the ePassport application,
(iii) equips travel document’s chips with pre-personalization Data.
EAC PP Application Note 1: Creation of the application for this TOE implies
Applet instantiation.
For this Security Target the following name mappings to the protection profile
[EAC-PP-V2] apply:
 IC Dedicated SW = Low level IC libraries
 travel document’s chip Embedded Software = Safran I&S OS ID JC
operating system.
 ePassport application = Project name Applet run time code or an
instantiation of it.
 Pre-personalization Data = Personalization Agent Key Set and Card
Production Life Cycle (CPLC) data.
Both the underlying platform and Project name provide configuration and life-
cycle management functions required for TOE preparation. TOE preparation steps
are performed in manufacturing phase and consist of the following 2 activities:
1. Platform initialisation
2. Pre-personalisation
Platform initialisation
Platform initialisation consists of the configuration of the Ideal Citiz v2.1 open
platform in accordance with requirements specified in the Ideal Citiz v2.1 open
platform administrator guidance [PLTF-ADM] by using the dedicated platform
commands. Furthermore the Pre-Personalisation Agent key set is installed and (a
part of) the CPLC data is updated.
Pre-personalisation
The pre-personalisation consists of the following steps:
a. IC (chip) Authentication and getting chip access with the pre-
personalisation key set.
b. [optional] In case the Project name Applet runtime code does not reside in
FLASH, it is loaded into FLASH.
c. Create applet instance for Project name Applet (i.e. installation of the
Project name Applet);
d. Disabling further pre-personalisation functionality;
e. Set the MRTD irreversibly in its PERSONALISATION life-cycle state by
installation of the Personalisation Agent specific personalisation key set;
During step c the CPLC data with the IC Identifier is configured in the ePassport
application instance. The last step (e) finalizes the TOE. This is the moment the
TOE starts to exist and is ready for delivery to the Personalisation Agent. The
guidance documentation for the Personalisation Agent is [AGD_PRE].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 16/119
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 pre-personalised travel document together with the IC Identifier is securely
delivered from the travel document manufacturer to the Personalisation Agent.
The travel document manufacturer also provides the relevant parts of the
guidance documentation to the Personalisation Agent.
1.4.3.3 Phase 3 “Personalisation of the travel document”
(Step6) The personalisation of the travel document includes
(i) the survey of the travel document holder’s biographical data,
(ii)the enrolment of the travel document holder biometric reference data (i.e.
the digitized portraits and the optional biometric reference data),
(iii) the personalization of the visual readable data onto the physical part
of the travel document,
(iv) the writing of the TOE User Data and TSF Data into the logical travel
document and
(v)configuration of the TSF if necessary.
The step (iv) is performed by the Personalisation Agent and includes but is not
limited to the creation of
(i) the digital MRZ data (EF.DG1),
(ii) the digitized portrait (EF.DG2), and
(iii) the Document security object.
The signing of the Document security object by the Document signer [ICAO-
9303] finalizes the personalisation of the genuine travel document for the travel
document holder. The personalised travel document (together with appropriate
guidance (AGD_OPE) for TOE use if necessary) is handed over to the travel
document holder for operational use.
EAC PP Application note 2: The TSF data (data created by and for the TOE,
that might affect the operation of the TOE; cf. [CC-1] §92) comprise (but are not
limited to) the Personalisation Agent Authentication Key(s), the Terminal
Authentication trust anchor, the effective date and the Chip Authentication
Private Key.
EAC PP Application note 3: This ST distinguishes between the Personalisation
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 [ICAO-
9303]. This approach allows but does not enforce the separation of these roles.
.
1.4.3.4 Phase 4 “Operational Use”
(Step7) The TOE is used as a travel document'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 Organisation and can be
used according to the security policy of the issuing State but they can never be
modified.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 17/119
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.
EAC PP Application note 4 2
: The intention of the ST is to consider at least the
phases 1 and parts of phase 2 (i.e. Step1 to Step3) as part of the evaluation and
therefore to define the TOE delivery according to CC after this phase. Since
specific production steps of phase 2 are of minor security relevance (e.g. booklet
manufacturing and antenna integration) these are not part of the CC evaluation
under ALC. Nevertheless the decision about this has to be taken by the
certification body resp. the national body of the issuing State or Organisation. In
this case the national body of the issuing State or Organisation is responsible for
these specific production steps.
Note that the personalisation process and its environment may depend on
specific security needs of an issuing State or Organisation. All production,
generation and installation procedures after TOE delivery up to the “Operational
Use” (phase 4) have to be considered in the product evaluation process under
AGD assurance class. Therefore, the Security Target outlines the split up of
P.Manufact, P.Personalisation and the related security objectives into aspects
relevant before vs. after TOE delivery.
1.4.3.5 Non-TOE hardware/software/firmware required by the TOE
There is no explicit non-TOE hardware, software or firmware required by the TOE
to perform its claimed security features. The TOE is defined to comprise the chip
and the complete operating system and application. Note, the inlay holding the
chip as well as the antenna and the booklet (holding the printed MRZ) are
needed to represent a complete travel document. Nevertheless these parts are
not inevitable for the secure operation of the TOE.
2
For this ST all steps of both phase 1 and phase 2 are part of the evaluation and therefore define the TOE
delivery according to the CC evaluation after this phase.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 18/119
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 CC Conformance Claim
This security target claims to be conformant to the Common Criteria version
3.1,which comprises
 Common Criteria for Information Technology Security Evaluation, Part
1:Introduction and General Model; CCMB-2012-09-001, Version 3.1, Revision
4, September 2012
[CC-1]
 Common Criteria for Information Technology Security Evaluation, Part
2:Security Functional Requirements; CCMB-2012-09-002, Version 3.1,
Revision 4, September 2012 [CC-2]
 Common Criteria for Information Technology Security Evaluation, Part
3:Security Assurance Requirements; CCMB-2012-09-003, Version 3.1,
Revision 4, September 2012 [CC-3]
as follows:
 Part 2 extended
 Part 3 conformant
The Common Methodology for Information Technology Security Evaluation
(CEM), Evaluation Methodology; CCMB-2012-09-004, Version 3.1, Revision 4,
September 2012 [CEM] has been taken into account.
2.2 PP Claim
This security target (ST) claims strict conformance to:
 Common Criteria Protection Profile Machine Readable Travel Document
with „ICAO Application”, Extended Access Control with PACE (EAC PP) BSI-
CC-PP-0056-V2-2012, Version 1.3.2, 5th December 2012 [EAC-PP-V2].
 Protection Profile Machine Readable Travel Document using Standard
Inspection Procedure with PACE, BSI-CC-PP-0068-V2-2011, Version 1.0.1,
22 July 2014, BSI [PACE-PP].
The [EAC-PP-V2] claims strict conformance to the PACE Protection Profile
Machine Readable Travel Document using Standard Inspection Procedure with
PACE, BSI-CC-PP-0068-V2-2011, Version 1.0, 2nd
November 2011, BSI [PACE-
PP].
2.3 Package Claim
This ST is conforming to assurance package EAL5 augmented with ALC_DVS.2
and AVA_VAN.5 defined in CC part 3 [CC-3].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 19/119
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.4 PP Conformance Rationale
This ST claims strict conformance to [EAC-PP-V2]. According to hints in [EAC-PP-
V2] parts of the [PACE-PP] have been included into this ST. A detailed
justification is given in the following.
Main aspects:
- The TOE description (chapter 1.3) is based on the TOE definition and TOE
usage of [EAC-PP, 1.1]. It was enhanced by product specific details.
- All definitions of the security problem definition in [EAC-PP, 3] have been
taken exactly from this protection profile in the same wording.
- All security objectives have been taken exactly from [EAC-PP, 4] in the same
wording.
- The part of extended components definition has been taken originally from
[EAC-PP, 5].
- All SFRs for the TOE have been taken originally from the [EAC-PP, 6.1] added
by according iterations, selections and assignments.
3 SFRs additional iterations have been added in this ST :
- FCS_COP.1/SIG_GEN,
- FIA_API.1/CA,
- FMT_MTD.1/AAPK
- The security assurance requirements (SARs) have been taken originally from
the EAC-PP. The requirements are shifted to those of EAL 5 if necessary.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 20/119
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 assets to be protected by the TOE include the User Data on the travel
document’s chip, user data transferred between the TOE and the terminal, and
travel document tracing data from PACE PP [PACE-PP], chapter 3.1, claimed by
[EAC-PP-V2]:
3.1.1 Primary Assets travel document
user data stored on the TOE
All data (being not authentication data) stored in the context of the ePassport
application of the travel document as defined in [ICAO-SAC] and being allowed
to be read out solely by an authenticated terminal acting as Basic Inspection
System with PACE (in the sense of [ICAO-SAC]).This asset covers "User Data
on the MRTD’s chip", "Logical MRTD Data" and "Sensitive User Data" in [BAC-
PP].
The generic security properties to be maintained by the current security policy
are:
Confidentiality
Integrity
Authenticity
user data transferred between the TOE and the terminal connected
The terminal connected is an authority represented by Basic Inspection System
with PACE.
All data (being not authentication data) being transferred in the context of the
ePassport application of the travel document as defined in [ICAO-SAC] between
the TOE and an authenticated terminal acting as Basic Inspection System with
PACE (in the sense of [ICAO-SAC]). User data can be received and sent.
The generic security properties to be maintained by the current security policy
are:
Confidentiality
Integrity
Authenticity
travel document tracing data
Technical information about the current and previous locations of the travel
document gathered unnoticeable by the travel document holder recognizing the
TOE not knowing any PACE password. TOE tracing data can be provided /
gathered.
The generic security property to be maintained by the current security policy is:
Unavailability
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 21/119
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.1.2 Secondary Assets travel document
Accessibility to the TOE functions and data only for authorised subjects
Property of the TOE to restrict access to TSF and TSF-data stored in the TOE to
authorized subjects only.
The property to be maintained by the current security policy is:
Availability
Genuineness of the TOE
Property of the TOE to be authentic in order to provide claimed security
functionality in a proper way. This asset also covers "Authenticity of the MRTD's
chip" in [BAC-PP]
The property to be maintained by the current security policy is:
Availability
TOE internal secret cryptographic keys
Permanently or temporarily stored secret cryptographic material used by the
TOE in order to enforce its security functionality.
The properties to be maintained by the current security policy are:
Confidentiality
Integrity
TOE internal non-secret cryptographic material
Permanently or temporarily stored non-secret cryptographic (public) keys and
other non-secret material (Document Security Object SOD containing digital
signature) used by the TOE in order to enforce its security functionality.
The properties to be maintained by the current security policy are:
Integrity
Authenticity
travel document communication establishment authorisation data
Restricted-reveal able authorization information for a human user being used
for verification of the authorisation attempts as authorized user (PACE
password). These data are stored in the TOE and are not to be send to it.
The properties to be maintained by the current security policy are:
Confidentiality
Integrity
All primary assets represent User Data in the sense of the CC. The secondary
assets represent TSF and TSF-data in the sense of the CC, see [PACE-PP, 3.1].
The secondary assets also have to be protected by the TOE in order to achieve a
sufficient protection of the primary assets.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 22/119
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.1.3 Additionals Assets
Logical travel document sensitive User Data
Sensitive biometric reference data (EF.DG3, EF.DG4)
Authenticity of the travel document chip
The authenticity of the travel document’s chip personalised by the issuing State
or Organisation for the travel document holder is used by the traveler to prove
his possession of a genuine travel document.
3.2 Users / Subjects
3.2.1 Subjects listed in PP PACE
This ST considers the following external entities and subjects from [PACE-PP]
chapter 3.1:
travel document holder
Definition A person for whom the travel document Issuer has personalized the
travel document. This entity is commensurate with ‘MRTD Holder’ in [BAC-PP].
Please note that a travel document holder can also be an attacker (s. below).
travel document presenter
A person presenting the travel document to a terminal and claiming the identity
of the travel document holder. This external entity is commensurate with
‘Traveler’ in [BAC-PP]. Please note that a travel document presenter can also be
an attacker (s. below)
Terminal
A terminal is any technical system communicating with the TOE through the
contactless/contact interface. The role ‘Terminal’ is the default role for any
terminal being recognised by the TOE as not being PACE authenticated
(‘Terminal’ is used by the travel document presenter). This entity is
commensurate with ‘Terminal’ in [BAC-PP].
Basic Inspection System with BIS-PACE
A technical system being used by an inspecting authority and verifying the travel
document presenter as the travel Document holder (for ePassport: by
comparing the real biometric data (face) of the travel document presenter with
the stored biometric data (DG2) of the travel document holder). BIS-PACE
implements the terminal’s part of the PACE protocol and authenticates itself to
the travel document using a shared password (PACE password) and supports
Passive Authentication.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 23/119
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.
Document Signer (DS)
An organisation enforcing the policy of the CSCA and signing the Document
Security Object stored on the travel document for passive authentication. A
Document Signer is authorised by the national CSCA issuing the Document
Signer Certificate (CDS), see [ICAO-9303]. This role is usually delegated to a
Personalisation Agent.
Country Signing Certification Authority
An organisation enforcing the policy of the travel document Issuer with respect
to confirming correctness of user and TSF data stored in the travel document.
The CSCA represents the country specific root of the PKI for the travel document
and creates the Document Signer Certificates within this PKI. The CSCA also
issues the self-signed CSCA Certificate (CCSCA) having to be distributed by
strictly secure diplomatic means, see [ICAO-9303], 5.5.1.
Personalisation Agent
An organization acting on behalf of the travel document Issuer to personalise
the travel document for the travel document holder by some or all of the
following activities:
(i) establishing the identity of the travel document holder for the biographic
data in the travel document,
(ii) enrolling the biometric reference data of the travel document holder,
(iii) writing a subset of these data on the physical travel document (optical
personalisation) and storing them in the travel document (electronic
personalisation) for the travel document holder as defined in [ICAO-
9303],
(iv) writing the document details data,
(v) writing the initial TSF data, (vi) signing the Document Security Object
defined in [ICAO-9303](in the role of DS). Please note that the role
‘Personalisation Agent’ may be distributed among several institutions
according to the operational policy of the travel document Issuer. This
entity is commensurate with ‘Personalisation agent’ in [BAC-PP].
Manufacturer
Generic term for the IC Manufacturer producing integrated circuit and the travel
document Manufacturer completing the IC to the travel document. The
Manufacturer is the default user of the TOE during the manufacturing life cycle
phase. The TOE itself does not distinguish between the IC Manufacturer and
travel document Manufacturer using this role Manufacturer. This entity is
commensurate with ‘Manufacturer’ in [BAC-PP].
Attacker
A threat agent (a person or a process acting on his behalf) trying to undermine
the security policy defined by the current PP, especially to change properties of
the assets having to be maintained. The attacker is assumed to possess an at
most high attack potential. Please note that the attacker might ‘capture’ any
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 24/119
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.
subject role recognised by the TOE. This external entity is commensurate with
‘Attacker’ in [BAC-PP].
Additionally to this definition, the definition of an attacker is refined as follows:
A threat agent trying
(i) to manipulate the logical travel document without authorization,
(ii) to read sensitive biometric reference data (i.e. EF.DG3, EF.DG4),
(iii) to forge a genuine travel document, or
(iv) to trace a travel document.
3.2.2 Additional Subjects
Furthermore this ST considers the following additional subjects from [EAC-PP-V2]:
Country Verifying Certification Authority
The Country Verifying Certification Authority (CVCA) enforces the privacy policy
of the issuing State or Organisation with respect to the protection of sensitive
biometric reference data stored in the travel document. The CVCA represents
the country specific root of the PKI of Inspection Systems and creates the
Document Verifier Certificates within this PKI. The updates of the public key of
the CVCA are distributed in the form of Country Verifying CA Link-Certificates.
Document Verifier
The Document Verifier (DV) enforces the privacy policy of the receiving State
with respect to, the protection of sensitive biometric reference data to be
handled by the Extended Inspection Systems. The Document Verifier manages
the authorization of the Extended Inspection Systems for the sensitive data of
the travel document in the limits provided by the issuing States or Organisations
in the form of the Document Verifier Certificates.
Inspection system (IS)
A technical system used by the border control officer of the receiving State (i)
examining an travel document presented by the traveler and verifying its
authenticity and (ii) verifying the traveler as travel document holder.
The Extended Inspection System (EIS) performs the Advanced Inspection
Procedure and therefore
(i)contains a terminal for the communication with the travel document’s
chip,
(ii) implements the terminals part of PACE and/or BAC;
(iii) gets the authorization to read the logical travel document either under
PACE or BAC by optical reading the travel document providing this
information.
(iv) implements the Terminal Authentication and Chip Authentication
Protocols both Version 1 according to [TR-03110-1] and
(v) is authorized by the issuing State or Organisation through the Document
Verifier of the receiving State to read the sensitive biometric reference
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 25/119
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. Security attributes of the EIS are defined by means of the Inspection
System Certificates. BAC may only be used if supported by the TOE. If
both PACE and BAC are supported by the TOE and the BIS, PACE must be
used.
3.3 Threats
This section describes the threats to be averted by the TOE independently or in
collaboration with its IT environment. These threats result from the TOE method
of use in the operational environment and the assets stored in or protected by the
TOE. Threats to be averted by the TOE and its environment
3.3.1 Threats listed in PP PACE
T.Skimming
Skimming travel document / Capturing Card-Terminal Communication
Adverse action: An attacker imitates an inspection system in order to get access
to the user data stored on or transferred between the TOE and the inspecting
authority connected via the contactless/contact interface of the TOE.
Threat agent: having high attack potential, cannot read and does not know the
correct value of the shared password (PACE password) in advance.
Asset: confidentiality of logical travel document data
T.Eavesdropping
Eavesdropping on the communication between the TOE and the PACE
terminal
Adverse action: An attacker is listening to the communication between the travel
document and the PACE authenticated BIS-PACE in order to gain the user data
transferred between the TOE and the terminal connected.
Threat agent: having high attack potential, cannot read and does not know the
correct value of the shared password (PACE password) in advance.
Asset: confidentiality of logical travel document data
T.Tracing
Tracing travel document
Adverse action: An attacker tries to gather TOE tracing data (i.e. to trace the
movement of the travel document) unambiguously identifying it remotely by
establishing or listening to a communication via the contactless/contact
interface of the TOE.
Threat agent: having high attack potential, cannot read and does not know the
correct value of the shared password (PACE password) in advance.
Asset: privacy of the travel document holder
T.Forgery
Forgery of Data
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 26/119
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.
Adverse action: An attacker fraudulently alters the User Data or/and TSF-data
stored on the travel document or/and exchanged between the TOE and the
terminal connected in order to outsmart the PACE authenticated BIS-PACE or
EIS-PACE by means of changed travel document holder’s related reference data
(like biographic or biometric data). The attacker does it in such a way that the
terminal connected perceives these modified data as authentic one.
Threat agent: having high attack potential
Asset: integrity of the travel document
T.Abuse-Func
Abuse of Functionality
Adverse action: An attacker may use functions of the TOE which shall not be
used in TOE operational phase in order (i) to manipulate or to disclose the User
Data stored in the TOE, (ii) to manipulate or to disclose the TSF-data stored in
the TOE or (iii) to manipulate (bypass, deactivate or modify) soft-coded security
functionality of the TOE. This threat addresses the misuse of the functions for
the initialisation and personalisation in the operational phase after delivery to
the travel document holder.
Threat agent: having high attack potential, being in possession of one or more
legitimate travel documents
Asset: integrity and authenticity of the travel document, availability of the
functionality of the travel document
T.Information_Leakage
Information Leakage from travel document
Adverse action: An attacker may exploit information leaking from the TOE
during its usage in order to disclose confidential User Data or/and TSF-data
stored on the travel document or/and exchanged between the TOE and the
terminal connected. The information leakage may be inherent in the normal
operation or caused by the attacker.
Threat agent: having high attack potential.
Asset: confidentiality of User Data and TSF-data of the travel document
T.Phys-Tamper
Physical Tampering
Adverse action: An attacker may perform physical probing of the travel
document in order (i) to disclose the TSF-data, or (ii) to disclose/reconstruct the
TOE’s Embedded Software.
An attacker may physically modify the travel document in order to alter (i) its
security functionality (hardware and software part, as well), (ii) the User Data
or the TSF-data stored on the travel document.
Threat agent: having high attack potential, being in possession of one or more
legitimate travel documents.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 27/119
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.
Asset: integrity and authenticity of the travel document, availability of the
functionality of the travel document, confidentiality of User Data and TSF-data
of the travel document
T.Malfunction
Malfunction due to Environmental Stress
Adverse action: An attacker may cause a malfunction the travel document’s
hardware and Embedded Software by applying environmental stress in order to
(i) deactivate or modify security features or functionality of the TOE’ hardware
or to (ii) circumvent, deactivate or modify security functions of the TOE’s
Embedded Software. This may be achieved e.g. by operating the travel
document outside the normal operating conditions, exploiting errors in the
travel document’s Embedded Software or misusing administrative functions. To
exploit these vulnerabilities an attacker needs information about the functional
operation.
Threat agent: having high attack potential, being in possession of one or more
legitimate travel documents, having information about the functional operation
Asset: integrity and authenticity of the travel document, availability of the
functionality of the travel document, confidentiality of User Data and TSF-data
of the travel document
3.3.2 Additional Threats
T.Read_Sensitive_Data
Read the sensitive biometric reference data
Adverse action: An attacker tries to gain the sensitive biometric reference data
through the communication interface of the travel document’s chip.
The attack T.Read_Sensitive_Data is similar to the threat T.Skimming (cf.
[PP_BAC]) in respect of the attack path (communication interface) and the
motivation (to get data stored on the travel document’s chip) but differs from
those in the asset under the attack (sensitive biometric reference data vs. digital
MRZ, digitized portrait and other data), the opportunity (i.e. knowing the PACE
Password) and therefore the possible attack methods. Note, that the sensitive
biometric reference data are stored only on the travel document’s chip as private
sensitive personal data whereas the MRZ data and the portrait are visually
readable on the physical part of the travel document as well.
Threat agent: having high attack potential, knowing the PACE Password, being
in possession of a legitimate travel document.
Asset: confidentiality of logical travel document sensitive user data(i.e.
biometric reference)
T.Counterfeit
Counterfeit of travel document chip data
Adverse action: An attacker with high attack potential produces an unauthorized
copy or reproduction of a genuine travel document’s chip to be used as part of
a counterfeit travel document. This violates the authenticity of the travel
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 28/119
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.
document’s chip used for authentication of a traveler by possession of a travel
document. The attacker may generate a new data set or extract completely or
partially the data from a genuine travel document’s chip and copy them to
another appropriate chip to imitate this genuine travel document’s chip.
Threat agent: having high attack potential, being in possession of one or more
legitimate travel documents.
Asset: authenticity of user data stored on the TOE
3.4 Organisational Security Policies
The TOE shall comply to the following organization security policies (OSP) as
security rules, procedures, practices, or guidelines imposed by an organization
upon its operations (see CC part 1 [CC-1], sec. 3.2).
3.4.1 OSP listed in PP PACE
P.Manufact
Manufacturing of the travel document's chip
The Initialisation Data are written by the IC Manufacturer to identify the IC
uniquely. The travel document Manufacturer writes the Pre-personalisation Data
which contains at least the Personalisation Agent Key.
P.Pre-Operational
Pre-operational handling of the travel document
1. The travel document Issuer issues the travel document and approves it
using the terminals complying with all applicable laws and regulations.
2. The travel document Issuer guarantees correctness of the user data
(amongst other of those, concerning the travel document holder) and of
the TSF-data permanently stored in the TOE
3. The travel document Issuer uses only such TOE’s technical components
(IC) which enable traceability of the travel documents in their
manufacturing and issuing life cycle phases, i.e. before they are in the
operational phase
4. If the travel document Issuer authorises a Personalisation Agent to
personalise the travel document for travel document holders, the travel
document Issuer has to ensure that the Personalisation Agent acts in
accordance with the travel document Issuer’s policy.
P.Card_PKI
PKI for Passive Authentication (issuing branch)
1. The travel document Issuer shall establish a public key infrastructure for
the passive authentication, i.e. for digital signature creation and
verification for the travel document. For this aim, he runs a Country
Signing Certification Authority (CSCA). The travel document Issuer shall
publish the CSCA Certificate (CCSCA).
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 29/119
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. The CSCA shall securely generate, store and use the CSCA key pair. The
CSCA shall keep the CSCA Private Key secret and issue a self-signed CSCA
Certificate (CCSCA) having to be made available to the travel document
Issuer by strictly secure means, see [ICAO-9303], 5.5.1. The CSCA shall
create the Document Signer Certificates for the Document Signer Public
Keys (CDS) and make them available to the travel document Issuer, see
[ICAO-9303], 5.5.1.
3. A Document Signer shall (i) generate the Document Signer Key Pair, (ii)
hand over the Document Signer Public Key to the CSCA for certification,
(iii) keep the Document Signer Private Key secret and (iv) securely use
the Document Signer Private Key for signing the Document Security
Objects of travel documents.
Application Note:
The given description states the responsibilities of involved parties and
represents the logical, but not the physical structure of the PKI. Physical
distribution ways shall be implemented by the involved parties in such a way
that all certificates belonging to the PKI are securely distributed / made available
to their final destination, e.g. by using directory services.
P.Trustworthy_PKI
Trustworthiness of PKI
The CSCA shall ensure that it issues its certificates exclusively to the rightful
organisations (DS) and DSs shall ensure that they sign exclusively correct
Document Security Objects to be stored on the travel document.
P.Terminal
Abilities and trustworthiness of terminals
The Basic Inspection Systems with PACE (BIS-PACE) shall operate their
terminals as follows:
1. The related terminals (basic inspection system, cf. above) shall be used
by terminal operators and by travel document holders as defined in
[ICAO-9303].
2. They shall implement the terminal parts of the PACE protocol [ICAO-SAC],
of the Passive Authentication [ICAO-9303] and use them in this order.
The PACE terminal shall use randomly and (almost) uniformly selected
nonces, if required by the protocols (for generating ephemeral keys for
Diffie-Hellmann).
3. The related terminals need not to use any own credentials.
4. They shall also store the Country Signing Public Key and the Document
Signer Public Key (in form of CCSCA and CDS) in order to enable and to
perform Passive Authentication (determination of the authenticity of data
groups stored in the travel document, [ICAO-9303]).
5. The related terminals and their environment shall ensure confidentiality
and integrity of respective data handled by them (e.g. confidentiality of
PACE passwords, integrity of PKI certificates, etc.), where it is necessary
for a secure operation of the TOE according to the PP [PACE-PP].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 30/119
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.4.2 Additional OSPs from PP EAC
P.Sensitive_Data
Privacy of sensitive biometric reference data
The biometric reference data of finger(s) (EF.DG3) and iris image(s) (EF.DG4)
are sensitive private personal data of the travel document holder. The sensitive
biometric reference data can be used only by inspection systems which are
authorized for this access at the time the travel document is presented to the
inspection system (Extended Inspection Systems). The issuing State or
Organization authorizes the Document Verifiers of the receiving States to
manage the authorization of inspection systems within the limits defined by the
Document Verifier Certificate. The travel document’s chip shall protect the
confidentiality and integrity of the sensitive private personal data even during
transmission to the Extended Inspection System after Chip Authentication
Version 1.
P.Personalisation
Personalisation of the travel document by issuing State or Organisation
only
The issuing State or Organisation guarantees the correctness of the biographical
data, the printed portrait and the digitized portrait, the biometric reference data
and other data of the logical travel document with respect to the travel
document holder. The personalisation of the travel document for the holder is
performed by an agent authorized by the issuing State or Organisation only.
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.Passive_Auth
PKI for Passive Authentication The issuing and receiving States or
Organisations establish a public key infrastructure for passive authentication i.e.
digital signature creation and verification for the logical travel document. The
issuing State or Organisation runs a Certification Authority (CA) which securely
generates, stores and uses the Country Signing CA Key pair. The CA keeps the
Country Signing CA Private Key secret and is recommended to distribute the
Country Signing CA Public Key to ICAO, all receiving States maintaining its
integrity. The Document Signer (i) generates the Document Signer Key Pair,(ii)
hands over the Document Signer Public Key to the CA for certification, (iii) keeps
the Document Signer Private Key secret and (iv) uses securely the Document
Signer Private Key for signing the Document Security Objects of the travel
documents. The CA creates the Document Signer Certificates for the Document
Signer Public Keys that are distributed to the receiving States and
Organisations. It is assumed that the Personalisation Agent ensures that the
Document Security Object contains only the hash values of genuine user data
according to [ICAO-9303].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 31/119
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.
A.Insp_Sys
Inspection Systems for global interoperability The Extended Inspection
System (EIS) for global interoperability includes the Country Signing CA Public
Key and implements the terminal part of PACE [ICAO-SAC] and/or BAC [BAC-
PP]. BAC may only be used if supported by the TOE. If both PACE and BAC are
supported by the TOE and the IS, PACE must be used. The EIS reads the logical
travel document under PACE or BAC and performs the Chip Authentication v.1
to verify the logical travel document and establishes secure messaging. EIS
supports the Terminal Authentication Protocol v.1 in order to ensure access
control and is authorized by the issuing State or Organisation through the
Document Verifier of the receiving State to read the sensitive biometric
reference data.
Justification: The assumption A.Insp_Sys does not confine the security
objectives of the [PACE-PP] as it repeats the requirements of P.Terminal and
adds only assumptions for the Inspection Systems for handling the EAC
functionality of the TOE.
A.Auth_PKI
PKI for Inspection Systems The issuing and receiving States or Organisations
establish a public key infrastructure for card verifiable certificates of the
Extended Access Control. The Country Verifying Certification Authorities, the
Document Verifier and Extended Inspection Systems hold authentication key
pairs and certificates for their public keys encoding the access control rights.
The Country Verifying Certification Authorities of the issuing States or
Organisations are signing the certificates of the Document Verifier and the
Document Verifiers are signing the certificates of the Extended Inspection
Systems of the receiving States or Organisations. The issuing States or
Organisations distribute the public keys of their Country Verifying Certification
Authority to their travel document’s chip.
Justification: This assumption only concerns the EAC part of the TOE. The
issuing and use of card verifiable certificates of the Extended Access Control is
neither relevant for the PACE part of the TOE nor will the security objectives of
the [PACE-PP] be restricted by this assumption. For the EAC functionality of the
TOE the assumption is necessary because it covers the pre-requisite for
performing the Terminal Authentication Protocol Version 1.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 32/119
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
This chapter describes the security objectives for the TOE and the security
objectives for the TOE environment. The security objectives for the TOE
environment are separated into security objectives for the development and
production environment and security objectives for the operational environment.
4.1 Security Objectives for the TOE
This section describes the security objectives for the TOE addressing the aspects
of identified threats to be countered by the TOE and organizational security policies
to be met by the TOE.
4.1.1 Security Objectives listed in PP PACE
OT.Data_Integrity
Integrity of Data
The TOE must ensure integrity of the User Data and the TSF-data stored on it
by protecting these data against unauthorised modification (physical
manipulation and unauthorised modifying). The TOE must ensure integrity of
the User Data and the TSF-data during their exchange between the TOE and the
terminal connected (and represented by PACE authenticated BIS-PACE) after
the PACE Authentication.
OT.Data_Authenticity
Authenticity of Data
The TOE must ensure authenticity of the User Data and the TSF-data stored on
it by enabling verification of their authenticity at the terminal-side. The TOE
must ensure authenticity of the User Data and the TSF-data during their
exchange between the TOE and the terminal connected (and represented by
PACE authenticated BIS-PACE)after the PACE Authentication. It shall happen by
enabling such a verification at the terminal-side (at receiving by the terminal)
and by an active verification by the TOE itself (at receiving by the TOE).
OT.Data_Confidentiality
Confidentiality of Data
The TOE must ensure confidentiality of the User Data and the TSF-data by
granting read access only to the PACE authenticated BIS-PACE connected. The
TOE must ensure confidentiality of the User Data and the TSF-data during their
exchange between the TOE and the terminal connected (and represented by
PACE authenticated BIS-PACE) after the PACE Authentication.
OT.Tracing
Tracing travel document
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 33/119
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 must prevent gathering TOE tracing data by means of unambiguous
identifying the travel document remotely through establishing or listening to a
communication via the contactless/contact interface of the TOE without
knowledge of the correct values of shared passwords (PACE passwords) in
advance.
OT.Prot_Abuse-Func
Protection against Abuse of Functionality
The TOE must prevent that functions of the TOE, which may not be used in TOE
operational phase, can be abused in order (i) to manipulate or to disclose the
User Data stored in the TOE, (ii) to manipulate or to disclose the TSF-data stored
in the TOE, (iii) to manipulate (bypass, deactivate or modify) soft-coded security
functionality of the TOE.
OT.Prot_Inf_Leak
Potection against Information Leakage The TOE must provide protection
against disclosure of confidential User Data or/and TSF-data stored and/or
processed by the travel document
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,
by forcing a malfunction of the TOE and/or
by a physical manipulation of the TOE.
OT.Prot_Phys-Tamper
Protection against Physical Tampering
The TOE must provide protection the confidentiality and integrity of the User
Data, the TSF Data, and the MRTD’s chip Embedded Software. This includes
protection against attacks with high 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
Protection against Malfunctions
The TOE must ensure its correct operation. The TOE must prevent its operation
outside the normal operating conditions where reliability and secure operation
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 34/119
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.
have not been proven or tested. This is to prevent functional errors in the TOE.
The environmental conditions may include external energy (especially
electromagnetic) fields, voltage (on any contacts), clock frequency or
temperature.
OT.Identification
Identification and Authentication of the TOE
The TOE must provide means to store Initialisation and Pre-Personalisation Data
in its non-volatile memory. The Initialisation Data must provide a unique
identification of the IC during the manufacturing and the card issuing life cycle
phases of the travel document. The storage of the Pre-Personalisation data
includes writing of the Personalisation Agent Key(s).
OT.AC_Pers
Access Control for Personalisation of logical MRTD
The TOE must ensure that the logical travel document data in EF.DG1 to
EF.DG16, the Document Security Object according to LDS [ICAO-9303] and the
TSF data can be written by authorized Personalisation Agents only. The logical
travel document data in EF.DG1 to EF.DG16 and the TSF data may be written
only during and cannot be changed after personalisation of the document.
4.1.2 Additional Security Objectives from PP EAC
OT.Sens_Data_Conf
Confidentiality of sensitive biometric reference data
The TOE must ensure the confidentiality of the sensitive biometric reference
data (EF.DG3 and EF.DG4) by granting read access only to authorized Extended
Inspection Systems. The authorization of the inspection system is drawn from
the Inspection System Certificate used for the successful authentication and
shall be a non-strict subset of the authorization defined in the Document Verifier
Certificate in the certificate chain to the Country Verifier Certification Authority
of the issuing State or Organisation. The TOE must ensure the confidentiality of
the logical travel document data during their transmission to the Extended
Inspection System. The confidentiality of the sensitive biometric reference data
shall be protected against attacks with high attack potential.
OT.Chip_Auth_Proof
Proof of the travel document's chip authenticity
The TOE must support the Inspection Systems to verify the identity and
authenticity of the travel document’s chip as issued by the identified issuing
State or Organisation by means of the Chip Authentication Version 1 as defined
in [TR-03110-1]. The authenticity proof provided by travel document’s chip shall
be protected against attacks with high attack potential.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 35/119
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.2 Security Objectives for the Operational Environment
4.2.1 Issuing State or Organisation
The Issuing State or Organization will implement the following security objectives
of the TOE environment.
OE.Legislative_Compliance
Issuing of the travel document
The travel document Issuer must issue the travel document and approve it using
the terminals complying with all applicable laws and regulations.
OE.Auth_Key_Travel_Document
Travel document Authentication Key
The issuing State or Organisation has to establish the necessary public key
infrastructure in order to (i) generate the travel document’s Chip Authentication
Key Pair, (ii) sign and store the Chip Authentication Public Key in the Chip
Authentication Public Key data in EF.DG14 and (iii) support inspection systems
of receiving States or Organisations to verify the authenticity of the travel
document’s chip used for genuine travel document by certification of the Chip
Authentication Public Key by means of the Document Security Object.
Justification: This security objective for the operational environment is needed
additionally to those from [PACE-PP] in order to counter the Threat T.Counterfeit
as it specifies the pre-requisite for the Chip Authentication Protocol Version 1
which is one of the additional features of the TOE described only in [EAC-PP-V2]
and not in [PACE-PP].
OE.Authoriz_Sens_Data
Authorization for Use of Sensitive Biometric Reference Data
The issuing State or Organisation has to establish the necessary public key
infrastructure in order to limit the access to sensitive biometric reference data
of travel document holders to authorized receiving States or Organisations. The
Country Verifying Certification Authority of the issuing State or Organisation
generates card verifiable Document Verifier Certificates for the authorized
Document Verifier only.
Justification: This security objective for the operational environment is needed
additionally to those from [PACE-PP] in order to handle the Threat
T.Read_Sensitive_Data, the Organisational Security Policy P.Sensitive_Data and
the Assumption A.Auth_PKI as it specifies the pre-requisite for the Terminal
Authentication Protocol v.1 as it concerns the need of an PKI for this protocol
and the responsibilities of its root instance. The Terminal Authentication Protocol
v.1 is one of the additional features of the TOE described only in [EAC-PP-V2]
and not in [PACE-PP].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 36/119
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.2.2 Travel document Issuer and CSCA: travel document PKI
(issuing) branch
The travel document Issuer and the related CSCA will implement the following
security objectives for the TOE environment (see also the PACE PP Application Note
20):
OE.Passive_Auth_Sign
Authentication of travel document by Signature.
The travel document Issuer has to establish the necessary public key
infrastructure as follows: the CSCA acting on behalf and according to the policy
of the travel document Issuer must
(i) generate a cryptographically secure CSCA Key Pair,
(ii) ensure the secrecy of the CSCA Private Key and sign Document Signer
Certificates in a secure operational environment, and
(iii) publish the Certificate of the CSCA Public Key (CCSCA). Hereby
authenticity and integrity of these certificates are being maintained.
A Document Signer acting in accordance with the CSCA policy must
(i) generate a cryptographically secure Document Signing Key Pair,
(ii) ensure the secrecy of the Document Signer Private Key,
(iii) hand over the Document Signer Public Key to the CSCA for certification,
(iv) sign Document Security Objects of genuine travel documents in a secure
operational environment only.
The digital signature in the Document Security Object relates to all hash values
for each data group in use according to [ICAO-9303].The Personalisation Agent
has to ensure that the Document Security Object contains only the hash values
of genuine user data according to [ICAO-9303]. The CSCA must issue its
certificates exclusively to the rightful organisations (DS) and DSs must sign
exclusively correct Document Security Objects to be stored on travel document.
OE.Personalisation
Personalisation of travel document
The travel document Issuer must ensure that the Personalisation Agents acting
on his behalf
(i) establish the correct identity of the travel document holder and create
the biographical data for the travel document,
(ii) enroll the biometric reference data of the travel document holder,
(iii) write a subset of these data on the physical Passport (optical
personalisation) and store them in the travel document (electronic
personalisation) for the travel document holder as defined in [ICAO-
9303],
(iv) write the document details data,
(v) write the initial TSF data,
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 37/119
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.
(vi) sign the Document Security Object defined in [ICAO-9303] (in the role
of a DS).
4.2.3 Terminal operator: Terminal receiving branch
OE.Terminal
Terminal operating
The terminal operators must operate their terminals as follows:
1.) The related terminals (basic inspection systems, cf. above) are used by
terminal operators and by travel document holders as defined in [ICAO-
9303].
2.) The related terminals implement the terminal parts of the PACE protocol
[ICAO-SAC], of the Passive Authentication [ICAO-SAC](by verification of
the signature of the Document Security Object) and use them in this
order. The PACE terminal uses randomly and (almost) uniformly selected
nonces, if required by the protocols (for generating ephemeral keys for
Diffie-Hellmann).
3.) The related terminals need not to use any own credentials.
4.) The related terminals securely store the Country Signing Public Key and
the Document Signer Public Key (in form of CCSCA and CDS) in order to
enable and to perform Passive Authentication of the travel document
(determination of the authenticity of data groups stored in the travel
document, [ICAO-9303]).
5.) The related terminals and their environment must ensure confidentiality
and integrity of respective data handled by them (e.g. confidentiality of
the PACE passwords, integrity of PKI certificates, etc.), where it is
necessary for a secure operation of the TOE according to the current PP.
Application Note:
OE.Terminal completely covers and extends “OE.Exam_MRTD”,
“OE.Passive_Auth_Verif“ and “OE.Prot_Logical_MRTD” from BAC PP [BAC-PP].
4.2.4 Travel document holder Obligations
OE.Travel_Document_Holder
Travel document holder Obligations
The travel document holder may reveal, if necessary, his or her verification
values of the PACE password to an authorized person or device who definitely
act according to respective regulations and are trustworthy.
4.2.5 Receiving State or Organisation
OE.Exam_Travel_Document
Examination of the physical part of the travel document
The inspection system of the receiving State or Organisation must examine the
travel document presented by the traveler to verify its authenticity by means of
the physical security measures and to detect any manipulation of the physical
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 38/119
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.
part of the travel document. The Basic Inspection System for global
interoperability (i) includes the Country Signing CA Public Key and the Document
Signer Public Key of each issuing State or Organisation, and (ii) implements the
terminal part of PACE [ICAO-SAC]and/or the Basic Access Control [ICAO-
9303].Extended Inspection Systems perform additionally to these points the
Chip Authentication Protocol Version 1toverify the Authenticity of the presented
travel document’s chip.
Justification: This security objective for the operational environment is needed
additionally to those from [PACE-PP] in order to handle the Threat T.Counterfeit
and the Assumption A.Insp_Sys by demanding the Inspection System to
perform the Chip Authentication protocolv.1. OE.Exam_Travel_Document also
repeats partly the requirements from OE.Terminal in [PACE-PP] and therefore
also counters T.Forgery and A. Passive_Auth from [PACE-PP]. This is done
because a new type of Inspection System is introduced in this PP as the
Extended Inspection System is needed to handle the additional features of a
travel document with Extended Access Control.
OE.Prot_Logical_Travel_Document
Protection of data from the logical travel document
The inspection system of the receiving State or Organisation ensures the
confidentiality and integrity of the data read from the logical travel document.
The inspection system will prevent eavesdropping to their communication with
the TOE before secure messaging is successfully established based on the Chip
Authentication Protocol Version 1.
Justification: This security objective for the operational environment is needed
additionally to those from [PACE-PP]in order to handle the Assumption
A.Insp_Sys by requiring the Inspection System to perform secure messaging
based on the Chip Authentication Protocol v.1.
OE.Ext_Insp_Systems
Authorization of Extended Inspection Systems
The Document Verifier of receiving States or Organisations authorizes Extended
Inspection Systems by creation of Inspection System Certificates for access to
sensitive biometric reference data of the logical travel document. The Extended
Inspection System authenticates themselves to the travel document’s chip for
access to the sensitive biometric reference data with its private Terminal
Authentication Key and its Inspection System Certificate.
Justification: This security objective for the operational environment is needed
additionally to those from [PACE-PP] in order to handle the Threat
T.Read_Sensitive_Data, the Organisational Security Policy P.Sensitive_Data and
the Assumption A. Auth_PKI as it specifies the pre-requisite for the Terminal
Authentication Protocol v.1 as it concerns the responsibilities of the Document
Verifier instance and the Inspection Systems.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 39/119
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.3 Security Objectives Rationale
4.3.1 Threats
4.3.1.1 Threats listed in PP PACE
T.Skimming addresses accessing the User Data (stored on the TOE or transferred
between the TOE and the terminal) using the TOE's contactless/contact
interface. This threat is countered by the security objectives OT.Data_Integrity,
OT.Data_Authenticity and OT.Data_Confidentiality through the PACE
authentication. The objective OE.Travel_Document_Holder ensures that a PACE
session can only be established either by the travel document holder itself or by
an authorised person or device, and, hence, cannot be captured by an attacker.
T.Eavesdropping addresses listening to the communication between the TOE and
a rightful terminal in order to gain the User Data transferred there. This threat
is countered by the security objective OT.Data_Confidentiality through a trusted
channel based on the PACE authentication.
T.Tracing addresses gathering TOE tracing data identifying it remotely by
establishing or listening to a communication via the contactless/contact
interface of the TOE, whereby the attacker does not a priori know the correct
values of the PACE password. This threat is directly countered by security
objectives OT.Tracing (no gathering TOE tracing data) and
OE.Travel_Document_Holder (the attacker does not a priori know the correct
values of the shared passwords).
T.Forgery 'Forgery of data' addresses the fraudulent, complete or partial
alteration of the User Data or/and TSF-data stored on the TOE or/and exchanged
between the TOE and the terminal. Additionally to the security objectives from
PACE PP [PACE-PP] which counter this threat, the examination of the presented
MRTD passport book according to OE.Exam_Travel_Document 'Examination of
the physical part of the travel document' shall ensure its authenticity by means
of the physical security measures and detect any manipulation of the physical
part of the travel document.
The threat T.Forgery also addresses the fraudulent, complete or partial
alteration of the User Data or/and TSF-data stored on the TOE or/and exchanged
between the TOE and the terminal. The security objective OT.AC_Pers requires
the TOE to limit the write access for the travel document to the trustworthy
Personalisation Agent (cf. OE.Personalisation). The TOE will protect the integrity
and authenticity of the stored and exchanged User Data or/and TSF-data as
aimed by the security objectives OT.Data_Integrity and OT.Data_Authenticity,
respectively. The objectives OT.Prot_Phys-Tamper and OT.Prot_Abuse-Func
contribute to protecting integrity of the User Data or/and TSF-data stored on
the TOE. A terminal operator operating his terminals according to OE.Terminal
and performing the Passive Authentication using the Document Security Object
as aimed by OE.Passive_Auth_Sign will be able to effectively verify integrity and
authenticity of the data received from the TOE.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 40/119
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.
T.Abuse-Func addresses attacks of misusing TOE's functionality to manipulate or
to disclosure the stored User- or TSF-data as well as to disable or to bypass the
soft-coded security functionality. The security objective OT.Prot_Abuse-Func
ensures that the usage of functions having not to be used in the operational
phase is effectively prevented.
T.Information_Leakage is typical for integrated circuits like smart cards under
direct attack with high attack potential. The protection of the TOE against this
threat is obviously addressed by the directly related security objective
OT.Prot_Inf_Leak.
T.Phys-Tamper is typical for integrated circuits like smart cards under direct
attack with high attack potential. The protection of the TOE against this threat
is obviously addressed by the directly related security objective OT.Prot_Phys-
Tamper.
T.Malfunction is typical for integrated circuits like smart cards under direct attack
with high attack potential. The protection of the TOE against this threat is
obviously addressed by the directly related security objective
OT.Prot_Malfunction.
4.3.1.2 Additional Threats
T.Read_Sensitive_Data The threat T.Read_Sensitive_Data 'Read the sensitive
biometric reference data' is countered by the TOE-objective OT.Sens_Data_Conf
'Confidentiality of sensitive biometric reference data' requiring that read access
to EF.DG3 and EF.DG4 (containing the sensitive biometric reference data) is
only granted to authorized inspection systems. Furthermore it is required that
the transmission of these data ensures the data's confidentiality. The
authorization bases on Document Verifier certificates issued by the issuing State
or Organisation as required by OE.Authoriz_Sens_Data 'Authorization for use of
sensitive biometric reference data'. The Document Verifier of the receiving State
has to authorize Extended Inspection Systems by creating appropriate
Inspection System certificates for access to the sensitive biometric reference
data as demanded by OE.Ext_Insp_Systems 'Authorization of Extended
Inspection Systems'.
T.Counterfeit 'Counterfeit of travel document chip data' addresses the attack of
unauthorized copy or reproduction of the genuine travel document's chip. This
attack is thwarted by chip identification and authenticity proof required by
OT.Chip_Auth_Proof 'Proof of travel document's chip authentication' using an
authentication key pair to be generated by the issuing State or Organisation.
The Public Chip Authentication Key has to be written into EF.DG14 and signed
by means of Documents Security Objects as demanded by
OE.Auth_Key_Travel_Document 'Travel document Authentication Key'.
According to OE.Exam_Travel_Document 'Examination of the physical part of
the travel document' the General Inspection system has to perform the Chip
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 41/119
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 Protocol Version 1 to verify the authenticity of the travel
document's chip.
4.3.2 Organisational Security Policies
4.3.2.1 OSP listed in PP PACE
P.Manufact requires a unique identification of the IC by means of the Initialization
Data and the writing of the Pre-personalisation Data as being fulfilled by
OT.Identification.
P.Pre-Operational is enforced by the following security objectives:
OT.Identification is affine to the OSP's property 'traceability before the
operational phase; OT.AC_Pers and OE.Personalisation together enforce the
OSP's properties 'correctness of the User and the TSF-data stored' and
'authorisation of Personalisation Agents'; OE.Legislative_Compliance is affine to
the OSP's property 'compliance with laws and regulations'.
P.Card_PKI is enforced by establishing the issuing PKI branch as aimed by the
objectives OE.Passive_Auth_Sign (for the Document Security Object).
P.Trustworthy_PKI is enforced by OE.Passive_Auth_Sign (for CSCA, issuing PKI
branch).
P.Terminal 'Abilities and trustworthiness of terminals' is countered by the security
objective OE.Exam_Travel_Document additionally to the security objectives
from PACE PP [PACE-PP]. OE.Exam_Travel_Document enforces the terminals to
perform the terminal part of the PACE protocol.
The OSP P.Terminal is obviously enforced by the objective OE.Terminal,
whereby the one-to-one mapping between the related properties is applicable.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 42/119
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.3.2.2 Additional OSPs from PP EAC
P.Sensitive_Data 'Privacy of sensitive biometric reference data' is fulfilled and
the threat T.Read_Sensitive_Data 'Read the sensitive biometric reference data'
is countered by the TOE-objective OT.Sens_Data_Conf 'Confidentiality of
sensitive biometric reference data' requiring that read access to EF.DG3 and
EF.DG4 (containing the sensitive biometric reference data) is only granted to
authorized inspection systems. Furthermore it is required that the transmission
of these data ensures the data's confidentiality. The authorization bases on
Document Verifier certificates issued by the issuing State or Organisation as
required by OE.Authoriz_Sens_Data 'Authorization for use of sensitive biometric
reference data'. The Document Verifier of the receiving State has to authorize
Extended Inspection Systems by creating appropriate Inspection System
certificates for access to the sensitive biometric reference data as demanded by
OE.Ext_Insp_Systems 'Authorization of Extended Inspection Systems'.
P.Personalisation 'Personalisation of the travel document by issuing State or
Organisation only' addresses the (i) the enrolment of the logical travel document
by the Personalisation Agent as described in the security objective for the TOE
environment OE.Personalisation 'Personalisation of logical travel document', and
(ii) the access control for the user data and TSF data as described by the security
objective OT.AC_Pers 'Access Control for Personalisation of logical travel
document'. Note the manufacturer equips the TOE with the Personalisation
Agent Key(s) according to OT.Identification 'Identification and Authentication of
the TOE'. The security objective OT.AC_Pers limits the management of TSF data
and the management of TSF to the Personalisation Agent.
4.3.3 Assumptions
A.Passive_Auth The assumption A.Passive_Auth 'PKI for Passive Authentication'
is directly covered by the security objective for the TOE environment
OE.Passive_Auth_Sign 'Authentication of travel document by Signature' from
PACE PP [PACE-PP] covering the necessary procedures for the Country Signing
CA Key Pair and the Document Signer Key Pairs. The implementation of the
signature verification procedures is covered by OE.Exam_Travel_Document
'Examination of the physical part of the travel document'.
A.Insp_Sys The examination of the travel document addressed by the assumption
A.Insp_Sys 'Inspection Systems for global interoperability' is covered by the
security objectives for the TOE environment OE.Exam_Travel_Document
'Examination of the physical part of the travel document' which requires the
inspection system to examine physically the travel document, the Basic
Inspection System to implement the Basic Access Control, and the Extended
Inspection Systems to implement and to perform the Chip Authentication
Protocol Version 1 to verify the Authenticity of the presented travel document's
chip. The security objectives for the TOE environment
OE.Prot_Logical_Travel_Document 'Protection of data from the logical travel
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 43/119
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.
document' require the Inspection System to protect the logical travel document
data during the transmission and the internal handling.
A.Auth_PKI 'PKI for Inspection Systems' is covered by the security objective for
the TOE environment OE.Authoriz_Sens_Data 'Authorization for use of sensitive
biometric reference data' requires the CVCA to limit the read access to sensitive
biometrics by issuing Document Verifier certificates for authorized receiving
States or Organisations only. The Document Verifier of the receiving State is
required by OE.Ext_Insp_Systems 'Authorization of Extended Inspection
Systems' to authorize Extended Inspection Systems by creating Inspection
System Certificates. Therefore, the receiving issuing State or Organisation has
to establish the necessary public key infrastructure.
4.3.4 SPD and Security Objectives
Threats Security Objectives Rationale
T.Skimming
OT.Data_Integrity, OT.Data_Authenticity,
OT.Data_Confidentiality,
OE.Travel_Document_Holder
4.3.1.1
T.Eavesdropping OT.Data_Confidentiality 4.3.1.1
T.Tracing OT.Tracing, OE.Travel_Document_Holder 4.3.1.1
T.Forgery
OT.AC_Pers, OT.Data_Integrity,
OT.Data_Authenticity, OT.Prot_Abuse-
Func, OT.Prot_Phys-Tamper,
OE.Personalisation, OE.Passive_Auth_Sign,
OE.Terminal, OE.Exam_Travel_Document
4.3.1.1
T.Abuse-Func OT.Prot_Abuse-Func 4.3.1.1
T.Information_Leakage OT.Prot_Inf_Leak 4.3.1.1
T.Phys-Tamper OT.Prot_Phys-Tamper 4.3.1.1
T.Malfunction OT.Prot_Malfunction 4.3.1.1
T.Read_Sensitive_Data
OT.Sens_Data_Conf,
OE.Authoriz_Sens_Data,
OE.Ext_Insp_Systems
4.3.1.2
T.Counterfeit
OT.Chip_Auth_Proof,
OE.Auth_Key_Travel_Document,
OE.Exam_Travel_Document
4.3.1.2
Table 1 Threats and Security Objectives - Coverage
Security Objectives Threats
OT.Data_Integrity T.Skimming, T.Forgery
OT.Data_Authenticity T.Skimming, T.Forgery
OT.Data_Confidentiality T.Skimming, T.Eavesdropping
OT.Tracing T.Tracing
OT.Prot_Abuse-Func T.Forgery, T.Abuse-Func
OT.Prot_Inf_Leak T.Information_Leakage
OT.Prot_Phys-Tamper T.Forgery, T.Phys-Tamper
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 44/119
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_Malfunction T.Malfunction
OT.Identification
OT.AC_Pers T.Forgery
OT.Sens_Data_Conf T.Read_Sensitive_Data
OT.Chip_Auth_Proof T.Counterfeit
OE.Legislative_Compliance
OE.Auth_Key_Travel_Document T.Counterfeit
OE.Authoriz_Sens_Data T.Read_Sensitive_Data
OE.Passive_Auth_Sign T.Forgery
OE.Personalisation T.Forgery
OE.Terminal T.Forgery
OE.Travel_Document_Holder T.Skimming, T.Tracing
OE.Exam_Travel_Document T.Forgery, T.Counterfeit
OE.Ext_Insp_Systems T.Read_Sensitive_Data
Table 2 Security Objectives and Threats - Coverage
Organisational
Security Policies
Security Objectives Rationale
P.Manufact OT.Identification 4.3.2.1
P.Pre-Operational
OT.Identification, OT.AC_Pers,
OE.Personalisation,
OE.Legislative_Compliance
4.3.2.1
P.Card_PKI OE.Passive_Auth_Sign 4.3.2.1
P.Trustworthy_PKI OE.Passive_Auth_Sign 4.3.2.1
P.Terminal
OE.Terminal,
OE.Exam_Travel_Document
4.3.2.1
P.Sensitive_Data
OT.Sens_Data_Conf,
OE.Authoriz_Sens_Data,
OE.Ext_Insp_Systems
4.3.2.2tok113
P.Personalisation
OT.AC_Pers, OT.Identification,
OE.Personalisation
4.3.2.2
Table 3 OSPs and Security Objectives - Coverage
Security Objectives
Organisational Security
Policies
OT.Data_Integrity
OT.Data_Authenticity
OT.Data_Confidentiality
OT.Tracing
OT.Prot_Abuse-Func
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfunction
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 45/119
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.Identification
P.Manufact, P.Pre-
Operational,
P.Personalisation
OT.AC_Pers
P.Pre-Operational,
P.Personalisation
OT.Sens_Data_Conf P.Sensitive_Data
OT.Chip_Auth_Proof
OE.Legislative_Compliance P.Pre-Operational
OE.Auth_Key_Travel_Document
OE.Authoriz_Sens_Data P.Sensitive_Data
OE.Passive_Auth_Sign
P.Card_PKI,
P.Trustworthy_PKI
OE.Personalisation
P.Pre-Operational,
P.Personalisation
OE.Terminal P.Terminal
OE.Travel_Document_Holder
OE.Exam_Travel_Document P.Terminal
OE.Prot_Logical_Travel_Document
OE.Ext_Insp_Systems P.Sensitive_Data
Table 4 Security Objectives and OSPs - Coverage
Assumptions
Security Objectives for the Operational
Environment
Rationale
A.Passive_Auth
OE.Passive_Auth_Sign,
OE.Exam_Travel_Document
4.3.3
A.Insp_Sys
OE.Exam_Travel_Document,
OE.Prot_Logical_Travel_Document
4.3.3
A.Auth_PKI OE.Authoriz_Sens_Data, OE.Ext_Insp_Systems 4.3.3
Table 5 Assumptions and Security Objectives for the Operational Environment -
Coverage
Security Objectives for the Operational
Environment
Assumptions
OE.Legislative_Compliance
OE.Auth_Key_Travel_Document
OE.Authoriz_Sens_Data A.Auth_PKI
OE.Passive_Auth_Sign A.Passive_Auth
OE.Personalisation
OE.Terminal
OE.Travel_Document_Holder
OE.Exam_Travel_Document
A.Passive_Auth,
A.Insp_Sys
OE.Prot_Logical_Travel_Document A.Insp_Sys
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 46/119
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.Ext_Insp_Systems A.Auth_PKI
Table 6 Security Objectives for the Operational Environment and Assumptions -
Coverage
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 47/119
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 Extended Family FCS_RND - Generation of random
numbers
Description
To define the IT security functional requirements of the TOE a sensitive 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
Family behaviour:
This family defines quality requirements for the generation of random numbers
intended to be used for cryptographic purposes.
Component levelling:
FCS_RND.1 Generation of random numbers requires that random numbers meet a defined
quality metric.
Management:
There are no management activities foreseen.
Audit:
There are no actions defined to be auditable.
Definition:
FCS_RND.1 Quality metric for random numbers
FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers
that meet [assignment: a defined quality metric ].
Dependencies: No dependencies.
FCS_RND.1 Generation of random numbers 1
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 48/119
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 Extended Family FPT_EMS - TOE emanation
Description
The family FPT_EMS (TOE Emanation) of the class FPT (Protection of the TSF) is
defined here to describe the IT security functional requirements of the TOE. The
TOE shall prevent attacks against secret data stored in and used by the TOE 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 (SPA), differential power analysis (DPA), timing attacks, etc.
Family behaviour:
This family defines requirements to mitigate intelligible emanations.
Component levelling:
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:
There are no management activities foreseen.
Audit:
There are no actions defined to be auditable.
Definition:
FPT_EMS.1 TOE Emanation
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
FPT_EMS TOE emanation 1
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 49/119
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.
[assignment: list of types of TSF data ] and [assignment: list of types of user
data ].
Dependencies: No dependencies.
5.3 Extended Family FAU_SAS - Audit data storage
Description
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.
Family behaviour:
This family describes the functional requirements for the storage of audit data.
Component levelling:
FCS_RND.1 Requires the TOE to provide the possibility to store audit data.
Management:
There are no management activities foreseen.
Audit:
There are no actions defined to be auditable.
Definition:
FAU_SAS Audit data storage 1
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 50/119
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.
FAU_SAS.1 Audit storage
FAU_SAS.1.1 The TSF shall provide [assignment: authorised users ] with the
capability to store [assignment: list of audit information ] in the audit records.
Dependencies: No dependencies.
5.4 Extended Family FIA_API - Authentication Proof of
Identity
Description
To describe the IT 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.
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 levelling:
FIA_API.1 Authentication Proof of Identity.
Management:
The following actions could 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.
Definition:
FIA_API Authentication Proof of Identity 1
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 51/119
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_API.1 Authentication Proof of Identity
FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism ]
to prove the identity of the [assignment: authorized user or role ].
Dependencies: No dependencies.
5.5 Extended Family FMT_LIM - Limited capabilities and
availability
Description
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
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.
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 lifecycle.
Management:
FMT_LIM Limited capabilities and availability
1
2
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 52/119
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.
There are no management activities foreseen.
Audit:
There are no actions defined to be auditable.
Definition:
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 [assignment: Limited capability and availability policy ]
Dependencies: (FMT_LIM.2)
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 [assignment: Limited capability and availability policy ]
Dependencies: (FMT_LIM.1)
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 53/119
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 Requirements
6.1 Security Functional Requirements
This section on security functional requirements for the TOE is divided into sub-
section following the main security functionality. Several SFRs of the PACE PP
[PACE-PP] are only listed in the EAC PP [EAC-PP-V2]. Therefore the descriptions
of these SFRs are taken directly from PACE PP into the Security target on hand
Definition of security attributes:
Security
attribute
Values Meaning
terminal
authentication
status
none (any
Terminal)
default role
CVCA
roles defined in the certificate used for
authentication (cf. [TR-03110-1]);
Terminal is authenticated as Country
Verifying Certification Authority after
successful CA v.1 and TA v.1
DV (domestic)
roles defined in the certificate used for
authentication (cf. [TR-03110-1]);
Terminal is authenticated as domestic
Document Verifier after successful CA v.1
and TA v.1
DV (foreign)
roles defined in the certificate used for
authentication (cf. [TR-03110-1]);
Terminal is authenticated as foreign
Document Verifier after successful CA v.1
and TA v.1
IS
roles defined in the certificate used for
authentication (cf. [TR-03110-1]);
Terminal is authenticated as Extended
Inspection System after successful CA v.1
and TA v.1
Terminal
Authorization
none -
DG4 (Iris) Read access to DG4: (cf. [TR-03110-1])
DG3
(Fingerprint)
Read access to DG3: (cf. [TR-03110-1])
DG3
(Fingerprint) /
DG4 (Iris)
Read access to DG3 and DG4: (cf. [TR-
03110-1])
The following table provides an overview of the keys and certificates used:
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 54/119
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.
Name Data
TOE intrinsic secret
cryptographic keys
Permanently or temporarily stored secret
cryptographic material used by the TOE in order to
enforce its security functionality.
Country Verifying
Certification Authority
Private Key (SKCVCA)
The Country Verifying Certification Authority (CVCA)
holds a private key (SKCVCA) used for signing the
Document Verifier Certificates.
Country Verifying
Certification Authority
Public Key (PKCVCA)
The TOE stores the Country Verifying Certification
Authority Public Key (PKCVCA) as part of the TSF
data to verify the Document Verifier Certificates. The
PKCVCA has the security attribute Current Date as
the most recent valid effective date of the Country
Verifying Certification Authority Certificate or of a
domestic Document Verifier Certificate.
Country Verifying
Certification Authority
Certificate (CCVCA)
The Country Verifying Certification Authority
Certificate may be a self-signed certificate or a link
certificate (cf. [TR-03110-1] and Glossary). It
contains (i) the Country Verifying Certification
Authority Public Key (PKCVCA) as authentication
reference data, (ii) the coded access control rights of
the Country Verifying Certification Authority, (iii) the
Certificate Effective Date and the Certificate
Expiration Date as security attributes.
Document Verifier
Certificate (CDV)
The Document Verifier Certificate CDV is issued by
the Country Verifying Certification Authority. It
contains (i) the Document Verifier Public Key (PKDV)
as authentication reference data (ii) identification as
domestic or foreign Document Verifier, the coded
access control rights of the Document Verifier, the
Certificate Effective Date and the Certificate
Expiration Date as security
Inspection System
Certificate (CIS)
The Inspection System Certificate (CIS) is issued by
the Document Verifier. It contains (i) as
authentication reference data the Inspection System
Public Key (PKIS), (ii) the coded access control rights
of the Extended Inspection System, the Certificate
Effective Date and the Certificate Expiration Date as
security attributes.
Chip Authentication
Public Key Pair
The Chip Authentication Public Key Pair (SKICC,
PKICC) are used for Key Agreement Protocol: Diffie-
Hellman (DH) according to RFC 2631 or Elliptic Curve
Diffie-Hellman according to ISO 15946.
Chip Authentication
Public Key (PKICC)
The Chip Authentication Public Key (PKICC) is stored
in the EF.DG14 Chip Authentication Public Key of the
TOE’s logical travel document and used by the
inspection system for Chip Authentication v.1 of the
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 55/119
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’s chip. It is part of the user data
provided by the TOE for the IT environment.
Chip Authentication
Private Key (SKICC)
The Chip Authentication Private Key (SKICC) is used
by the TOE to authenticate itself as authentic travel
document’s chip. It is part of the TSF data.
Country Signing
Certification Authority
Key Pair and Certificate
Country Signing Certification Authority of the Issuing
State or Organization signs the Document Signer
Public Key Certificate(CDS) with the Country Signing
Certification Authority Private Key (SKCSCA)and the
signature will be verified by Receiving State or
Organization (e.g. an Extended Inspection System)
with the Country Signing Certification Authority
Public Key (PKCSCA). The CSCA also issues the self-
signed CSCA Certificate (CCSCA) to be distributed by
strictly secure diplomatic means, see [ICAO-9303],
5.5.1.
Document Signer Key
Pairs and Certificates
The Document Signer Certificate CDS is issued by
the Country Signing Certification Authority. It
contains the Document Signer Public Key (PKDS) as
authentication reference data. The Document Signer
acting under the policy of the CSCA signs the
Document Security Object (SOD) of the travel
document with the Document Signer Private Key
(SKDS) and the signature will be verified by a
terminal as the Passive Authentication with the
Document Signer Public Key (PKDS)
Chip Authentication
Session Key
Secure messaging encryption key and MAC
computation key agreed between the TOE and an
Inspection System in result of the Chip
Authentication Protocol Version 1.
PACE Session Keys
(PACE-KMAC, PACE-
KEnc)
Secure messaging AES keys for message
authentication (CMAC-mode) and for message
encryption (CBC-mode) or3DES Keys for message
authentication and message encryption (both CBC)
agreed between the TOE and a terminal as result of
the PACE Protocol, see [ICAO_SAC].
PACE authentication
ephemeral key pair
(ephem-SKPICC-
PACE,ephem-PKPICC-
PACE)
The ephemeral PACE Authentication Key Pair
(ephem-SKPICC-PACE, ephem-PKPICC-PACE) is used
for Key Agreement Protocol: Diffie-Hellman (DH)
according to PKCS#3 or Elliptic Curve Diffie-Hellman
(ECDH; ECKA key agreement algorithm) according to
TR-03111 [TR-03111], cf. [ICAO_SAC].
6.1.1 Class Cryptographic Support (FCS)
The TOE shall meet the requirement “Cryptographic key generation (FCS_CKM.1)”
as specified below (Common Criteria Part 2). The iterations are caused by different
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 56/119
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.
cryptographic key generation algorithms to be implemented and key to be
generated by the TOE.
6.1.1.1 Cryptographic key generation (FCS_CKM.1)
FCS_CKM.1/DH_PACE Cryptographic key generation
FCS_CKM.1.1/DH_PACE The TSF shall generate cryptographic keys in
accordance with a specified cryptographic key generation algorithm ECDH
compliant to [TR-03111] and specified cryptographic key sizes 192,
224,256 and 320 bits in combination with 112 bits 3DES or 128, 192 or
256 bits AES that meet the following: [ICAO-SAC].
FCS_CKM.1/CA Cryptographic key generation
FCS_CKM.1.1/CA [Editorially Refined] The TSF shall generate cryptographic
keys in accordance with the specified cryptographic key generation algorithm
Chip Authentication Protocol Version 1[TR-03110-1] based on the ECDH
protocol compliant to [TR-03111] with specified cryptographic key sizes
192, 224, 256, 320 bits in combination with 112 bits 3DES or 128, 192
or 256 bits AES
and
based on the Diffie-Hellman protocol compliant to [RSA-PKCS3] and
[TR-03110-1] with specified cryptographic key size of 2048 bits in
combination with 112 bits 3DES or 128, 192 or 256 bits AES
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 physically overwriting the
keys that meets the following: none.
6.1.1.2 Cryptographic operation (FCS_COP.1)
FCS_COP.1/PACE_ENC Cryptographic operation
FCS_COP.1.1/PACE_ENC The TSF shall perform secure messaging -
encryption and decryption
in accordance with a specified cryptographic algorithm 3DES and AES in CBC
mode and cryptographic key sizes respectively 112 and 128, 192 and 256
that meet the following: compliant to [ICAO-SAC].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 57/119
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/PACE_MAC Cryptographic operation
FCS_COP.1.1/PACE_MAC The TSF shall perform secure messaging -
message authentication code
in accordance with a specified cryptographic algorithm Retail-MAC and CMAC
and cryptographic key sizes respectively 112 and 128, 192, 256 that meet
the following: compliant to [ICAO-SAC].
FCS_COP.1/CA_ENC Cryptographic operation
FCS_COP.1.1/CA_ENC The TSF shall perform secure messaging encryption
and decryption in accordance with a specified cryptographic algorithm 3DES
and AES in CBC mode and cryptographic key sizes respectively 112 and
128, 192 and 256 that meet the following: [TR-03110-1].
FCS_COP.1/SIG_VER Cryptographic operation
FCS_COP.1.1/SIG_VER The TSF shall perform digital signature verification
in accordance with a specified cryptographic algorithm ECDSA and
cryptographic key sizes 192, 224 and 256 bits that meet the following:
ISO15946-2 specified in [ISO15946-2],in combination SHA1, SHA224,
SHA256, SHA384, SHA512 digest algorithms.
FCS_COP.1/SIG_GEN Cryptographic operation
FCS_COP.1.1/SIG_GEN The TSF shall perform digital signature generation
in accordance with a specified cryptographic algorithm ECDSA and RSA and
cryptographic key sizes 192, 224, 256 and 320 bits for ECDSA and 1024,
1536, 1792 and 2048 bits for RSA that meet the following: ISO15946-2
specified in [ISO15946-2] for ECDSA and ISO9796-2 specified in
[ISO9796-2] for RSA, in combination with SHA1, SHA224, SHA256,
SHA384 and SHA512 digest algorithms specified in [NIST-180-4] for
both ECDSA and RSA signatures.
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 [ICAO-9303].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 58/119
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/CA_MAC Cryptographic operation
FCS_COP.1.1/CA_MAC The TSF shall perform secure messaging message
authentication code in accordance with a specified cryptographic algorithm
3DES Retail-MAC and AES CMAC and cryptographic key sizes 112 bits 3DES
and 128, 192 and 256 bits AES that meet the following: [ICAO-9303] for
3DES Retail-MAC and [NIST-800-38B] for AES CMAC.
6.1.1.3 Random Number Generation (FCS_RND.1)
FCS_RND.1 Quality metric for random numbers
FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers
that meet AIS31 Class P2 quality metric.
Application Note:
7 Application Note: This SFR was added to the standard set of SFRs to address the
requirements of the PACE protocol. The random number generation is provided by the
underlying platform.
7.1.1 Class FIA Identification and Authentication
FIA_AFL.1/PACE Authentication failure handling
FIA_AFL.1.1/PACE The TSF shall detect when 3 unsuccessful authentication
attempts occur related to authentication attempts using the PACE
password as shared password.
FIA_AFL.1.2/PACE When the defined number of unsuccessful authentication
attempts has been met, the TSF shall wait an administrator configurable
time, with a minimum of 1 second, before the next authentication
attempt can be performed.
FIA_UID.1/PACE Timing of identification
FIA_UID.1.1/PACE The TSF shall allow
1. to establish the communication channel,
2. carrying out the PACE Protocol according to [ICAO-SAC],
3. to read the Initialisation Data if it is not disabled by TSF, according
to FMT_MTD.1/INI_DIS,
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 59/119
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. to carry out the Chip Authentication Protocol v.1 according to [TR-
03110-1],
5. to carry out the Terminal Authentication Protocol v.1] according to
[TR-03110-1],
6. None
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2/PACE The TSF shall require each user to be successfully identified
before allowing any other TSF-mediated actions on behalf of that user.
FIA_UAU.1/PACE Timing of authentication
FIA_UAU.1.1/PACE The TSF shall allow
1. to establish the communication channel,
2. carrying out the PACE Protocol according to [ICAO-SAC],
3. to read the Initialisation Data if it is not disabled by TSF, according
to FMT_MTD.1/INI_DIS,
4. to identify themselves by selection of the authentication key
5. to carry out the Chip Authentication Protocol v.1 according to [TR-
03110-1],
6. to carry out the Terminal Authentication Protocol v.1] according to
[TR-03110-1],
7. to carry out Personalisation Agent Authentication based on a
symmetric mechanism according to [ICA0-9303] for 3DES and
[ISO18013-3] for AES-128, -192 and 256
8. None
on behalf of the user to be performed before the user is authenticated.
FIA_UAU.1.2/PACE The TSF shall require each user to be successfully
authenticated before allowing any other TSF-mediated actions on behalf of that
user.
FIA_UAU.4/PACE Single-use authentication mechanisms
FIA_UAU.4.1/PACE The TSF shall prevent reuse of authentication data related
to
1. PACE Protocol according to [ICAO-SAC],
2. Authentication Mechanism based on Triple-DES and AES
3. Terminal Authentication Protocol Version 1 according to [TR-03110-
1].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 60/119
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/PACE Multiple authentication mechanisms
FIA_UAU.5.1/PACE The TSF shall provide
1. PACE Protocol according to [ICAO-SAC]
2. Passive Authentication according to [ICAO-9303]
3. Secure messaging in MAC-ENC mode according to [ICAO-SAC]
4. Symmetric Authentication Mechanism based on Triple-DES and AES
5. Terminal Authentication Protocol Version 1 according to [TR-03110-
1]
to support user authentication.
FIA_UAU.5.2/PACE The TSF shall authenticate any user's claimed identity
according to the following rules:
1. Having successfully run the PACE protocol the TOE accepts only
received commands with correct message authentication code sent by
means of secure messaging with the key agreed with the terminal by
means of the PACE protocol.
2. The TOE accepts the authentication attempt from the Personalisation
Agent by means of either the ICAO BAC authentication mechanism and
secure messaging protocol defined in [ICAO-9303] for 112 bits 3DES
3. After run of the Chip Authentication Protocol Version 1 the TOE
accepts only received commands with correct message authentication
code sent by means of secure messaging with key agreed with the
terminal by means of the Chip Authentication Mechanism v1.
4. The TOE accepts the authentication attempt by means of the Terminal
Authentication Protocol v.1 only if the terminal uses the public key
presented during the Chip Authentication Protocol v.1 and the secure
messaging established by the Chip Authentication Mechanism v.1
5. None.
FIA_UAU.6/EAC Re-authenticating
FIA_UAU.6.1/EAC The TSF shall re-authenticate the user under the conditions
each command sent to the TOE after successful run of the Chip
Authentication Protocol Version 1 shall be verified as being sent by the
Inspection System.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 61/119
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.6/PACE Re-authenticating
FIA_UAU.6.1/PACE The TSF shall re-authenticate the user under the conditions
each command sent to the TOE after successful run of the PACE protocol
shall be verified as being sent by the PACE Terminal..
FIA_API.1/CA Authentication Proof of Identity
FIA_API.1.1/CA The TSF shall provide a Chip Authentication Protocol
Version 1 according to [TR-03110-1] to prove the identity of the TOE.
Application Note:
This SFR requires the TOE to implement the Chip Authentication Mechanism v.1
specified in [TR-03110-1]. The TOE and the terminal generate a shared secret
using the Diffie-Hellman Protocol (DH or EC-DH) and two session keys for secure
messaging in ENC_MAC mode according to [ICAO-9303]. The terminal verifies by
means of secure messaging whether the travel document’s chip was able or not to
run his protocol properly using its Chip Authentication Private Key corresponding
to the Chip Authentication Key (EF.DG14).
FIA_API.1/AA Authentication Proof of Identity
FIA_API.1.1/AA The TSF shall provide a Active Authentication Protocol
according to [ICAO-9303] to prove the identity of the TOE.
7.1.2 Class FDP User Data Protection
FDP_ACC.1/TRM Subset access control
FDP_ACC.1.1/TRM The TSF shall enforce the Access Control SFP on terminals
gaining access to the User Data and data stored in EF.SOD of the logical
travel document.
FDP_ACF.1/TRM Security attribute based access control
FDP_ACF.1.1/TRM The TSF shall enforce the Access Control SFP to objects
based on the following:
1. Subjects:
a. Terminal,
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 62/119
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. BIS-PACE
c. Extended Inspection System
2. Objects:
a. data in EF.DG1, EF.DG2 and EF.DG5 to EF.DG16, EF.SOD and
EF.COM of the logical travel document,
b. data in EF.DG3 of the logical travel document,
c. data in EF.DG4 of the logical travel document,
d. all TOE intrinsic secret cryptographic keys stored in the travel
document
3. Security attributes:
a. PACE Authentication
b. Terminal Authentication v.1
c. Authorisation of the Terminal.
FDP_ACF.1.2/TRM The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed: A BIS-
PACE is allowed to read data objects from FDP_ACF.1.1/TRM according
to [ICAO-SAC] after a successful PACE authentication as required by
FIA_UAU.1/PACE.
FDP_ACF.1.3/TRM The TSF shall explicitly authorise access of subjects to objects
based on the following additional rules: none.
FDP_ACF.1.4/TRM The TSF shall explicitly deny access of subjects to objects
based on the following additional rules:
1. Any terminal being not authenticated as PACE authenticated BIS-
PACE is not allowed to read, to write, to modify, to use any User
Data stored on the travel document.
2. Terminals not using secure messaging are not allowed to read, to
write, to modify, to use any data stored on the travel document.
3. Any terminal being not successfully authenticated as Extended
Inspection System with the Read access to DG 3 (Fingerprint)
granted by the relative certificate holder authorization encoding
is not allowed to read the data objects 2b) of FDP_ACF.1.1/TRM.
4. Any terminal being not successfully authenticated as Extended
Inspection System with the Read access to DG 4 (Iris) granted by
the relative certificate holder authorization encoding is not
allowed to read the data objects 2c) of FDP_ACF.1.1/TRM.
5. Nobody is allowed to read the data objects 2d) of
FDP_ACF.1.1/TRM.
6. Terminals authenticated as CVCA or as DV are not allowed to read
data in the EF.DG3 and EF.DG4.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 63/119
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_RIP.1 Subset residual information protection
FDP_RIP.1.1 The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the resource from the
following objects:
1. Session Keys (immediately after closing related communication
session),
2. the ephemeral private key ephem - SK PICC- PACE (by having
generated a DH shared secret K).
3. None.
FDP_UCT.1/TRM Basic data exchange confidentiality
FDP_UCT.1.1/TRM The TSF shall enforce the Access Control SFP to transmit
and receive user data in a manner protected from unauthorised disclosure.
FDP_UIT.1/TRM Data exchange integrity
FDP_UIT.1.1/TRM The TSF shall enforce the Access Control SFP to transmit
and receive user data in a manner protected from modification, deletion,
insertion and replay errors.
FDP_UIT.1.2/TRM The TSF shall be able to determine on receipt of user data,
whether modification, deletion, insertion and replay has occurred.
7.1.3 Class FTP Trusted Path/Channels
FTP_ITC.1/PACE Inter-TSF trusted channel
FTP_ITC.1.1/PACE The TSF shall provide a communication channel between
itself and another trusted IT product that is logically distinct from other
communication channels and provides assured identification of its end points
and protection of the channel data from modification or disclosure.
FTP_ITC.1.2/PACE The TSF shall permit another trusted IT product to initiate
communication via the trusted channel.
FTP_ITC.1.3/PACE The TSF shall enforce communication via the trusted channel
for any data exchange between the TOE and the Terminal..
7.1.4 Class FAU Security Audit
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 64/119
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.
FAU_SAS.1 Audit storage
FAU_SAS.1.1 The TSF shall provide the Manufacturer with the capability to
store initialisation and pre-personnalization data in the audit records.
7.1.5 Class FMT Security Management
The SFR FMT_SMR.1/PACE provides basic requirements to the management of the
TSF data.
The TOE shall meet the requirement 'Security roles (FMT_SMR.1)' as specified
below (Common Criteria Part 2).
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management
functions:
1. Initialization,
2. Pre-personalisation,
3. Personalisation
4. Configuration.
FMT_SMR.1/PACE Security roles
FMT_SMR.1.1/PACE The TSF shall maintain the roles
1. Manufacturer,
2. Personalisation Agent,
3. Terminal,
4. PACE authenticated BIS-PACE,
5. Country Verifying Certification Authority,
6. Document Verifier,
7. Domestic Extended Inspection System
8. Foreign Extended Inspection System.
FMT_SMR.1.2/PACE The TSF shall be able to associate users with roles.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 65/119
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 manipulated and disclosed,
2. TSF data to be disclosed or manipulated,
3. software to be reconstructed,
4. substantial information about construction of TSF to be gathered
which may enable other attacks and
5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed
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 manipulated and disclosed,
2. TSF data to be disclosed or manipulated
3. software to be reconstructed,
4. substantial information about construction of TSF to be gathered
which may enable other attacks and
5. sensitive User Data (EF.DG3 and EF.DG4) to be disclosed
FMT_MTD.1/INI_ENA Management of TSF data
FMT_MTD.1.1/INI_ENA The TSF shall restrict the ability to write the
Initialisation Data and the Pre-personalisation 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 read out the
Initialisation Data and the Pre-personalisation Data to the
Personalisation Agent.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 66/119
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_MTD.1/PA Management of TSF data
FMT_MTD.1.1/PA The TSF shall restrict the ability to write the Document
Security Object (SO.D) to the Personalisation Agent.
FMT_MTD.1/CVCA_INI Management of TSF data
FMT_MTD.1.1/CVCA_INI The TSF shall restrict the ability to write the
1. initial Country Verifying Certification Authority Public Key,
2. initial Country Verifying Certification Authority Certificate,
3. initial Current Date,
4. none
to Personalization Agent.
FMT_MTD.1/CVCA_UPD Management of TSF data
FMT_MTD.1.1/CVCA_UPD The TSF shall restrict the ability to update the
1. Country Verifying Certification Authority Public Key,
2. Country Verifying Certification Authority Certificate
to Country Verifying Certification Authority.
FMT_MTD.1/DATE Management of TSF data
FMT_MTD.1.1/DATE The TSF shall restrict the ability to modify the Current
date to
1. Country Verifying Certification Authority,
2. Document Verifier,
3. Domestic Extended Inspection System.
FMT_MTD.1/CAPK Management of TSF data
FMT_MTD.1.1/CAPK The TSF shall restrict the ability to load the Chip
Authentication Private Key to Personalization Agent.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 67/119
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_MTD.1/AAPK Management of TSF data
FMT_MTD.1.1/AAPK The TSF shall restrict the ability to load the Active
Authentication Private Key to Personalization Agent.
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. PACE passwords,
2. Chip Authentication Private Key,
3. Personalisation Agent Keys
4. Active Authentication Private Key
to none.
FMT_MTD.3 Secure TSF data
FMT_MTD.3.1 [Editorially Refined] The TSF shall ensure that only secure
values of the certificate chain are accepted for TSF data of the Terminal
Authentication Protocol v.1 and the Access Control.
Refinement:
The certificate chain is valid if and only if
1. the digital signature of the Inspection System Certificate can be verified as
correct with the public key of the Document Verifier Certificate and the
expiration date of the Inspection System Certificate is not before the Current
Date of the TOE,
2. the digital signature of the Document Verifier Certificate can be verified as
correct with the public key in the Certificate of the Country Verifying Certification
Authority and the expiration date of the Certificate of the Country Verifying
Certification Authority is not before the Current Date of the TOE and the
expiration date of the Document Verifier Certificate is not before the Current
Date of the TOE,
3. the digital signature of the Certificate of the Country Verifying Certification
Authority can be verified as correct with the public key of the Country Verifying
Certification Authority known to the TOE.
The Inspection System Public Key contained in the Inspection System Certificate
in a valid certificate chain is a secure value for the authentication reference data
of the Extended Inspection System.
The intersection of the Certificate Holder Authorizations contained in the
certificates of a valid certificate chain is a secure value for Terminal
Authorization of a successful authenticated Extended Inspection System.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 68/119
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.1.6 Class FPT Protection of the Security Functions
The TOE shall prevent inherent and forced illicit information leakage for User Data
and TSF Data. The security functional requirement FPT_EMS.1 addresses the
inherent leakage. The SFRs 'Limited capabilities (FMT_LIM.1)', 'Limited availability
(FMT_LIM.2)' together with the SAR 'Security architecture description'
(ADV_ARC.1) prevent bypassing, deactivation and manipulation of the security
features or misuse of TOE functions. The TOE shall meet the requirement 'TOE
Emanation (FPT_EMS.1)' as specified below (Common Criteria Part 2 extended):
FPT_EMS.1 TOE Emanation
FPT_EMS.1.1 The TOE shall not emit variations in power consumption or
variations in timing during command execution in excess of non-useful
information enabling access to
1. Chip Authentication Session Keys
2. PACE session Keys (PACE-K MAC, PACE-KEnc),
3. the ephemeral private key ephem SK PICC-PACE,
4. Active Authentication Private Key,
5. Personalisation Agent Key(s),
6. Chip Authentication Private Key
and none
FPT_EMS.1.2 The TSF shall ensure any users are unable to use the following
interface smart card circuit contacts to gain access to
1. Chip Authentication Session Keys
2. PACE Session Keys (PACE-K.MAC, PACE-K.Enc),
3. the ephemeral private key ephem SK PICC-PACE,
4. Active Authentication Private Key,
5. Personalisation Agent Key(s) and
6. Chip Authentication Private Key
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 operating conditions causing a TOE malfunction,
2. Failure detected by TSF according to FPT_TST.1,
3. none.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 69/119
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 the TSF.
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.
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.
7.2 Security Assurance Requirements
The Evaluation Assurance Level is EAL5 augmented with AVA_VAN.5 and
ALC_DVS.2.
7.3 Security Requirements Rationale
7.3.1 Objectives
7.3.1.1 Security Objectives for the TOE
OT.Data_Integrity The security objective OT.Data_Integrity “Integrity of
personal data” requires the TOE to protect the integrity of the logical travel
document stored on the travel document’s chip against physical manipulation
and unauthorized writing. Physical manipulation is addressed by FPT_PHP.3.
Logical manipulation of stored user data is addressed by (FDP_ACC.1/TRM,
FDP_ACF.1/TRM): only the Personalisation Agent is allowed to write the data in
EF.DG1 to EF.DG16 of the logical travel document (FDP_ACF.1.2/TRM, rule 1)
and terminals are not allowed to modify any of the data in EF.DG1 to EF.DG16
of the logical travel document (cf.FDP_ACF.1.4/TRM). FMT_MTD.1/PA requires
that SOD containing signature over the User Data stored on the TOE and used
for the Passive Authentication is allowed to be written by the Personalisation
Agent only and, hence, is to be considered as trustworthy. The Personalisation
Agent must identify and authenticate themselves according to FIA_UID.1/PACE
and FIA_UAU.1/PACE before accessing these data. FIA_UAU.4/PACE,
FIA_UAU.5/PACE and FCS_CKM.4 represent some required specific properties
of the protocols used. The SFR FMT_SMR.1/PACE lists the roles and the SFR
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 70/119
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_SMF.1 lists the TSF management functions. Unauthorised modifying of the
exchanged data is addressed, in the first line, by FTP_ITC.1/PACE using
FCS_COP.1/PACE_MAC. For PACE secured data exchange, a prerequisite for
establishing this trusted channel is a successful PACE Authentication
(FIA_UID.1/PACE, FIA_UAU.1/PACE) using FCS_CKM.1/DH_PACE and
possessing the special properties FIA_UAU.5/PACE, FIA_UAU.6/PACE resp.
FIA_UAU.6/EAC. The trusted channel is established using PACE, Chip
Authentication v.1 and Terminal Authentication v.1. FDP_RIP.1 requires erasing
the values of session keys (here: for KMAC).The TOE supports the inspection
system detect any modification of the transmitted logical travel document data
after Chip Authentication v.1. The SFR FIA_UAU.6/EAC and FDP_UIT.1/TRM
requires the integrity protection of the transmitted data after Chip
Authentication v.1 by means of secure messaging implemented by the
cryptographic functions according to FCS_CKM.1/CA (for the generation of
shared secret and for the derivation of the new session keys), and
FCS_COP.1/CA_ENCand FCS_COP.1/CA_MAC for the ENC_MAC_Mode secure
messaging. The session keys are destroyed according to FCS_CKM.4 after use.
The SFR FMT_MTD.1/CAPK and FMT_MTD.1/KEY_READ requires that the Chip
Authentication Key cannot be written unauthorized or read afterwards. The SFR
FMT_MTD.1/AAPK and FMT_MTD.1/KEY_READ requires that the Active
Authentication Key cannot be written unauthorized or read afterwards. The SFR
FCS_RND.1 represents a general support for cryptographic operations needed.
OT.Data_Authenticity The security objective OT.Data_Authenticity aims
ensuring authenticity of the User- and TSF data (after the PACE Authentication)
by enabling its verification at the terminal-side and by an active verification by
the TOE itself. This objective is mainly achieved by FTP_ITC.1/PACE using
FCS_COP.1/PACE_MAC. A prerequisite for establishing this trusted channel is a
successful PACE or Chip and Terminal Authentication v.1 (FIA_UID.1/PACE,
FIA_UAU.1/PACE) using FCS_CKM.1/DH_PACE resp. FCS_CKM.1/CA and
possessing the special properties FIA_UAU.5/PACE, FIA_UAU.6/PACE resp.
FIA_UAU.6/EAC. FDP_RIP.1 requires erasing the values of session keys (here:
for KMAC). FIA_UAU.4/PACE, FIA_UAU.5/PACE and FCS_CKM.4 represent some
required specific properties of the protocols used. The SFR
FMT_MTD.1/KEY_READ restricts the access to the PACE passwords, the Chip
Authentication Private Key and the Active Authentication Private Key.
FMT_MTD.1/PA requires that SOD containing signature over the User Data
stored on the TOE and used for the Passive Authentication is allowed to be
written by the Personalisation Agent only and, hence, is to be considered as
trustworthy. The SFR FCS_RND.1 represents a general support for
cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1/PACE
support the functions and roles related.
OT.Data_Confidentiality The security objective OT.Data_Confidentiality aims
that the TOE always ensures confidentiality of the User- and TSF-data stored
and, after the PACE Authentication resp. Chip Authentication, of these data
exchanged. This objective for the data stored is mainly achieved by
(FDP_ACC.1/TRM, FDP_ACF.1/TRM). FIA_UAU.4/PACE, FIA_UAU.5/PACE and
FCS_CKM.4 represent some required specific properties of the protocols used.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 71/119
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 objective for the data exchanged is mainly achieved by FDP_UCT.1/TRM,
FDP_UIT.1/TRM and FTP_ITC.1/PACE using FCS_COP.1/PACE_ENC resp.
FCS_COP.1/CA_ENC. A prerequisite for establishing this trusted channel is a
successful PACE or Chip and Terminal Authentication v.1 (FIA_UID.1/PACE,
FIA_UAU.1/PACE) using FCS_CKM.1/DH_PACE resp. FCS_CKM.1/CA and
possessing the special properties FIA_UAU.5/PACE, FIA_UAU.6/PACE resp.
FIA_UAU.6/EAC. FDP_RIP.1 requires erasing the values of session keys (here:
for Kenc). The SFR FMT_MTD.1/KEY_READ restricts the access to the PACE
passwords, the Chip Authentication Private Key and the Active Authentication
Private Key. FMT_MTD.1/PA requires that SOD containing signature over the
User Data stored on the TOE and used for the Passive Authentication is allowed
to be written by the Personalisation Agent only and, hence, is to be considered
trustworthy. The SFR FCS_RND.1 represents the general support for
cryptographic operations needed. The SFRs FMT_SMF.1 and FMT_SMR.1/PACE
support the functions and roles related.
OT.Tracing The security objective OT.Tracing aims that the TOE prevents
gathering TOE tracing data by means of unambiguous identifying the travel
document remotely through establishing or listening to a communication via the
contactless interface of the TOE without a priori knowledge of the correct values
of shared passwords (CAN, MRZ). This objective is achieved as follows: (i) while
establishing PACE communication with CAN or MRZ (non-blocking authorization
data) – by FIA_AFL.1/PACE; (ii) for listening to PACE communication (is of
importance for the current PP, since SOD is card-individual) – FTP_ITC.1/PACE.
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
which prevent misuse of test functionality of the TOE or other features 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 travel document’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 (i) the SFR FPT_TST.1 which requires self-
tests to demonstrate the correct operation and tests of authorized users to verify
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 72/119
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 integrity of TSF data and TSF code, and (ii) the SFRFPT_FLS.1 which requires
a secure state in case of detected failure or operating conditions possibly causing
a malfunction.
OT.Identification The security objective OT.Identification “Identification of the
TOE” addresses the storage of Initialisation and Pre-Personalisation Data in its
non-volatile memory, whereby they also include the IC Identification Data
uniquely identifying the TOE’s chip. This will be ensured by TSF according to
SFR FAU_SAS.1. The SFR FMT_MTD.1/INI_ENA allows only the Manufacturer to
write Initialisation and Pre-personalisation Data (including the Personalisation
Agent key set). The SFR FMT_MTD.1/INI_DIS requires the Personalisation Agent
to disable access to Initialisation and Pre-personalisation Data in the life cycle
phase ‘operational use’. The SFRs FMT_SMF.1 and FMT_SMR.1/PACE support
the functions and roles related.
OT.AC_Pers The security objective OT.AC_Pers “Access Control for
Personalisation of logical travel document” addresses the access control of the
writing the logical travel document. The justification for the SFRs FAU_SAS.1,
FMT_MTD.1/INI_ENA and FMT_MTD.1/INI_DIS arises from the justification for
OT.Identification above with respect to the Pre-personalisation Data. The write
access to the logical travel document data are defined by the SFR
FIA_UID.1/PACE, FIA_UAU.1/PACE, FDP_ACC.1/TRM and FDP_ACF.1/TRM in
the same way: only the successfully authenticated Personalisation Agent is
allowed to write the data of the groups EF.DG1 to EF.DG16 of the logical travel
document only once. FMT_MTD.1/PA covers the related property of OT.AC_Pers
(writing SOD and, in generally, personalization data). The SFR
FMT_SMR.1/PACE lists the roles (including Personalisation Agent) and the SFR
FMT_SMF.1 lists the TSF management functions (including Personalisation). The
SFRs FMT_MTD.1/KEY_READ and FPT_EMS.1 restrict the access to the
Personalisation Agent Keys, the Chip Authentication Private Key and the Active
Authentication Private key. The authentication of the terminal as Personalisation
Agent shall be performed by TSF according to SFR FIA_UAU.4/PACE and
FIA_UAU.5/PACE. If the Personalisation Terminal wants to authenticate itself to
the TOE by means of the Terminal Authentication Protocol v.1 (after Chip
Authentication v.1) with the Personalisation Agent Keys, the TOE will use TSF
according to the FCS_RND.1 (for the generation of the challenge),
FCS_CKM.1/CA (for the derivation of the new session keys after Chip
Authentication v.1), and FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC (for the
ENC_MAC_Mode secure messaging), FCS_COP.1/SIG_VER (as part of the
Terminal Authentication Protocol v.1) and FIA_UAU.6/EAC (for the re-
authentication). If the Personalisation Terminal wants to authenticate itself to
the TOE by means of the Authentication Mechanism with the Personalisation
Agent Key, the TOE will use TSF according to the FCS_RND.1 (for the generation
of the challenge) and FCS_COP.1/CA_ENC (to verify the authentication
attempt). The session keys are destroyed according to FCS_CKM.4 after use.
OT.Sens_Data_Conf The security objective OT.Sense_Data_Conf“
Confidentiality of sensitive biometric reference data” is enforced by the Access
Control SFP defined in FDP_ACC.1/TRM and FDP_ACF.1/TRM allowing the data
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 73/119
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.
of EF.DG3 and EF.DG4 only to be read by successfully authenticated Extended
Inspection System being authorized by a valid certificate according
FCS_COP.1/SIG_VER. The SFRs FIA_UID.1/PACE and FIA_UAU.1/PACE require
the identification and authentication of the inspection systems. The SFR
FIA_UAU.5/PACE requires the successful Chip Authentication (CA) v.1 before
any authentication attempt as Extended Inspection System. During the
protected communication following the CA v.1 the reuse of authentication data
is prevented by FIA_UAU.4/PACE. The SFR FIA_UAU.6/EAC and FDP_UCT.1/TRM
requires the confidentiality protection of the transmitted data after Chip
Authentication v.1 by means of secure messaging implemented by the
cryptographic functions according to FCS_RND.1 (for the generation of the
terminal authentication challenge), FCS_CKM.1/CA (for the generation of shared
secret and for the derivation of the new session keys), and FCS_COP.1/CA_ENC
and FCS_COP.1/CA_MAC for the ENC_MAC_Mode secure messaging. The
session keys are destroyed according to FCS_CKM.4 after use. The SFR
FMT_MTD.1/CAPK and FMT_MTD.1/KEY_READ requires that the Chip
Authentication Key cannot be written unauthorized or read afterwards. The SFR
FMT_MTD.1/AAPK and FMT_MTD.1/KEY_READ requires that the Active
Authentication Key cannot be written unauthorized or read afterwards. To allow
a verification of the certificate chain as in FMT_MTD.3 the CVCA’s public key and
certificate as well as the current date are written or update by authorized
identified role as of FMT_MTD.1/CVCA_INI, FMT_MTD.1/CVCA_UPD and
FMT_MTD.1/DATE.
OT.Chip_Auth_Proof The security objective OT.Chip_Auth_Proof “Proof of travel
document’s chip authenticity” is ensured by the Chip Authentication Protocolv.1
provided by FIA_API.1/CA and by Active Authentication provided by
FIA_API.1/AA proving the identity of the TOE. The Chip Authentication
Protocolv.1 defined by FCS_CKM.1/CA is performed using a TOE internally
stored confidential private key as required by FMT_MTD.1/CAPK and
FMT_MTD.1/KEY_READ. The Chip Authentication Protocolv.1 [TR-03110-1]
requires additional TSF according to FCS_CKM.1/CA (for the derivation of the
session keys), FCS_COP.1/CA_ENC and FCS_COP.1/CA_MAC (for the
ENC_MAC_Mode secure messaging). The SFRs FMT_SMF.1 and
FMT_SMR.1/PACE support the functions and roles related. The Active
Authentication defined by FCS_COP.1/SIG_GEN for the generation of the RSA
Signature is performed using a TOE internally stored confidential private key as
required by FMT_MTD.1/AAPK and FMT_MTD.1/KEY_READ. According to
FDP_ACF.1, only the successfully authenticated Inspection Systems are allowed
to request active authentication (FDP_ACF.1.2, rule 2).
7.3.2 Rationale tables of Security Objectives and SFRs
Security Objectives Security Functional Requirements Rationale
OT.Data_Integrity
FCS_CKM.1/DH_PACE, FCS_CKM.4,
FCS_COP.1/PACE_MAC, FIA_UAU.6/PACE,
FDP_RIP.1, FDP_UIT.1/TRM,
FTP_ITC.1/PACE, FMT_SMF.1,
FMT_MTD.1/PA, FPT_PHP.3,
7.3.1.1
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 74/119
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_CKM.1/CA, FCS_COP.1/CA_ENC,
FCS_COP.1/CA_MAC, FCS_RND.1,
FIA_UID.1/PACE, FIA_UAU.1/PACE,
FIA_UAU.4/PACE, FIA_UAU.5/PACE,
FIA_UAU.6/EAC, FDP_ACC.1/TRM,
FDP_ACF.1/TRM, FMT_SMR.1/PACE,
FMT_MTD.1/CAPK,
FMT_MTD.1/KEY_READ, FMT_MTD.1/AAPK
OT.Data_Authenticity
FCS_CKM.1/DH_PACE, FCS_CKM.4,
FCS_COP.1/PACE_MAC, FIA_UAU.6/PACE,
FDP_RIP.1, FTP_ITC.1/PACE, FMT_SMF.1,
FMT_MTD.1/PA, FCS_CKM.1/CA,
FCS_RND.1, FIA_UID.1/PACE,
FIA_UAU.1/PACE, FIA_UAU.4/PACE,
FIA_UAU.5/PACE, FIA_UAU.6/EAC,
FMT_SMR.1/PACE, FMT_MTD.1/KEY_READ
7.3.1.1
OT.Data_Confidentiality
FCS_CKM.1/DH_PACE, FCS_CKM.4,
FCS_COP.1/PACE_ENC, FIA_UAU.6/PACE,
FDP_RIP.1, FDP_UCT.1/TRM,
FDP_UIT.1/TRM, FTP_ITC.1/PACE,
FMT_SMF.1, FMT_MTD.1/PA,
FCS_CKM.1/CA, FCS_COP.1/CA_ENC,
FCS_RND.1, FIA_UID.1/PACE,
FIA_UAU.1/PACE, FIA_UAU.4/PACE,
FIA_UAU.5/PACE, FIA_UAU.6/EAC,
FDP_ACC.1/TRM, FDP_ACF.1/TRM,
FMT_SMR.1/PACE, FMT_MTD.1/KEY_READ
7.3.1.1
OT.Tracing FIA_AFL.1/PACE, FTP_ITC.1/PACE 7.3.1.1
OT.Prot_Abuse-Func FMT_LIM.1, FMT_LIM.2 7.3.1.1
OT.Prot_Inf_Leak
FPT_FLS.1, FPT_TST.1, FPT_PHP.3,
FPT_EMS.1
7.3.1.1
OT.Prot_Phys-Tamper FPT_PHP.3 7.3.1.1
OT.Prot_Malfunction FPT_FLS.1, FPT_TST.1 7.3.1.1
OT.Identification
FMT_SMF.1, FMT_MTD.1/INI_ENA,
FAU_SAS.1, FMT_SMR.1/PACE,
FMT_MTD.1/INI_DIS
7.3.1.1
OT.AC_Pers
FMT_SMF.1, FMT_MTD.1/INI_ENA,
FMT_MTD.1/PA, FAU_SAS.1,
FCS_CKM.1/CA, FCS_CKM.4,
FCS_COP.1/CA_ENC,
FCS_COP.1/CA_MAC,
FCS_COP.1/SIG_VER, FCS_RND.1,
FIA_UID.1/PACE, FIA_UAU.1/PACE,
FIA_UAU.4/PACE, FIA_UAU.5/PACE,
FIA_UAU.6/EAC, FDP_ACC.1/TRM,
FDP_ACF.1/TRM, FMT_SMR.1/PACE,
FMT_MTD.1/KEY_READ, FPT_EMS.1,
7.3.1.1
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 75/119
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_MTD.1/INI_DIS, FMT_LIM.1,
FMT_LIM.2
OT.Sens_Data_Conf
FCS_CKM.1/CA, FCS_CKM.4,
FCS_COP.1/CA_ENC,
FCS_COP.1/CA_MAC,
FCS_COP.1/SIG_VER, FCS_RND.1,
FIA_UID.1/PACE, FIA_UAU.1/PACE,
FIA_UAU.4/PACE, FIA_UAU.5/PACE,
FIA_UAU.6/EAC, FDP_ACC.1/TRM,
FDP_ACF.1/TRM, FDP_UCT.1/TRM,
FMT_MTD.1/CVCA_INI,
FMT_MTD.1/CVCA_UPD,
FMT_MTD.1/DATE, FMT_MTD.1/CAPK,
FMT_MTD.1/KEY_READ, FMT_MTD.3,
FMT_MTD.1/AAPK
7.3.1.1
OT.Chip_Auth_Proof
FCS_CKM.1/CA, FCS_COP.1/CA_ENC,
FCS_COP.1/CA_MAC, FMT_SMF.1,
FMT_SMR.1/PACE, FMT_MTD.1/CAPK,
FMT_MTD.1/KEY_READ, FIA_API.1/CA,
FMT_MTD.1/AAPK, FIA_API.1/AA,
FCS_COP.1/SIG_GEN
7.3.1.1
Table 7 Security Objectives and SFRs - Coverage
Security Functional
Requirements
Security Objectives
FCS_CKM.1/DH_PACE
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality
FCS_CKM.1/CA
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf,
OT.Chip_Auth_Proof
FCS_CKM.4
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf
FCS_COP.1/PACE_ENC OT.Data_Confidentiality
FCS_COP.1/PACE_MAC
OT.Data_Integrity,
OT.Data_Authenticity
FCS_COP.1/CA_ENC
OT.Data_Integrity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf,
OT.Chip_Auth_Proof
FCS_COP.1/SIG_VER OT.AC_Pers, OT.Sens_Data_Conf
FCS_COP.1/SIG_GEN OT.Chip_Auth_Proof
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 76/119
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/CA_MAC
OT.Data_Integrity, OT.AC_Pers,
OT.Sens_Data_Conf,
OT.Chip_Auth_Proof
FCS_RND.1
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf
FIA_AFL.1/PACE OT.Tracing
FIA_UID.1/PACE
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf
FIA_UAU.1/PACE
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf
FIA_UAU.4/PACE
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf
FIA_UAU.5/PACE
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf
FIA_UAU.6/EAC
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf
FIA_UAU.6/PACE
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality
FIA_API.1/CA OT.Chip_Auth_Proof
FIA_API.1/AA OT.Chip_Auth_Proof
FDP_ACC.1/TRM
OT.Data_Integrity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf
FDP_ACF.1/TRM
OT.Data_Integrity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf
FDP_RIP.1
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality
FDP_UCT.1/TRM
OT.Data_Confidentiality,
OT.Sens_Data_Conf
FDP_UIT.1/TRM
OT.Data_Integrity,
OT.Data_Confidentiality
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 77/119
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.
FTP_ITC.1/PACE
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality, OT.Tracing
FAU_SAS.1 OT.Identification, OT.AC_Pers
FMT_SMF.1
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.Identification, OT.AC_Pers,
OT.Chip_Auth_Proof
FMT_SMR.1/PACE
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.Identification, OT.AC_Pers,
OT.Chip_Auth_Proof
FMT_LIM.1 OT.Prot_Abuse-Func, OT.AC_Pers
FMT_LIM.2 OT.Prot_Abuse-Func, OT.AC_Pers
FMT_MTD.1/INI_ENA OT.Identification, OT.AC_Pers
FMT_MTD.1/INI_DIS OT.Identification, OT.AC_Pers
FMT_MTD.1/PA
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality, OT.AC_Pers
FMT_MTD.1/CVCA_INI OT.Sens_Data_Conf
FMT_MTD.1/CVCA_UPD OT.Sens_Data_Conf
FMT_MTD.1/DATE OT.Sens_Data_Conf
FMT_MTD.1/CAPK
OT.Data_Integrity,
OT.Sens_Data_Conf,
OT.Chip_Auth_Proof
FMT_MTD.1/AAPK
OT.Data_Integrity,
OT.Sens_Data_Conf,
OT.Chip_Auth_Proof
FMT_MTD.1/KEY_READ
OT.Data_Integrity,
OT.Data_Authenticity,
OT.Data_Confidentiality,
OT.AC_Pers, OT.Sens_Data_Conf,
OT.Chip_Auth_Proof
FMT_MTD.3 OT.Sens_Data_Conf
FPT_EMS.1 OT.Prot_Inf_Leak, OT.AC_Pers
FPT_FLS.1
OT.Prot_Inf_Leak,
OT.Prot_Malfunction
FPT_TST.1
OT.Prot_Inf_Leak,
OT.Prot_Malfunction
FPT_PHP.3
OT.Data_Integrity,
OT.Prot_Inf_Leak, OT.Prot_Phys-
Tamper
Table 8 SFRs and Security Objectives
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 78/119
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.3.3 Dependencies
7.3.3.1 SFRs Dependencies
Requirements CC Dependencies Satisfied Dependencies
FIA_AFL.1/PACE (FIA_UAU.1) FIA_UAU.1/PACE
FIA_UID.1/PACE No Dependencies
FIA_UAU.1/PACE (FIA_UID.1) FIA_UID.1/PACE
FIA_UAU.4/PACE No Dependencies
FIA_UAU.5/PACE No Dependencies
FIA_UAU.6/EAC No Dependencies
FIA_UAU.6/PACE No Dependencies
FIA_API.1/CA No Dependencies
FIA_API.1/AA No Dependencies
FDP_ACC.1/TRM (FDP_ACF.1) FDP_ACF.1/TRM
FDP_ACF.1/TRM
(FDP_ACC.1) and
(FMT_MSA.3)
FDP_ACC.1/TRM
FDP_RIP.1 No Dependencies
FDP_UCT.1/TRM
(FDP_ACC.1 or
FDP_IFC.1) and
(FTP_ITC.1 or
FTP_TRP.1)
FDP_ACC.1/TRM,
FTP_ITC.1/PACE
FDP_UIT.1/TRM
(FDP_ACC.1 or
FDP_IFC.1) and
(FTP_ITC.1 or
FTP_TRP.1)
FDP_ACC.1/TRM,
FTP_ITC.1/PACE
FTP_ITC.1/PACE No Dependencies
FAU_SAS.1 No Dependencies
FMT_SMF.1 No Dependencies
FMT_SMR.1/PACE (FIA_UID.1) FIA_UID.1/PACE
FMT_LIM.1 (FMT_LIM.2) FMT_LIM.2
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/PACE
FMT_MTD.1/INI_DIS
(FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1,
FMT_SMR.1/PACE
FMT_MTD.1/PA
(FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1,
FMT_SMR.1/PACE
FMT_MTD.1/CVCA_INI
(FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1,
FMT_SMR.1/PACE
FMT_MTD.1/CVCA_UPD
(FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1,
FMT_SMR.1/PACE
FMT_MTD.1/DATE
(FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1,
FMT_SMR.1/PACE
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 79/119
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_MTD.1/CAPK
(FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1,
FMT_SMR.1/PACE
FMT_MTD.1/AAPK
(FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1,
FMT_SMR.1/PACE
FMT_MTD.1/KEY_READ
(FMT_SMF.1) and
(FMT_SMR.1)
FMT_SMF.1,
FMT_SMR.1/PACE
FMT_MTD.3 (FMT_MTD.1)
FMT_MTD.1/CVCA_INI,
FMT_MTD.1/CVCA_UPD
FPT_EMS.1 No Dependencies
FPT_FLS.1 No Dependencies
FPT_TST.1 No Dependencies
FPT_PHP.3 No Dependencies
FCS_CKM.1/DH_PACE
(FCS_CKM.2 or
FCS_COP.1) and
(FCS_CKM.4)
FCS_CKM.4,
FCS_COP.1/PACE_ENC,
FCS_COP.1/PACE_MAC
FCS_CKM.1/CA
(FCS_CKM.2 or
FCS_COP.1) and
(FCS_CKM.4)
FCS_CKM.4,
FCS_COP.1/CA_ENC,
FCS_COP.1/CA_MAC
FCS_CKM.4
(FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2)
FCS_CKM.1/DH_PACE
FCS_COP.1/PACE_ENC
(FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1/DH_PACE,
FCS_CKM.4
FCS_COP.1/PACE_MAC
(FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1/DH_PACE,
FCS_CKM.4
FCS_COP.1/CA_ENC
(FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1/CA, FCS_CKM.4
FCS_COP.1/SIG_VER
(FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1/CA, FCS_CKM.4
FCS_COP.1/SIG_GEN
(FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1/CA, FCS_CKM.4
FCS_COP.1/CA_MAC
(FCS_CKM.1 or
FDP_ITC.1 or
FDP_ITC.2) and
(FCS_CKM.4)
FCS_CKM.1/CA, FCS_CKM.4
FCS_RND.1 No Dependencies
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 80/119
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 9 SFRs Dependencies
7.3.3.1.1 Rationale for the exclusion of Dependencies
The dependency FMT_MSA.3 of FDP_ACF.1/TRM is discarded. The access
control TSF according to FDP_ACF.1/TRM uses security attributes which are
defined during the personalisation 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.3) is necessary here.
7.3.3.2 SARs Dependencies
Requirements CC Dependencies Satisfied Dependencies
ADV_ARC.1 (ADV_FSP.1) and (ADV_TDS.1) ADV_FSP.5, ADV_TDS.4
ADV_FSP.5 (ADV_IMP.1) and (ADV_TDS.1) ADV_IMP.1, ADV_TDS.4
ADV_IMP.1 (ADV_TDS.3) and (ALC_TAT.1) ADV_TDS.4, ALC_TAT.2
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
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_CMS.5, ALC_DVS.2,
ALC_LCD.1
ALC_CMS.5 No Dependencies
ALC_DEL.1 No Dependencies
ALC_DVS.2 No Dependencies
ALC_LCD.1 No Dependencies
ALC_TAT.2 (ADV_IMP.1) ADV_IMP.1
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)
ADV_FSP.5, ASE_INT.1,
ASE_REQ.2
ATE_COV.2 (ADV_FSP.2) and (ATE_FUN.1) ADV_FSP.5, ATE_FUN.1
ATE_DPT.3
(ADV_ARC.1) and (ADV_TDS.4)
and (ATE_FUN.1)
ADV_ARC.1, ADV_TDS.4,
ATE_FUN.1
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)
ADV_FSP.5, AGD_OPE.1,
AGD_PRE.1, ATE_COV.2,
ATE_FUN.1
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 81/119
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.
AVA_VAN.5
(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_FSP.5,
ADV_IMP.1, ADV_TDS.4,
AGD_OPE.1, AGD_PRE.1,
ATE_DPT.3
Table 10 SARs Dependencies
7.3.4 Rationale for the Security Assurance Requirements
The EAL5 was chosen to permits a developer to gain maximum assurance from
positive security engineering based upon rigorous commercial development
practices supported by moderate application of specialist security engineering
techniques. Such a TOE will probably be designed and developed with the intent
of achieving EAL5 assurance. It is likely that the additional costs attributable to
the EAL5 requirements, relative to rigorous development without the application
of specialised techniques, will not be large.
7.3.5 AVA_VAN.5 Advanced methodical vulnerability analysis
The selection of the component AVA_VAN.5 provides the assurance that the TOE
is shown to be highly resistant to penetration attacks to meet the security
objectives OT.Prot_Inf_Leak, OT.Prot_Phys-Tamper and OT.Prot_Malfunction.
7.3.6 ALC_DVS.2 Sufficiency of security measures
The selection of the component ALC_DVS.2 provides a higher assurance of the
secu-rity of the MRTD's development and manufacturing especially for the secure
handling of the MRTD's material.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 82/119
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 TOE Summary Specification
8.1 TOE Summary Specification
This section provides a description of the security functions and assurance
measures of the TOE that meet the TOE security requirements.
The TOE provides security features (SF) which can be associated to following
groups:
Identification and Authentication mechanisms
Cryptographic functions support
Access control /Storage and protection of logical travel document data
Secure messaging
Security and Life-cycle management
Moreover the TOE will protect itself against interference, logical tampering and
bypass. The security functionality of the TOE respectively the Product Citiz 2.1 :
MICAO 1.1.3 on IDealCitiz OS 2.1, SAC/EAC configuration applet will be externally
available to the user by APDU commands according to the access conditions
specified by the according policies considering the life cycle state, user role and
security state.
8.1.1 SF.IA Identification and Authentication
The different authentication mechanisms are supported by APDU commands and
parameters using the cryptographic functions provided by the platform. The
authentication mechanisms are enforced by protocols and APDU methods as
specified in the functional specification.
Note that Symmetric Basic Access Control (BAC) Authentication Mechanism is
supported by the TOE but not covered by this Security Target.
The TOE supports the following authentication mechanisms:
1.Password Authenticated Connection Establishment (PACE)
2.EAC Chip Authentication v. 1
3.EAC Terminal Authentication Protocol v.1
4.Authentication of the Personalization Agent with a personalisation key set
based on a symmetric authentication mechanism.
5.ICAO Active Authentication
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 83/119
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.1.2 SF.CF Cryptographic functions support
Cryptographic function support is provided by the underlying Ideal Citiz v2.1
platform, i.e. the TOE relies on the underlying platform for performing its required
cryptographic operations.
SF.CF Cryptographic functions include:
1. 3DES and AES cipher operations for secure messaging
2. Digest calculations (SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512)
3. Signature generation (ECDSA, RSA)
4. Signature verification (ECDSA, RSA)
5. Diffie-Hellman Key Agreement (ECDH and DH)
6. Key Generation (PACE ECDH/DH ephemeral keys and secure messaging MAC
and ENC session keys)
7. Key Destruction
8. True Random Number generation
8.1.3 SF.ILTB Protection against interference, logical tampering
and bypass
SF.ILTB.1
Protection against interference, logical tampering and bypass
Security domains are supported by the Java Card platform used by the TOE
underlying IDeal Citiz v2.1 open platform. The Ideal Citiz v2.1 platform provides
protection against physical attack and performs self-tests as described in [PLTF-
ST].
The platform protects the TOE against malfunctions that are caused by exposure
to operating conditions that may cause a malfunction. This includes hardware
resets and operation outside the specified norms.
The Product Citiz 2.1 : MICAO 1.1.3 on IDealCitiz OS 2.1, SAC/EAC configuration
Applet uses transient memory where a hardware reset always reverts the
Product Citiz 2.1 : MICAO 1.1.3 on IDealCitiz OS 2.1, SAC/EAC configuration
Applet into an unauthenticated state.
8.1.4 SF.AC Access control / Storage and protection of logical
travel document data
SF.AC.1
Access control / Storage and protection of logical travel document data
The TOE provided access control, storage and protection of logical travel
document data including access control to MRTD data. The TOE implements the
subjects, objects, security attributes and rules according to the security
attribute based access control. Access control is enforced by the APDU methods
as specified in the interface defined in the functional specification.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 84/119
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.1.5 SF.SM Secure Messaging
SF.SM.1
Secure Messaging
Secure messaging MAC and ENC operations are performed by the TOE’s
platform.
Secure messaging in ENC_MAC mode is established during PACE or re-
established during Chip Authentication v1.
SF.SM.2
Secure Messaging – Re-authentication
The Retail MAC for 3DES and CMAC for AES are part of every APDU
command/response when secure messaging is active after a successful PACE or
Chip Authentication has been accomplished. Re-authentication after reset of the
SM protocol is assured by accepting only valid (mandatory) MAC or CMAC
cryptograms.
8.1.6 SF.LCM Security and life cycle management
SF.LCM.1
Management of phases and roles
For the TOE the following life-cycle phases have been identified:
1. Manufacturing phase
2. Personalisation phase
3. Operational phase
4. Termination phase
Each life-cycle phase (or state) has its typical user acting as role holder.
Life-cycle phase Role
Manufacturing phase IC Manufacturer
MRTD Manufacturer Platform initialisation)
MRTD Manufacturer (Pre-personalisation)
Personalisation phase Personalisation Agent
Operational phase Basic or Extended Inspection system
Terminated phase None
All role holders in Manufacturing, Pre-Personalisation and Personalisation phases
are Identified by cryptographic authentication keys. In Operational phase the
PACE password is required to authenticate the Basic or Extended Inspection
System in order to get access to the non-sensitive ICAO LDS datagroups.
The Product Citiz 2.1 : MICAO 1.1.3 on IDealCitiz OS 2.1, SAC/EAC configuration
Applet maintains the internal life-cycle state the moment that the applet is
installed. This state, together with the access control mechanisms force the
Terminal into a specific role, for the pre-personalisation and subsequent,
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 85/119
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.
personalisation and operational phases. The phases (and corresponding life-
cycle states) are controlled by APDU commands.
SF.LCM.2
Life Cycle states of the Product Citiz 2.1 : MICAO 1.1.3 on IDealCitiz OS
2.1, SAC/EAC configuration Applet
The TOE supports the following life-cycle states:
1. Not instantiated (applet resides in FLASH)
2. PRE-PERSONALISATION state
3. PERSONALISATION state
4. OPERATIONAL state
5. TERMINATED state (irreversibly)
Each life-cycle phase (or state) has its typical user acting as role holder.
Life-cycle phase
Life-cycle state (maintained
by applet)
Role
Manufacturing
phase
- (Applet not instantiated) IC Manufacturer
- (Applet not instantiated)
MRTD Manufacturer Platform
initialisation)
PRE-PERSONALISATION
MRTD Manufacturer (Pre-
personalisation)
Personalisation
phase
PERSONALISATION Personalisation Agent
Operational phase OPERATIONAL
Basic or Extended
Inspection system
Terminated phase TERMINATED None
SF.LCM.3
Management of TSF-Data
The TOE allows only in its PERSONALISATION life-cycle state TSF data to be
written onto the TOE.
In OPERATIONAL life-cycle state the management of TSF-Data can only be
performed after successful Terminal Authentication.
Updating the Country Verifier Certification Authority Public Key and Certificate
is restricted to the Country Verifier Certification Authority. Modifying the Current
Date is restricted to the Country Verifier Certification Authority, the Document
Verifier and the domestic Extended Inspection System
SF.LCM.4
Protection of test features
The Product Citiz 2.1 : MICAO 1.1.3 on IDealCitiz OS 2.1, SAC/EAC configuration
Applet does not have any dedicated test features implemented.
The test features of the IDeal Citiz v2.1 platform are protected by ways
described in [PLTF-ST] and guidance documentation.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 86/119
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.
SF.LCM.5
Protection of keys and PACE passwords
In PRE-PERSONALISATION life-cycle state personalisation Agent Key Set is
installed on the TOE’s platform and protected by the platform.
In all TOE life-cycle states the Personalization Agent Key set (MAC, ENC, KEK),
the PACE passwords (derived from MRZ and/or CAN), the Chip Authentication
Private Key, the Active Authentication Private Key are protected from disclosure.
The Product Citiz 2.1 : MICAO 1.1.3 on IDealCitiz OS 2.1, SAC/EAC configuration
Applet only stores keys in Java Card specified Key structures, which are
protected by IDeal Citiz v2.1 platform.
SF.LCM.6
IC Identification data
During initialisation the Product Citiz 2.1 : MICAO 1.1.3 on IDealCitiz OS 2.1,
SAC/EAC configuration Applet is installed and initiated with the Pre-
Personalisation Agent key and the IC Identification data.
8.2 SFRs and TSS
8.2.1 SFRs and TSS - Rationale
8.2.1.1 TOE Summary Specification
8.2.1.1.1 SF.IA Identification and Authentication
The implementation of PACE contributes to:
FIA_AFL.1/PACE, Authentication failure handling PACE authentication using
non-blocking authorisation data. The TOE increases the reaction time of
the TOE after an unsuccessful authentication attempt with a wrong PACE
passwords.
FIA_UID.1/PACE, Timing of identification. The TOE allows to carry out the
PACE Protocol after successful user identification
FIA_UAU.1/PACE, Timing of identification. The TOE prevents reuse of
authentication data related to the PACE protocol, i.e. according
authentication mechanisms.
FIA_UAU.4/PACE, Single-use authentication mechanisms - Single-use
authentication of the Terminal by the TOE
FIA_UAU.5/PACE, Multiple authentication mechanisms to support user
authentication. The TOE provides multiple authentication mechanisms,
PACE, symmetric key based authentication mechanism, etc.
FIA_UAU.6/PACE, Re-authenticating of Terminal by the TOE. The TOE re-
authenticates the connected terminal, if a secure messaging error
occurred.
FCS_CKM.1/DH_PACE, Diffie-Hellman key generation for PACE session keys
provided by SF.CF
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 87/119
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_CKM.4, Cryptographic key destruction – Session keys provided by
SF.CF
FCS_COP.1/PACE_ENC, Cryptographic operation – Encryption / Decryption
AES / 3DES provided by SF.CF
FCS_COP.1/PACE_MAC, Cryptographic operation MAC/CMAC provided by
SF.CF
FDP_ACF.1/TRM, Security attribute based access control, provided by SF.AC
FDP_UCT.1/TRM,Basic data exchange confidentiality – MRTD provided by
SF.AC
FDP_UIT.1/TRM,Data exchange integrity provided by SF.AC
FDP_RIP.1, Subset residual information protection provided by SF.AC
FMT_MTD.1/KEY_READ, Management of TSF data – Key Read protection of
PACE Passwords provided by SF.LCM.6
The implementation Chip Authentication v1. contributes to
FIA_API.1/CA, Authentication Proof of Identity – MRTD. Requires to
implement Chip Authentication.
FIA_UAU.6/EAC Re-authenticating of Terminal by the TOE. The TOE does
not execute any command with incorrect message authentication code.
Therefore the TOE re-authenticates the user for each received command
and accepts only those commands received from the previously
authenticated user.
FMT_SMR.1/PACE, Security Roles provided by SF.LCM.2
FMT_MTD.1/CAPK, Chip Authentication Private Key provided by SF.LCM.2
FMT_MTD.1/KEY_READ, Management of TSF data – Key Read provided by
SF.LCM.6
The implementation of Terminal Authentication v.1 contributes to
FIA_UAU.5/PACE, Multiple authentication mechanisms required to provide
Terminal Authentication v1
FIA_UID.1/PACE, Timing of identification
FMT_MTD.3 Secure TSF data
FMT_SMR.1/PACE Security Roles
FCS_COP.1/SIG_VER (ECDSA signatures only)
The implementation of the Personalization Agent Authentication contributes to
FIA_UAU.5/PACE, Multiple authentication mechanisms, requires to
authenticate the Personalization Agent by symmetric authentication
mechanisms Triple-DES or AES which is provided by the TOE.
FIA_UAU.4/PACE Single-use authenti¬cation of the Terminal by the TOE
FIA_UAU.1/PACE Timing of authentication
FMT_SMR.1/PACE Security Roles
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 88/119
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 implementation of Active Authentication contributes to
FIA_API.1/AA Authentication Proof of Identity – MRTD
FMT_SMR.1/PACE Security Roles provided by SF.LCM.2
FMT_MTD.1/AAPK, Active Authentication Private Key provided by SF.LCM.2
FMT_MTD.1/KEY_READ, Management of TSF data – Key Read provided by
SF.LCM.6
FCS_COP.1/SIG_GEN, Cryptographic operation – Signature generation by
travel document (RSA and ECDSA)
8.2.1.1.2 SF.CF Cryptographic functions support
The implementation of this security function contributes to:
FCS_COP.1/PACE_ENC Cryptographic operation – Encryption / Decryption
FCS_COP.1/PACE_MAC Cryptographic operation MAC
FCS_COP.1/CA_ENC Cryptographic operation – Symmetric Encryption /
Decryption
FCS_COP.1/CA_MAC Cryptographic operation – Cryptographic operation
MAC
FCS_COP.1/SIG_GEN (Supports ECDSA and RSA signature generation)
FCS_COP.1/SIG_VER
FIA_API.1/AA
FCS_COP.1/SIG_GEN (Supports ECDSA and RSA signature generation)
FIA_API.1/CA
FCS_CKM.1/DH_PACE Cryptographic key generation – Diffie-Hellman for
PACE session keys
FCS_CKM.1/CA Cryptographic key generation – Diffie-Hellman for Chip
Authentication session keys (implicitly contains the requirements for the
hashing functions used for key derivation)
FCS_CKM.4/ Cryptographic key destruction – Session keys
FDP_RIP.1
FCS_RND.1/ Quality metric for random numbers
8.2.1.1.3 SF.ILTB Protection against interference, logical tampering and bypass
The implementation of this security function contributes to:
FPT_FLS.1 Failure with preservation of secure state
FPT_TST.1 TSF testing
FPT_PHP.3 Resistance to physical attack
8.2.1.1.4 SF.AC Access control / Storage and protection of logical travel
document data
The implementation of this security function contributes to:
FDP_ACC.1/TRM Subset access control
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 89/119
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_ACF.1/TRM Security attribute based access control,
FDP_UCT.1/TRM Basic data exchange confidentiality – MRTD
FDP_UIT.1/TRM Data exchange integrity
FDP_RIP.1 Subset residual information protection
8.2.1.1.5 SF.SM Secure Messaging
SF.SM.1 The implementation of this security function contributes to::
FTP_ITC.1/PACE: trusted channel after PACE
FCS_COP.1/PACE_ENC: Encryption/Decryption after PACE
FCS_COP.1/PACE_MAC: MAC generation/verification after PACE
FIA_UAU.1/PACE: PACE Authentication (PACE authenticated BIS-PACE)
FCS_COP.1/CA_ENC Encryption/Decryption after Chip Authentication v1
FCS_COP.1/CA_MAC MAC generation/verification after Chip Authentication
v1
FDP_UCT.1/TRM Basic data exchange confidentiality – MRTD (ENC), after
Chip Authentication v1
FDP_UIT.1/TRM Data exchange integrity – MRTD (MAC), after Chip
Authentication v1
SF.SM.2 The implementation of this security function contributes to:
FIA_UAU.6/PACE Re-authenticating – Re-authenticating of Terminal by the
TOE
FIA_UAU.6/EAC Re-authenticating – Re-authenticating of Terminal by the
TOE
8.2.1.1.6 SF.LCM Security and life cycle management
SF.LCM.1 The implementation of this security function contributes to:
FMT_SMF.1 Specification of Management Functions (Initialisation part)
FMT_SMR.1.1/PACE Security roles (Manufacturer)
FMT_MTD.1/INI_ENA Management of TSF data – Writing of Initialisation
Data and Pre-personalization Data
FMT_MTD.1/INI_DIS Management of TSF data – Disabling of Read Access
to Initialisation Data and Pre-personalization Data
FMT_MTD.1/PA
SF.LCM.2 The implementation of this security function contributes to:
FMT_SMF.1 Specification of Management Functions (Personalization and
Configuration)
FMT_SMR.1.1/PACE Security roles (Personalization Agent)
FMT_MTD.1/PA, Personalization Agent Ability to write the Document
Security Object (SOD)
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 90/119
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_MTD.1/CVCA_INI Management of TSF data – Initialisation of CVCA
Certi¬ficate and Current Date
FMT_MTD.1/CAPK Management of TSF data – Chip Authentication Private
Key Restriction of the ability to load the Chip Authentication Private Key
to the Personalization Agent.
FMT_MTD.1/AAPK Management of TSF data – Active Authentication Private
Key Restriction of the ability to load the Active Authentication Private Key
to the Personalization Agent.
SF.LCM.3 The implementation of this security function contributes to:
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1/PACE Security roles (Personalization Agent)
FMT_MTD.1/CVCA_UPD Management of TSF data – Country Verifier
Certification Authority
FMT_MTD.3 Secure TSF data
FMT_MTD.1/DATE Current date
SF.LCM.4 The platform implementation provides this security function and
contributes to:
FMT_LIM.1 Limited capabilities
FMT_LIM.2 Limited availability
SF.LCM.5 The implementation of this security function contributes to:
FMT_MTD.1/KEY_READ Management of TSF data – Key Read
FPT_EMS.1 TOE Emanation
SF.LCM.6
FAU_SAS.1 Audit storage The audit records are usually write-only-once data
of the travel document (see FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS).
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 91/119
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 Statement of Compatibility concerning
Composite Security Target
9.1 Separation of the platform TSF
This section describes the separation of relevant security functionality described in the ST
of the platform (IDeal Ctitz v2.1 [PLTF-ST]) being used by this ST.
The following table confronts the relevant security functionality of the platform with those
of the composite TOE defined in the present ST
IDeal Citiz v2.1 Functionnalities in
[PLTF-ST]
Usage by TOE
F.OPEN
Not relevant
F.CARD_MANAGER
Relevant SF
Used by SF.LCM.1, SF.LCM.2, SF.LCM.3,
SF.LCM.4, SF.LCM.5 and SF.LCM.6
F.JAVA_CARD_SYSTEM
Not relevant
F.JAVA_API
Relevant SF
Used by SF.ILTB.1
F.AUTHENTICATION
Relevant SF
Used by SF.IA.1, SF.IA.2, SF.IA.3, SF.IA.4,
SF.IA.5 and SF.SM.1, SF.SM.2
F.MEMORY_PROGRAMMING
Not relevant
F.SECURE_DATA_MANAGER
Relevant SF
Used by SF.LCM.5 and SF.AC.1
F.SECRET_DATA_MANAGER
Relevant SF
Used by SF.AC.1
F.SYSTEM_MANAGER
Not relevant
F.CRYPTOGRAPHIC_OPERATIONS
Relevant SF
Used by SF.CF.1, SF.CF.2, SF.CF.3,
SF.CF.4, SF.CF.5, SF.CF.6, SF.CF.7,
SF.CF.8, SF.SM.1 and SF.SM.2
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 92/119
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.
IDeal Citiz v2.1 Functionnalities in
[PLTF-ST]
Usage by TOE
F.MEMORY_ACCESS
Not relevant
F.MEMORY_CONTROLLER
Not relevant
F.INPUT/OUTPUT_LAYER
Not relevant
F.TRANSPORT_LAYER
Not relevant
F.CRYPTOGRAPHY_SERVICES
Relevant SF
Used by SF.CF.1, SF.CF.2, SF.CF.3,
SF.CF.4, SF.CF.5, SF.CF.6, SF.CF.7,
SF.CF.8, and SF.LCM.4
F.SECURITY_CONFIGURATION Not relevant
F.CPU_MANAGER Not relevant
F.SECURITY_AUDIT
Not relevant
F.CRYPTOGRAPHIC_LIBRARY
Not relevant
F.INTEGRATED_CIRCUIT
Relevant SF
Used by SF.ILTB.1
Table 11: Compatibility between platform SFRs and the composite ST – Firewall Policy
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 93/119
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 tables specify the compatibility between SFRs of the platform ST and the
composite ST. It indicates to what extend the IDeal Citiz v2.1 platform SFRs are used by
the TOE to meet the security requirements of this composite ST.
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Not used
References
/Remarks
1. Firewall Policy
FDP_ACC.2/FIREWALL Complete
Access Control
The Firewall policy rules are
indirectly used by the applet to
prevent the Project name applet
from accidentally changing the
state of the JCRE.
-
FDP_ACF.1/FIREWALL Security
Attribute based Access Control
FDP_IFC.1/JCVM Subset Information
Flow Control
FDP_IFF.1/JCVM Simple Security
Attributes
FDP_RIP.1/OBJECTS Subset Residual
Information Protection
FMT_MSA.1/JCRE Management of
Security Attributes
FMT_MSA.1/JCVM Management of
Security Attributes
FMT_MSA.2/FIREWALL_JCVM Secure
Security Attributes
FMT_MSA.3/FIREWALL Static
Attribute Initialisation
FMT_MSA.3/JCVM Static Attribute
Initialisation
FMT_SMF.1 Specification of
Management Functions
FMT_SMR.1 Security roles
Table 12: Compatibility between platform SFRs and the composite ST – Firewall Policy
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 94/119
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.
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Used by Applet
Not used
References
/Remarks
2. Application Programming Interface
The following SFRs are related to the Java Card API
FCS_CKM.1 Cryptographic Key
Generation
Used by TOE for :
 FCS_CKM.1/DH_PACE
 FCS_CKM.1/CA
Not used for RSA.
Remark:
TOE derives 3DES and AES session
keys during PACE and Chip
Authentication.
TOE generates ephemeral ECDH
keys during PACE.
SF.CF.6
FCS_CKM.2 Cryptographic Key
Distribution
Used to implement:
 FCS_CKM.1/DH_PACE
 FCS_CKM.1/CA
 FCS_COP.1/SIG_GEN
 FCS_COP.1.1/PACE_ENC
 FCS_COP.1.1/CA_ENC
 FCS_COP.1.1/PACE_MAC
 FCS_COP.1.1/CA_MAC
Remark:
TOE uses platform method
“set keys and components” for
assigning 3DES, AES, RSA, RSA
CRT secure messaging and EC keys.
This
functionality
is not
provided at
the external
interface of
the TOE.
FCS_CKM.3 Cryptographic Key
Access
Used to implement:
 FCS_CKM.1/DH_PACE
 FCS_CKM.1/CA
 FCS_COP.1/SIG_GEN
 FCS_COP.1.1/PACE_ENC
 FCS_COP.1.1/CA_ENC
 FCS_COP.1.1/PACE_MAC
 FCS_COP.1.1/CA_MAC
The TOE uses the platform provided
management of DES, AES, RSA,
RSA-CRT and EC-keys is used in
accordance with cryptographic key
access methods/commands defined
in packages javacard.security of
[JAVA-3.0.1] and [PLTF-OPE] for
proprietary classes.
This
functionality
is not
provided at
the external
interface of
the TOE.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 95/119
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.
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Used by Applet
Not used
References
/Remarks
FCS_CKM.4 Cryptographic Key
Destruction
Used by TOE for:
 FCS_CKM.4
FCS_COP.1 Cryptographic Operation: Used by TOE for:
FIA_UAU.4/PACE
FCS_COP.1.1/PACE_ENC
FCS_COP.1.1/CA_ENC
FCS_COP.1/SIG_GEN
FCS_CKM.1.1/CA
FCS_COP.1/SIG_GEN
FCS_COP.1/SIG_GEN
FIA_UAU.4/PACE
FCS_COP.1/SIG_GEN,
FCS_COP.1/SIG_VER,
FCS_CKM.1/DH_PACE
FCS_CKM.1/CA
FCS_COP.1/SIG_GEN,
FCS_COP.1/SIG_VER
FCS_COP.1/SIG_GEN,
FCS_COP.1/SIG_VER,
FCS_CKM.1/DH_PACE
FCS_CKM.1/CA
FCS_COP.1.1/PACE_ENC
FCS_COP.1.1/CA_ENC
FCS_COP.1.1/PACE_MAC
FCS_COP.1.1/CA_MAC
FCS_COP.1.1/PACE_MAC
FCS_COP.1.1/CA_MAC
Chapter 7
FDP_RIP.1/ABORT Subset Residual
Information Protection
Not directly used by TOE.
TOE relies on this platform SFR.
Note:
Project name Applet has its own
additional implementation of
FDP_RIP.1 in this ST
A deselect by JCRE of Applet
instance occurs in case of re-select
of the Applet by re-issuing a
SELECT BY NAME with ICAO AID.
The Ideal Citiz v2.1 platform clears
the transient memory after the
applets deselect() method has been
called.
-
FDP_RIP.1/APDU Subset Residual
Information Protection
Not directly used.
TOE relies on this platform SFR.
-
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 96/119
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.
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Used by Applet
Not used
References
/Remarks
FDP_RIP.1/bArray Subset Residual
Information Protection
Not directly used.
TOE relies on this platform SFR.
-
FDP_RIP.1/KEYS Subset Residual
Information Protection
Not directly used by TOE’ s
implementation of FDP_RIP.1.
TOE relies on this platform SFR.
-
FDP_RIP.1/TRANSIENT Subset
Residual Information Protection
Not directly used by TOE’ s
implementation of FDP_RIP.1.
TOE relies on this platform SFR.
-
FDP_ROL.1/FIREWALL Basic Rollback Used by TOE during TA trust point
update.
-
Table 13: Compatibility between platform SFRs and the composite ST –
Application Programming Interface
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Not used
References
/Remarks
3. Card Security Management
FAU_ARP.1 Security Alarms Not directly used SF.ILTB.13
FDP_SDI.2 Stored Data Integrity
Monitoring and Action
Not directly used. SF.ILTB.1
FPR_UNO.1 Unobservability Not directly used. SF.ILTB.1
FPT_FLS.1 Failure with Preservation
of Secure State
Not directly used. SF.ILTB.1
FPT_TDC.1 Inter-TSF basic TSF data
consistency
Not used. -
Table 14: Compatibility between platform SFRs and the composite ST –
Card Security Management
3
SFR indirectly supports FMT_LIM.1, FMT_LIM.2, and FPT_FLS.1.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 97/119
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.
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Not used
References
/Remarks
4. AID Management
This group consists of the SFRs related to the management of Application Identifiers.
FIA_ATD.1/AID User Attribute
Definition
Not directly used by TOE.
Only used during TOE initialisation.
SF.LCM.2
FIA_UID.2/AID User Identification
before any Action
Not directly used by TOE.
FIA_USB.1/AID User-Subject Binding Not directly used by TOE.
FMT_MTD.1/JCRE Management of
TSF Data
Not directly used by TOE.
FMT_MTD.3/JCRE Secure TSF Data Not directly used by TOE.
Table 15: Compatibility between platform SFRs and the composite ST – AID Management
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Not used
References
/Remarks
5. INSTG Security Functional Requirements
This group consists of the SFRs related to the installation of the applets, which
addresses security aspects outside the runtime.
FDP_ITC.2/Installer Import of User
Data with Security Attributes
Not used -
FMT_SMR.1/Installer Security roles
FPT_FLS.1/Installer Failure with
preservation of secure state
FPT_RCV.3/Installer Automated
recovery without undue loss
Table 16: Compatibility between platform SFRs and the composite ST –
INSTG Security Functional Requirements
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 98/119
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.
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Not used
References
/Remarks
6. ADELG Security Functional Requirements
This group consists of the SFRs related to the deletion of applets and/or packages,
enforcing the applet deletion manager (ADEL) policy on security aspects outside the
runtime.
FDP_ACC.2/ADEL Complete access
control
Not used -
FDP_ACF.1/ADEL Security attribute
based access control
FDP_RIP.1/ADEL Subset residual
information protection
FMT_MSA.1/ADEL Management of
security attributes
FMT_MSA.3/ADEL Static attribute
Initialisation
FMT_SMF.1/ADEL Specification of
Management Functions
FMT_SMR.1/ADEL Security roles
FPT_FLS.1/ADEL Failure with
preservation of secure state
Table 17: Compatibility between platform SFRs and the composite ST –
ADELG Security Functional Requirements
IDeal Citiz v2.1-SFRs in [PLTF-ST] Usage by TOE /
Not used
Reference
s
/Remarks
7. ODELG Security Functional Requirements
This group describes the object deletion mechanism. This mechanism is triggered by the
applet that owns the deleted objects by invoking a specific API method.
FDP_RIP.1/ODEL Subset residual
information protection
Not used by applet. -
FPT_FLS.1/ODEL Failure with
preservation of secure state
Not used by applet. -
Table 18: Compatibility between platform SFRs and the composite ST –
ODELG Security Functional Requirements
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 99/119
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.
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Not used
References
/Remarks
8. CARG Security Functional Requirements
This group includes requirements for preventing the installation of packages that has
not been byte code verified, or that has been modified after byte code verification.
FCO_NRO.2/CM Enforced proof of
origin
Not directly used.
The applet has passed byte code
verifier.
-
FDP_IFC.2/CM Complete information
flow control
FDP_IFF.1/CM Simple security
attributes
FDP_UIT.1/CM Data exchange
integrity
FIA_UID.1/CM Timing of identification
FMT_MSA.1/CM Management of
security attributes
FMT_MSA.3/CM Static attribute
initialisation
FMT_SMF.1/CM Specification of
Management Functions
FMT_SMR.1/CM Security roles
FTP_ITC.1/CM Inter-TSF trusted
channel
Table 19: Compatibility between platform SFRs and the composite ST –
CARG Security Functional Requirements
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Not used
References
/Remarks
9. PACE Functional Requirements
FCS_CKM.2/PACE Cryptographic key
distribution
Not directly used.
FCS_CKM.3/PACE Cryptographic key
access
Not directly used.
FCS_COP.1/PACE Cryptographic
operation
Not directly used.
Table 20: Compatibility between platform SFRs and the composite ST –
PACE Functional Requirements
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 100/119
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.
IDeal Citiz v2.1-SFRs in [PLTF-
ST]
Usage by TOE /
Not used
References
/Remarks
10.OSG Security Functional Requirements
FPT_RCV.3/OS Automated recovery
without undue loss
Not used -
FPT_RCV.4/OS Function recovery Not used -
FPT_FLS.1/OS Failure with
preservation of secure state
Not used -
FPT_PHP.3/OS Resistance to physical
attack
Not used
Table 21: Compatibility between platform SFRs and the composite ST -
OSG Security Functional Requirements
IDeal Citiz v2.1-SFRs in [PLTF-ST] Usage by TOE /
Not used
Reference
s
/Remarks
11.CardLifeCycleManagement Security Functional Requirements
FDP_ACC.1/CardLifeCycleManagemen
t Subset Access Control
Used during TOE initialisation for
installing pre-personalisation key
set.
Not used by applet.
SF.LCM.2
FDP_ACF.1/CardLifeCycleManagement
Security Attribute based Access
Control
Used during TOE initialisation for
adjusting GP state to SECURED.
Used by applet to move GP state to
TERMINATED in case of physical
detected attacks detected by applet.
(see SFR FPT_PHP.3)
SF.LCM.2
FMT_MSA.1/CardLifeCycleManagemen
t Management of Security Attributes
Not directly used. -
FMT_MSA.3/CardLifeCycleManagemen
t Static Attribute
Initialisation
Not directly used. -
FTP_ITC.1/CardLifeCycleManagement
Inter-TSF trusted channel
Not directly used. -
Table 22: Compatibility between platform SFRs and the composite ST -
LifeCycle Security Functional Requirements
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 101/119
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
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 102/119
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.2 Compatibility between the Composite Security Target
and the Platform Security Target
The following mapping demonstrates the compatibility between the Composite Security
Target (the document at hand) and the Platform Security Target [PLTF-ST] regarding
security environments, security objectives, and security requirements. There is no
conflict between security environments, security objectives, and security requirements of
the Composite Security Target and the Platform Security Target.
IDeal Citiz v2.1 Definition Pendent in this ST Remarks
Security objectives for the TOE
Platform objectives Pendant in this ST with similar
aim
Remarks
O.SID - No contradictions
O.FIREWALL - No contradictions
O.GLOBAL_ARRAYS_CONFID - No contradictions
O.GLOBAL_ARRAYS_INTEG - No contradictions
O.NATIVE - No contradictions
O.OPERATE OT.Prot_Malfunction No contradictions
O.REALLOCATION - No contradictions
O.RESOURCES - No contradictions
O.ALARM - No contradictions
O.CIPHER OT.Sens_Data_Conf No contradictions
O.PIN-MNGT - No contradictions
O.KEY-MNGT OT.AC_Pers, OT.Data_Integrity,
OT.Sens_Data_Conf,
OT.Chip_Auth_Proof
No contradictions
O.TRANSACTION - No contradictions
O.DELETION - No contradictions
O.LOAD - No contradictions
O.INSTALL - No contradictions
O.CARD-MANAGEMENT OT.Prot_Phys-Tamper No contradictions
O.SCP.RECOVERY - No contradictions
O.SCP.SUPPORT - No contradictions
O.SCP.IC OT.Prot_Phys-Tamper No contradictions
O.BIO-MNGT - No contradictions
O.OBJ-DELETION - No contradictions
Relevant threats of the Platform ST vs. threats of the Composite-ST.
Threats of Platform ST According threats of comp. ST
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 103/119
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.
IDeal Citiz v2.1 Definition Pendent in this ST Remarks
T.CONFID-APPLI-DATA T.Read_Sensitive_Data, No contradictions
T.CONFID-JCS-DATA - No contradictions
T.INTEG-JCS-DATA - No contradictions
T.INTEG-APPLI-DATA T.Phys-Tamper, T.Forgery No contradictions
T.INTEG-APPLI-CODE.LOAD T.Phys-Tamper, T.Forgery No contradictions
T.INTEG-APPLI-DATA.LOAD T.Phys-Tamper, T.Forgery No contradictions
T.CONFID-JCS-CODE - No contradictions
T.INTEG-APPLI-CODE - No contradictions
T.INTEG-JCS-CODE - No contradictions
T.APP_DATA_INTEGRITY - No contradictions
T.SID.1 - No contradictions
T.SID.2 - No contradictions
T.EXE-CODE.1 - No contradictions
T.EXE-CODE.2 - No contradictions
T.NATIVE - No contradictions
T.RESOURCES - No contradictions
T.DELETION - No contradictions
T.INSTALL - No contradictions
T.OBJ-DELETION - No contradictions
T.UNAUTH_CARD_MNGT - No contradictions
T.LIFE_CYCLE - No contradictions
T.UNAUTH_ACCESS - No contradictions
T.PHYSICAL T.Phys-Tamper No contradictions
Assumptions (platform) significant for Composite-ST
Assumptions of Platform ST Relevancy for Composite-ST
A.APPLET Guidance of the Platform-
Developer for the Applet
Developer has to be applied
No contradiction to
this ST
A.VERIFICATION Guidance of the Platform-
Developer for the Applet
Developer has to be applied
No contradiction to
this ST
A.PRODUCTION Guidance of the Platform-
Developer for the Applet
Developer has to be applied
No contradiction to
this ST
Platform security objectives for the environment and relevancy for the
Composite ST
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 104/119
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.
IDeal Citiz v2.1 Definition Pendent in this ST Remarks
OE of platform ST Matching aspects in Composite-
ST
Remarks
OE.CODE-EVIDENCE - No contradictions
OE.SECURITY-DOMAINS - No contradictions
OE.QUOTAS - No contradictions
OE.SHARE-CONTROL - No contradictions
OE.KEY_GENERATION - No contradictions
OE.PRODUCTION - No contradictions
OE.VERIFICATION Guidance of the Platform-
Developer for the Applet
Developer has to be applied
No contradictions
OE.APPLET - No contradictions
Platform organizational security policies for the environment and relevancy for
the
Composite ST
OSP of platform ST Matching aspects in Composite-
ST
Remarks
OSP.VERIFICATION
Guidance of the Platform-
Developer for the Applet-
Developer and
recommandations related to
the isolation property of the
platform have to be applied in
the application code
Not contradictory to any
threats of composite ST
No contradictions
OSP.SECURITY_DOMAINS
No correspondence
Not contradictory to any
threats of composite ST
No contradictions
OSP.QUOTAS
No correspondence
Not contradictory to any
threats of composite ST
No contradictions
OSP.KEY_GENERATION
Guidance of the Platform-
Developer for the Applet-
Developer and
recommandations related to
the Key Generation have to be
applied in the application code
Not contradictory to any
threats of composite ST
No contradictions
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 105/119
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.
IDeal Citiz v2.1 Definition Pendent in this ST Remarks
OSP.SHARE-CONTROL
Guidance of the Platform-
Developer for the Applet-
Developer and
recommandations related to
the Shareable interface
functionality have to be applied
in the application code
Not contradictory to any
threats of composite ST
No contradictions
Table 23: Compatibility between platform and composite ST
9.3 Compatibility of Assurance Requirements
The level of assurance of the:
- TOE is EAL5 augmented with ALC DVS.2 and AVA_VAN.5
- Platform is EAL5 augmented with ALC DVS.2 and AVA VAN.5
This shows that the Assurance Requirements of the TOE matches the Assurance
Requirements of the underlying Platform.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 106/119
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 Annex
Glossary
Term Definition
Accurate Terminal
Certificate
A Terminal Certificate is accurate, if the issuing Document Verifier is
trusted by the travel document’s chip to produce Terminal
Certificates with the correct certificate effective date, see [TR-
03110-1].
Advanced
Inspection
Procedure (with
PACE)
A specific order of authentication steps between a travel document
and a terminal as required by [ICAO-SAC], namely (i) PACE, (ii)
Chip Authentication v.1, (iii) Passive Authentication with SOD and
(iv) Terminal Authentication v.1. AIP can generally be used by EIS-
AIP-PACE.
Agreement This term is used in the current ST in order to reflect an appropriate
relationship between the parties involved, but not as a legal notion.
Active
Authentication
Security mechanism defined in [ICAO-9303]. Option by which means
the MTRD’s chip proves and the inspection system verifies the
identity and authenticity of the MTRD’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 (cf. CC part 1, section B.2.7).
Audit records Write-only-once non-volatile memory area of the MRTDs chip to
store the Initialisation 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
Security mechanism defined in [ICAO-9303] by which means the
MTRD’s chip proves and the inspection system protect their
communication by means of secure messaging with Basic Access
Keys (see there).
Basic Inspection
System (BIS)
A technical system being used by an inspecting authority and
operated by a governmental organisation (i.e. an Official Domestic
or Foreign Document Verifier) and verifying the travel document
presenter as the travel document holder (for ePassport: by
comparing the real biometric data (face) of the travel document
presenter with the stored biometric data (DG2) of the travel
document holder).
The Basic Inspection System with PACE is a PACE Terminal
additionally supporting/applying the Passive Authentication protocol
and is authorised by the travel document Issuer through the
Document Verifier of receiving state to read a subset of data stored
on the travel document.
Biographical data
(bio data).
The personalized details of the bearer of the document 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.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 107/119
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.
Term Definition
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.
Card Access
Number (CAN)
Password derived from a short number printed on the front side of
the data-page.
Certificate chain A sequence defining a hierarchy certificates. The Inspection System
Certificate is the lowest level, Document Verifier Certificate in
between, and Country Verifying Certification Authority Certificates
are on the highest level. A certificate of a lower level is signed with
the private key corresponding to the public key in the certificate of
the next higher level.
Counterfeit An unauthorized copy or reproduction of a genuine security
document made by whatever means.
Country Signing
CA Certificate
(CCSCA)
Self-signed certificate of the Country Signing CA Public Key
(KPu CSCA) issued by CSCA stored in the inspection system.
Country Signing
Certification
Authority (CSCA)
An organisation enforcing the policy of the travel document Issuer
with respect to confirming correctness of user and TSF data stored in
the travel document. The CSCA represents the country specific root
of the PKI for the travel documents and creates the Document
Signer Certificates within this PKI.
The CSCA also issues the self-signed CSCA Certificate (CCSCA)
having to be distributed by strictly secure diplomatic means, see.
[ICAO-9303], 5.5.1.
The Country Signing Certification Authority issuing certificates for
Document Signers (cf. [6]) and the domestic CVCA may be
integrated into a single entity, e.g. a Country Certification Authority.
However, even in this case, separate key pairs must be used for
different roles, see [TR-03110-1].
Country Verifying
Certification
Authority (CVCA)
An organisation enforcing the privacy policy of the travel document
Issuer with respect to protection of user data stored in the travel
document (at a trial of a terminal to get an access to these data).
The CVCA represents the country specific root of the PKI for the
terminals using it and creates the Document Verifier Certificates
within this PKI. Updates of the public key of the CVCA are distributed
in form of CVCA Link-Certificates, see [TR-03110-1].
Since the Standard Inspection Procedure does not imply any
certificate-based terminal authentication, the current TOE cannot
recognise a CVCS as a subject; hence, it merely represents an
organizational entity within this ST.
The Country Signing Certification Authority (CSCA) issuing
certificates for Document Signers (cf. [ICAO-9303]) and the
domestic CVCA may be integrated into a single entity, e.g. a Country
Certification Authority. However, even in this case, separate key
pairs must be used for different roles, see [TR-03110-1].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 108/119
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.
Term Definition
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.
CV 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 certificate effective date
for the new key is before the certificate expiration date of the
certificate for the old key.
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 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 [ICAO-9303] 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 Details
Data
Data printed on and electronically stored in the travel document
representing the document details like document type, issuing state,
document number, date of issue, date of expiry, issuing authority.
The document details data are less-sensitive data.
Document Basic
Access Keys
Pair of symmetric 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 [ICAO-9303]. 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). [ICAO-9303]
Document Signer
(DS)
An organisation enforcing the policy of the CSCA and signing the
Document Security Object stored on the travel document for passive
authentication.
A Document Signer is authorised by the national CSCA issuing the
Document Signer Certificate (CDS), see [TR-03110-1] and [ICAO-
9303].
This role is usually delegated to a Personalisation Agent.
Document Verifier
(DV)
An organisation enforcing the policies of the CVCA and of a Service
Provider (here: of a governmental organisation / inspection
authority) and managing terminals belonging together (e.g.
terminals operated by a State’s border police), by – inter alia –
issuing Terminal Certificates. A Document Verifier is therefore a
Certification Authority, authorised by at least the national CVCA to
issue certificates for national terminals, see [TR-03110-1].
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 109/119
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.
Term Definition
Since the Standard Inspection Procedure does not imply any
certificate-based terminal authentication, the current TOE cannot
recognise a DV as a subject; hence, it merely represents an
organisational entity within this ST.
There can be Domestic and Foreign DV: A domestic DV is acting
under the policy of the domestic CVCA being run by the travel
document Issuer; a foreign DV is acting under a policy of the
respective foreign CVCA (in this case there shall be an appropriate
agreement between the travel document Issuer und a foreign CVCA
ensuring enforcing the travel document Issuer’s privacy policy) 4 5
Eavesdropper A threat agent with low 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. [ICAO-9303]
ePassport
application
[PP-SAC] definition
A part of the TOE containing the non-executable, related user data
(incl. biometric) as well as the data needed for authentication (incl.
MRZ); this application is intended to be used by authorities,
amongst other as a machine readable travel document (MRTD).
See [TR-03110-1].
[PP-EAC] definition
Non-executable data defining the functionality of the operating
system on the IC as the travel document’s chip. It includes
 the file structure implementing the LDS [ICAO-9303],
 the definition of the User Data, but does not include the User
Data itself (i.e. content of EF.DG1 to EF.DG13, EF.DG16,
EF.COM and EF.SOD) and
 the TSF Data including the definition the authentication data
but except the authentication data itself.
Extended Access
Control
Security mechanism identified in [ICAO-9303] by which means the
MTRD’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 Personalization Agent
Authentication Private Key and to get write and read access to the
logical MRTD and TSF data.
4
The form of such an agreement may be of formal and informal nature; the term ‘agreement’ is used in the
current ST in order to reflect an appropriate relationship between the parties involved.
5
Existing of such an agreement may be technically reflected by means of issuing a CCVCA-F for the Public Key of
the foreign CVCA signed by the domestic CVCA.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 110/119
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.
Term Definition
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.
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. [ICAO-9303]
IC Dedicated
Software
Software developed and injected into the chip hardware by the IC
manufacturer. Such software might support special functionality of
the IC hardware and be used, amongst other, for implementing
delivery procedures between different players. The usage of parts of
the IC Dedicated Software might be restricted to certain life phases.
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.
IC Embedded
Software
Software embedded in an IC and not being designed by the IC
developer. The IC Embedded Software is designed in the design life
phase and embedded into the IC in the manufacturing life phase of
the TOE.
IC Identification
Data
The IC manufacturer writes a unique IC identifier to the chip to
control the IC as travel document material during the IC
manufacturing and the delivery process to the travel document
manufacturer.
Impostor A person who applies for and obtains a document by assuming a
false name and identity, or a person who alters his or her physical
appearance to represent himself or herself as another person for the
purpose of using that person’s document.
Improperly
documented
person
A person who travels, or attempts to travel with: (a) an expired
travel document or an invalid visa; (b) a counterfeit, forged or
altered travel document or visa; (c) someone else’s travel document
or visa; or (d) no travel document or visa, if required. [ICAO-9303]
Initialisation Process of writing Initialisation Data (see below) to the TOE (TOE
life-cycle, Phase 2 Manufacturing, Step 3).
Initialisation Data 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).
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 111/119
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.
Term Definition
Inspection The act of a State examining an MRTD presented to it by a traveler
(the MRTD holder) and verifying its authenticity. [ICAO-9303]
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 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). [ICAO-
9303]]
Issuing State The Country issuing the MRTD. [ICAO-9303]
Logical Data
Structure (LDS)
The collection of groupings of Data Elements stored in the optional
capacity expansion technology [ICAO-9303]. The capacity expansion
technology used is the MRTD’s chip.
Logical travel
document
Data of the travel document holder stored according to the Logical
Data Structure [ICAO-9303] as specified by ICAO on the contact
based/contactless integrated circuit. It presents contact
based/contactless readable data including (but not limited to)
1. personal data of the travel document 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
5. the other data according to LDS (EF.DG5 to EF.DG16).
6. EF.COM and EF.SOD
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. [ICAO-9303]
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. [ICAO-9303]
The MRZ-Password is a restricted-revealable secret that is derived
from the machine readable zone and may be used for PACE.
Machine-verifiable
biometrics feature
A unique physical personal identification feature (e.g. an iris pattern,
fingerprint or facial characteristics) stored on a travel document in a
form that can be read and verified by machine. [ICAO-9303]
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 112/119
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.
Term Definition
Manufacturer Generic term for the IC Manufacturer producing integrated circuit
and the travel document Manufacturer completing the IC to the
travel document. The Manufacturer is the default user of the TOE
during the manufacturing life phase. The TOE itself does not
distinguish between the IC Manufacturer and travel document
Manufacturer using this role Manufacturer.
Metadata of a CV
Certificate
Data within the certificate body (excepting Public Key) as described
in [TR-03110-1].
The metadata of a CV certificate comprise the following elements:
- Certificate Profile Identifier,
- Certificate Authority Reference,
- Certificate Holder Reference,
- Certificate Holder Authorisation Template,
- Certificate Effective Date,
- Certificate Expiration Date.
Optional biometric
reference data
Data stored for biometric authentication of the MRTD holder in the
MRTD’s chip as (i) encoded finger image(s) (DG3) or (ii) encoded iris
image(s) (DG4) or (iii) both. Note that the European commission
decided to use only finger print and not to use iris images as
optional biometric reference data.
Password
Authenticated
Connection
Establishment
(PACE)
A communication establishment protocol defined in [ICAO-SAC]. The
PACE Protocol is a password authenticated Diffie-Hellman key
agreement protocol providing implicit password-based authentication
of the communication partners (e.g. smart card and the terminal
connected): i.e. PACE provides a verification, whether the
communication partners share the same value of a password π).
Based on this authentication, PACE also provides a secure
communication, whereby confidentiality and authenticity of data
transferred within this communication channel are maintained.
PACE passwords Passwords used as input for PACE. This may either be the CAN or
the SHA-1-value of the concatenation of Serial Number, Date of
Birth and Date of Expiry as read from the MRZ, see [ICAO-SAC],
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.
Personalisation The process by which the Personalisation Data are stored in and
unambiguously, inseparably associated with the travel document.
This may also include the optional biometric data collected during
the “Enrolment” (cf. paragraph 1.4.3.3, TOE life-cycle, Phase 3, Step
6).
Personalisation
Agent
An organisation acting on behalf of the travel document Issuer to
personalise the travel document for the travel document holder by
some or all of the following activities:
(i) establishing the identity of the travel document holder
for the biographic data in the travel document,
(ii) enrolling the biometric reference data of the travel
document holder,
(iii) writing a subset of these data on the physical travel
document (optical personalisation) and storing them in
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 113/119
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.
Term Definition
the travel document (electronic personalisation) for the
travel document holder as defined in [TR-03110-1],
(iv) writing the document details data,
(v) writing the initial TSF data,
(vi) signing the Document Security Object defined in
[ICAO-9303] (in the role of DS).
Please note that the role ‘Personalisation Agent’ may be distributed
among several institutions according to the operational policy of the
travel document Issuer.
Generating signature key pair(s) is not in the scope of the tasks of
this role.
Personalisation
Data
A set of data incl.
(i) individual-related data (biographic and biometric data)
of the travel document holder,
(ii) dedicated document details data and
(iii) dedicated initial TSF data (incl. the Document Security
Object).
Personalisation data are gathered and then written into the non-
volatile memory of the TOE by the Personalisation Agent in the life-
cycle phase card issuing.
Personalization
Agent
Authentication
Information
TSF data used for authentication proof and verification of the
Personalisation Agent.
Personalisation
Agent Key
Symmetric cryptographic key or key set (MAC, ENC) used
(i) by the Personalisation Agent to prove his identity and
get access to the logical travel document and
(ii) by the MRTD’s chip to verify the authentication attempt
of a terminal as Personalization Agent according to the
SFR
FIA_UAU.1/PACE, FIA_UAU.4/PACE, FIA_UAU.5/PACE.
Physical part of
the travel
document
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
Process of writing Pre-Personalisation Data (see below) to the TOE
including the creation of the travel document Application (TOE life-
cycle, Phase 2, Step 5)
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
Personalization Agent Key Pair and Chip Life-Cycle Production data
(CPLC data).
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 114/119
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.
Term Definition
Pre-personalised
travel document’s
chip
Travel document’s chip equipped with a unique identifier.
Receiving State The Country to which the MRTD holder is applying for entry. [ICAO-
9303]
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.
RF-terminal A device being able to establish communication with an RF-chip
according to ISO/IEC 14443 [ISO14443].
Secondary image A repeat image of the holder’s portrait reproduced elsewhere in the
document by whatever means [ICAO-9303].
Secure messaging
in encrypted
/combined mode
Secure messaging using encryption and message authentication
code according to ISO/IEC 7816-4 [ISO7816]
Service Provider An official organisation (inspection authority) providing inspection
service which can be used by the travel document holder. Service
Provider uses terminals (BIS-PACE) managed by a DV.
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.
Standard
Inspection
Procedure
A specific order of authentication steps between an travel document
and a terminal as required by [ICAO-SAC], namely
(i) PACE or BAC and
(ii) Passive Authentication with SOD.
SIP can generally be used by BIS-PACE and BIS-BAC.
Terminal A terminal is any technical system communicating with the TOE
either through the contact based or contactless interface. A technical
system verifying correspondence between the password stored in
the travel document and the related value presented to the terminal
by the travel document presenter.
In this ST the role ‘Terminal’ corresponds to any terminal being
authenticated by the TOE.
Terminal may implement the terminal’s part of the PACE protocol
and thus authenticate itself to the travel document using a shared
password (CAN or MRZ).
Terminal
Authorization
Intersection of the Certificate Holder Authorizations of the Inspection
System Certificate, the Document Verifier Certificate and Country
Verifier Certification Authority which shall be valid for the Current
Date.
Terminal
Authorisation
Level
Intersection of the Certificate Holder Authorisations defined by the
Terminal Certificate, the Document Verifier Certificate and Country
Verifying Certification Authority which shall be all valid for the
Current Date.
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 115/119
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.
Term Definition
TOE tracing data Technical information about the current and previous locations of the
travel document gathered by inconspicuous (for the travel document
holder) recognising the travel document.
Travel document Official document issued by a state or organisation 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; see [ICAO-9303] (there “Machine readable travel
document”).
Travel document
(electronic)
The contact based or contactless smart card integrated into the
plastic or paper, optical readable cover and providing the following
application: ePassport.
Travel Document
Holder
The rightful holder of the travel document for whom the issuing
State or Organisation personalised the travel document.
Travel document’s
Chip
A contact based/contactless integrated circuit chip complying with
ISO/IEC 14443 [15] and programmed according to the Logical Data
Structure as specified by ICAO, [ICAO-9303], sec III.
Traveler Person presenting the travel document to the inspection system and
claiming the identity of the travel document holder.
TSF data Data created by and for the TOE, that might affect the operation of
the TOE (CC part 1 [CC-1]).
Unpersonalised
travel document
The travel document that contains the travel document chip holding
only Initialisation Data and Pre-personalisation Data as delivered to
the Personalisation Agent from the Manufacturer.
User data All data (being not authentication data)
(i) stored in the context of the ePassport application of the
travel document as defined in [5] and
(ii) being allowed to be read out solely by an authenticated
terminal acting as Basic Inspection System with PACE.
CC give the following generic definitions for user data:
Data created by and for the user that does not affect the operation
of the TSF (CC part 1 [CC-1]). Information stored in TOE resources
that can be operated upon by users in accordance with the SFRs and
upon which the TSF places no special meaning (CC part 2 [CC-2]).
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. [ICAO-9303]
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
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 116/119
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.
Abbreviations
CC Common Criteria, see [CC]
EAL Evaluation Assurance Level
PP Protection Profile
ST Security Target
SEF Security Enforcing Functions
SOF Strength Of Function
TOE Target of Evaluation
TSF TOE Security Functions
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 117/119
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.
References
Reference Description
[AIS20V1] Funktionalitätsklassen und Evaluationsmethodologie für
deterministische Zufallszahlengeneratoren, Version 2.0,
02.12.1999
[AIS20V2] Anwendungshinweise und Interpretationen zum Schema, AIS 20:
Funktionalitaetsklassen und Evaluationsmethodologie fuer
deterministische Zufallszahlengeneratoren, Version 2.1,
02.12.2011, Bundesamt fuer Sicherheit in der Informationstechnik.
[ANSSI-
FRP256V1]
Avis relatif aux paramètres de courbes elliptiques définis par l'Etat
français NOR: PRMD1123151V (Le 18 avril 2012)- ANSSI
(http://www.ssi.gouv.fr/).
[BAC-PP] Common Criteria Protection Profile Machine Readable Travel
Document with „ICAO Application", Basic Access Control, BSI-CC-
PP-0055-2009, Version 1.10, 25th March 2009
[CC-1] Common Criteria for Information Technology Security Evaluation,
Part 1:Introduction and General Model; CCMB-2012-09-001,
Version 3.1, Revision 4, September 2012
[CC-2] Common Criteria for Information Technology Security Evaluation,
Part 2:Security Functional Requirements; CCMB-2012-09-002,
Version 3.1, Revision 4, September 2012
[CC-3] Common Criteria for Information Technology Security Evaluation,
Part 3:Security Assurance Requirements; CCMB-2012-09-003,
Version 3.1, Revision 4, September 2012
[CEM] The Common Methodology for Information Technology Security
Evaluation (CEM), Evaluation Methodology; CCMB-2012-09-004,
Version 3.1, Revision 4, September 2012
[DH] Rescorla, Eric, RFC 2631: Diffie-Hellman key agreement method,
1999
[EAC-PP-V2] Common Criteria Protection Profile Machine Readable Travel
Document with „ICAO Application”, Extended Access Control with
PACE (EAC PP) BSI-CC-PP-0056-V2-2012, Version 1.3.2, December
5th
2012, BSI
[ICAO-9303] International Civil Aviation Organization, ICAO Doc 9303, Machine
Readable Travel Documents – Machine Readable Passports, Version
Sixth Edition, 2006 (this includes the latest supplemental for ICAO
Doc 9303 which also should be considered)
[ICAO-SAC] International Civil Aviation Organization, ICAO MACHINE READABLE
TRAVEL DOCUMENTS, TECHNICAL REPORT, Supplemental Access
Control for Machine Readable Travel Documents, Version 1.00,
November 2010
[ISO14443] ISO/IEC 14443 Identification cards -- Contactless integrated circuit
cards -- Proximity cards, 2008-11
[ISO15946-1] ISO/IEC 15946-1. Information technology – Security techniques –
Cryptographic techniques based on elliptic curves – Part 1:
General, 2002
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 118/119
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.
Reference Description
[ISO15946-2] ISO/IEC15946-2. Information technology – Security techniques –
Cryptographic techniques based on elliptic curves – Part 2: Digital
signatures, 2002.
[ISO15946-3] ISO/IEC 15946: Information technology — Security techniques —
Cryptographic techniques based on elliptic curves — Part 3: Key
establishment, 2002
[ISO18013-3] ISO/IEC 18013-3: Information technology — Personal identification
— ISO-compliant driving licence. Part 3: Access control,
authentication and integrity validation, 2009-03-01
Including ISO/CEI 18013-3/AC1:2011, TECHNICAL CORRIGENDUM
1, Published 2011-12-01
[ISO7816] ISO/IEC 7816: Identification cards — Integrated circuit cards,
Version Second Edition, 2008
[ISO9796-2] ISO/IEC 9796-2: 2002, Information Technology - Security
Techniques - Digital Signature Schemes giving message recovery -
Part 2: Integer factorization based mechanisms
[ISO9797] ISO/IEC 9797-1:1999, Information technology —Security
techniques — Message Authentication Codes (MACs) — Part 1:
Mechanisms using a block cipher.
[JAVA-3.0.1] Application Programming Interface Java Card(tm) Platform, Version
3.0.1, Classic Edition, May 2009, Sun Microsystems, Inc.
[PLTF-PRE] 2014_2000003597 - PRE - IDealCitiz_v2_1 - Preparative
Procedures
[PLTF-ST] 2014_0000002183 Security Target -IDeal Citiz v2.1 open platform
[PLTF-OPE] 2014_200004459 - OPE - IDealCitiz_v2_1 - Operational User
Guidance
[KS2011] A proposal for: Functionality classes for random number
generators, Version 2.0, September 18, 2011 - W. Killmann, W.
Schindler
[NIST-180-4] NIST. FIPS 180-4, Secure Hash Standard, February 2011.
[NIST-186-3] NIST. Digital Signature Standard (DSS), FIPS 186-3, 2009
[NIST-197] NIST. Specification for the Advanced Encryption Standard (AES),
FIPS PUB 197, 2001
[NIST-800-38B] NIST. Recommendation for Block Cipher Modes of Operation: The
CMAC Mode for Authentication, Special Publication 800-38B, 2005
[PACE-PP] Machine Readable Travel Document using Standard Inspection
Procedure with PACE, BSI-CC-PP-0068-V2-2011, Version 1.0.1, 22
July 2014, BSI
[RFC-5639] Lochter, Manfred; Merkle, Johannes. Elliptic Curve Cryptography
(ECC) Brainpool Standard Curves and Curve Generation, RFC 5639,
2010
[RSA-PKCS#3] PKCS #3: Diffie-Hellman Key-Agreement Standard, An RSA
Laboratories Technical Note, Version 1.4, Revised November 1,
1993
[SIC-PP] Security IC Platform Protection Profile; registered and certified by
BSI (Bundesamt für Sicherheit in der Informationstechnik) under
the reference BSI-PP-0035-2007, Version 1.0, June 2007 – BSI
[ST-BAC] 2014_0000000698 - Security Target MICAO on IDealCitiz v2.1,
BAC configuration
[TR-02102] TR-02102 Technische Richtlinie Kryptographische Algorithmen und
Schlüssellängen, Version 2013.02, January 9th
2013 by BSI
Security target LITE for
MICAO 1.1.3 on IDealCitizTM
OS v2.1
SAC/EAC Configuration
Ref.: 2016_2000022974
Page: 119/119
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.
Reference Description
[TR-03110-1] Technical Guideline TR-03110-1, Advanced Security Mechanisms
for Machine Readable Travel Documents –Part 1 – eMRTDs with
BAC/PACEv2 and EACv1, Version 2.10, 20.03.2012 by BSI
[TR-03110-3] TR-03110-3 Advanced Security Mechanisms for Machine Readable
Travel Documents – Part 3: Common Specifications, version 2.10,
2012-03-07 by BSI
[TR-03111] Bundesamt für Sicherheit in der Informationstechnik (BSI),
Technical Guideline TR-03111 Elliptic Curve Cryptography, TR-
03111, Version 1.11, 17.04.2009