Public release.
© Morpho B.V.
Security Target Lite
for the
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0
BAC configuration
a Product of Morpho B.V.
Filename 7301-9302-112 ASE-Lite IDeal Pass v2 - SAC-EAC JC
ePassport 4.0.0 (BAC configuration) v1.0.0.doc
Document version 1.0.0 Approved
Date 2014-01-22
Author Morpho B.V.
Certification ID BSI-DSZ-CC-0867
Classification Public release
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 2 of 111
Table of Contents
1 ST Introduction 5
1.1 ST Reference 5
1.2 TOE Reference 5
1.3 TOE Overview 6
1.4 TOE Description 6
1.4.1 TOE definition 6
1.4.2 TOE usage and security features for operational use 8
1.4.3 TOE life cycle 10
2 Conformance Claims 17
2.1 CC Conformance Claim 17
2.2 PP Claim / Package Claim 17
2.3 PP Conformance Rationale 17
2.3.1 Main aspects 18
2.3.2 Overview of differences between the PP and the ST 18
3 Security Problem Definition 21
3.1 Introduction 21
3.1.1 Assets 21
3.1.2 Subjects 22
3.2 Assumptions 23
3.3 Threats 25
3.3.1 Threats to be averted by the TOE and its environment 25
3.4 Organizational Security Policies 29
4 Security Objectives 31
4.1 Security Objectives for the TOE 31
4.2 Security Objectives for the Operational Environment 35
4.3 Security Objectives Rationale 39
5 Extended Components Definition 44
5.1 Definition of the Family FAU_SAS 44
5.2 Definition of the Family FCS_RND 45
5.3 Definition of the Family FIA_API 46
5.4 Definition of the Family FMT_LIM 47
5.5 Definition of the Family FPT_EMSEC 48
6 Security Requirements 50
6.1 Security Functional Requirements for the TOE 51
6.1.1 Class FAU Security Audit 51
6.1.2 Class Cryptographic Support (FCS) 52
6.1.3 Class FIA Identification and Authentication 58
6.1.4 Class FDP User Data Protection 66
6.1.5 Class FMT Security Management 69
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 3 of 111
6.1.6 Protection of the Security Functions 74
6.2 Security Assurance Requirements for the TOE 78
6.3 Security Requirements Rationale 81
6.3.1 Functional Security Requirements Rationale 81
6.3.2 Dependency Rationale 86
6.3.3 Security Assurance Requirements Rationale 89
6.3.4 Security Requirements – Mutual Support and Internal Consistency 89
7 TOE Summary Specification 91
7.1 SF.I&A Identification and Authentication 91
7.2 SF.CF Cryptographic functions support 93
7.3 SF.ILTB Protection against interference, logical tampering and bypass 97
7.4 SF.AC Access control / Storage and protection of logical travel document data 97
7.5 SF.SM Secure Messaging 98
7.6 SF.LCM Security and life cycle management 99
8 Annex 102
8.1 Glossary 102
8.2 Abbreviations 108
8.3 References 109
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 4 of 111
Document Revision History
Version Date Author Description
1.0.0 2014-01-22 Morpho Public release based on ASE v1.1.3
Distribution List
Name v1.0.0
TÜVIT X
Morpho X
BSI X
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 5 of 111
1 ST Introduction
The aim of this document is to describe the Security Target for the Machine Readable Travel
Document (MRTD) with the ICAO application, Basic Access Control and Active Authentication
on the NXP J3E120_M65 (JCOP2.4.2R3) Java Card Platform.
1.1 ST Reference
Title: ASE-Lite IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0
(BAC configuration)
Version Number: 1.0.0
Document Reference: 7301-9302-112 IDeal Pass v2 - SAC/EAC JC ePassport
4.0.0 (BAC)
Document type: ASE-Lite
CC version: 3.1 Revision 4
Provided by: Morpho B.V.
Evaluation body: TÜV Informationstechnik GmbH (TÜViT)
Certification body: Bundesamt für Sicherheit in der Informationstechnik (BSI)
Evaluation assurance level: EAL4 augmented with ALC_DVS.2
1.2 TOE Reference
TOE Name: IDeal Pass v2 - SAC/EAC JC ePassport
TOE Version: 4.0.0
Developer: Morpho
TOE identification: IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0
Certification ID: BSI-DSZ-CC-0867
Product type / platform Machine Readable Travel Document (MRTD) with the ICAO
application, PACE and Extended Access Control on the
NXP J3E120_M65 (JCOP2.4.2R3) Secure Smart Card
Controller (NSCIB-CC-13-37760)
TOE hardware NXP P5CD145V0B (certificate BSI-DSZ-CC-0858-2013)
and the crypto libraries in the hardware have been certified
by BSI (certificate BSI-DSZ-CC-0750)
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 6 of 111
ST Application note 1: This Security Target defines the security objectives and requirements for
the TOE, the IDeal Pass v2 - SAC/EAC JC ePassport, only as an ePassport with Basic Access
Control (BAC) and Active Authentication. All further security functionality of the TOE, i.e. the
Password Authenticated Connection Establishment (PACE) and the Extended Access Control
(EACv1) functionality is not covered by this certification. PACEv2 and EACv1 have been
evaluated and certified separately under certification ID: BSI-DSZ-CC-0866.
1.3 TOE Overview
The Security Target (ST) defines the security objectives and requirements for the contactless
and contact chip of machine readable travel documents (MRTD) based on the requirements and
recommendations of the International Civil Aviation Organization (ICAO). It addresses the
advanced security method Basic Access Control and Active Authentication in the ‘ICAO Doc
9303’ [ICAO-9303].
Therefore the main features and their origin are the following:
• Authentication by the Basic Access Control (BAC),
using the Document Basic Access Key Derivation Algorithm according to ‘ICAO Doc 9303’
[ICAO-9303], Normative Appendix 5.
• Active Authentication (AA),
to protect the MRTD’s chip against chip substitution according to ‘ICAO Doc 9303’ [ICAO-
9303], Volume II, Section IV, 5.6.2. It prevents copying the LDS Security Object (SOD) and
proves that the SOD has been read from the authentic chip.
1.4 TOE Description
1.4.1 TOE definition
The Target of Evaluation (TOE) is a contact or contactless integrated circuit chip of machine
readable travel documents (MRTD’s chip) programmed according to the Logical Data Structure
(LDS) and providing Basic Access Control according to the ICAO document [ICAO-9303] and the
protection profile [BAC-PP]. Additionally to the [BAC-PP] the TOE provides and Active
Authentication according to [ICAO-9303].
The TOE comprises
• the NXP J3E120_M65 (JCOP2.4.2R3) Secure Smartcard Controller, comprising of
o the circuitry of the MRTD’s chip (the NXP P5CD145V0B integrated circuit, IC) 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;
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 7 of 111
o the IC Embedded Software (operating system): JCOP v2.4.2R3;
• the MRTD application IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 Applet version
1.0.59.300 loaded in ROM or in EEPROM;
• the associated guidance documentation.
For this TOE, only one application will be present on the IC, namely the ICAO MRTD Application.
The TOE utilizes the evaluation of the underlying platform, which includes the NXP chip, the IC
Dedicated Software and the JCOP2.4.2R3 operating system certified by the Dutch NSCIB
Certification Body (NSCIB-CC-13-37760). The hardware platform NXP P5CD145V0B has been
certified by BSI (BSI-DSZ-CC-0858-2013) and the crypto libraries in the hardware have been
certified by BSI (BSI-DSZ-CC-0750).
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.
For this TOE post issuance loading or deletion of Applets is not allowed;
o Native Mifare application, for this TOE the Mifare application is disabled.
• The Applet Layer is the IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 Applet.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 8 of 111
Figure 1: TOE
1.4.2 TOE usage and security features for operational use
A State or organisation issues MRTD to be used by the holder for international travel. The
traveler presents its MRTD to the inspection system to prove his or her identity. The MRTD in the
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 MRTD’s chip according to the LDS for contactless and contact
based machine reading.
The authentication of the traveler is based on:
i. the possession of a valid MRTD personalized for a holder with the claimed identity as
given on the biographical data page and
ii. optional biometrics using the reference data stored in the MRTD.
The issuing State or Organization ensures the authenticity of the data of genuine MRTD’s. The
receiving State trusts genuine MRTD of issuing State or Organization.
The security functionality of the TOE respectively the IDeal Pass v2 - SAC/EAC JC ePassport
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.
For this security target the MRTD is viewed as unit of
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 9 of 111
a) the physical MRTD as travel document in form of paper, plastic and chip. It presents
visual readable data including (but not limited to) personal data of the MRTD holder
(1) the biographical data on the biographical data page of the passport book,
(2) the printed data in the Machine Readable Zone (MRZ) and
(3) the printed portrait.
b) the logical MRTD as data of the MRTD holder stored according to the Logical Data
Structure as specified by ICAO in [ICAO-9303] on the contactless or contact based
integrated circuit. It presents contactless and/or contact based readable data including
(but not limited to) personal data of the MRTD holder
(1) the digital Machine Readable Zone Data (digital MRZ data, EF.DG1),
(2) the digitized portraits (EF.DG2),
(3) the biometric reference data of finger(s) (EF.DG3) or iris image(s) (EF.DG4) or
both1
(4) the other data according to LDS (EF.DG5 to EF.DG16) and
(5) the Document security object.
The issuing State or Organization implements security features of the MRTD to maintain the
authenticity and integrity of the MRTD and their data. The MRTD as the passport book and the
MRTD’s chip is uniquely identified by the document number.
The physical MRTD is protected by physical security measures (e.g. watermark on paper,
security printing), logical (e.g. authentication keys of the MRTD’s chip) and organizational
security measures (e.g. control of materials, personalization procedures) [ICAO-9303]. These
security measures include the binding of the MRTD’s chip to the passport book.
The logical MRTD is protected in authenticity and integrity by a digital signature created by the
document signer acting for the issuing State or Organization and the security features of the
MRTD’s chip.
The ICAO defines the baseline security methods Passive Authentication and the optional
advanced security methods Basic Access Control to the logical MRTD, Active Authentication of
the MRTD’s chip, Extended Access Control to and the Data Encryption of sensitive biometrics as
optional security measure in the ICAO document [ICAO-9303]. The Passive Authentication
Mechanism and the Data Encryption are performed completely and independently of the TOE by
the TOE environment.
This security target addresses the protection of the logical MRTD
i. in integrity by write-only-once access control and by physical means, and
ii. in confidentiality by the Basic Access Control Mechanism, and
1
These additional biometric reference data are optional. Existing data are protected by means of extended access
control.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 10 of 111
iii. in authenticity by the Active Authentication of the MRTD’s chip.
This security target does not address the Extended Access Control as optional security
mechanism.
The Basic Access Control is a security feature which is mandatory supported by the TOE. The
inspection system
(i) reads optically the MRTD,
(ii) authenticates itself as inspection system by means of Document Basic Access Keys.
After successful authentication of the inspection system the MRTD’s chip provides read access
to the logical MRTD by means of private communication (secure messaging) with this inspection
system [ICAO-9303], normative appendix 5.
The Active Authentication is provided by the following steps:
i. the inspection system communicates by means of secure messaging established by
Basic Access Control,
ii. the inspection system read the LDS Document Security Object (SOD) from MRTD
iii. the inspection system reads public key required for Active authentication from LDS DG15
and verifies by means of the Passive Authentication the authenticity of the MRTD’s Active
Authentication Public Key using the Document Security Object,
iv. the inspection system submits the TOE’s Active Authentication command and includes a
generated 8 bytes random number as challenge data.
v. The TOE signs this challenge with the MRTD’s Active Authentication Private Key and
returns the signed challenge response (authentication data),
vi. the inspection system reads the signed challenge response and verifies its signature.
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 PP. These steps are denoted
too in the following although the sequence of the steps differs for the TOE life cycle)
1.4.3.1 Phase 1: “Development”
(Step 1) The TOE is developed in phase 1. The IC developer develops the integrated circuit, the
IC Dedicated Software and the guidance documentation associated with these TOE
components. The IC developer also acts as the developer of the embedded software (operating
system) which is the NXP J3E120_M65 (JCOP2.4.2R3) platform.
(Step 2) The software developer uses the guidance documentation for the integrated circuit and
the guidance documentation for relevant parts of the IC Embedded Software (operating system)
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 11 of 111
and develops the ePassport application and the guidance documentation associated with these
TOE components.
The ePassport application (i.e. the IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 Applet run
time code) may be integrated either in ROM or in EEPROM of the chip. Depending on the
intention
(a) the ePassport application is securely delivered directly from the software developer
(Morpho development dept.) to the IC manufacturer (NXP). The applet code will be
integrated into the ROM mask code by the IC manufacturer, or
(b) either the ePassport application and the guidance documentation is securely delivered
directly from the software developer (Morpho development dept.) to the travel document
manufacturer (Morpho production dept.).
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 12 of 111
IC Manufacturer
Phase 2 - Manufacturing
ROM
EEPROM
Initialization
MRTD Manufacturer
Pre-Personalisation
Personalisation Keys
IDeal Pass v2 -
SAC/EAC JC ePassport
Preparative Guidance
Booklet / Card production
MRTD Holder
Phase 4 - Operational use
Inlay Manufacturing
`
Operational use
Sample Authentication
Transport and
Authentication Keys
Pre-Personalisation
Keys
Software Developer
Phase 1 - Development
IC Developer
NXP P5CD0145V1B
NXP JCOP Guidance
Documentation
NXP JCOP 2.4.2 R3
IDeal pass v2 -
SAC/EAC JC
ePassport applet
Personalization
Personalization Agent
Phase 3 - Personalization
AGD_PRE +
AGD_OPE
SAC/EAC JC
ePassport applet
JCOP AGD_PRE JCOP AGD_OPE
NXP JCOP Guidance
Documentation
Chip modules
Transport key
+ Authentication key
eMRTD
Personalisation
key set
Personalised
eMRTD
(ePassport)
(1a)
(2a)
(1b)
(3) (4)
(5)
(6)
(7) (8)
(9)
(10)
(11)
(12)
(C)
(B)
SAC/EAC JC
ePassport applet
+ ALC_LCD
(2b)
Figure 2: TOE Life-cycle
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 13 of 111
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
(ROM). The IC manufacturer writes the IC Identification Data onto the chip to control the IC as
travel document material during the IC manufacturing and the delivery process to the travel
document manufacturer. The IC is securely delivered from the IC manufacturer to the travel
document manufacturer.
If necessary the IC manufacturer adds the parts of the IC Embedded Software in the non-volatile
programmable memories (for instance EEPROM).
(Step4) The travel document manufacturer combines the IC with hardware for the contact
based / contactless interface in the travel document unless the travel document consists of
the chip only.
(Step5) The travel document manufacturer
(i) in case of alternative b), adds the ePassport application in the non-volatile programmable
memories (for instance EEPROM or FLASH) if necessary,
(ii) creates the ePassport application and
(iii) equips travel document’s chips with pre-personalization Data.
BAC 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 [BAC-PP] apply:
• MRTD’s chip Dedicated SW = Low level IC libraries
• travel document’s chip Embedded Software = JCOP 2.4.2 Revision 3 operating system.
• ePassport application = the IDeal Pass v2 SAC/EAC JC ePassport 4.0.0 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 the IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 Applet
provide configuration and life-cycle management functions required for TOE preparation. TOE
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 14 of 111
preparation steps are performed in manufacturing phase and consists of the following 2
activities:
1. Platform initialisation
2. Pre-personalisation
Platform initialisation
Platform initialisation consists of the configuration of the JCOP platform in accordance with
requirements specified in the JCOP platform administrator guidance [JCOP-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 IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 Applet runtime code
does not reside in ROM, it is loaded into EEPROM.
c. Create applet instance for IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 Applet (i.e.
installation of the IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 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].
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: “Personalization of the MRTD”
(Step 6) The personalization of the MRTD includes
i. the survey of the MRTD holder’s biographical data,
ii. the enrolment of the MRTD holder biometric reference data (i.e. the digitized portraits and
the optional biometric reference data),
iii. the printing of the visual readable data onto the physical MRTD,
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 15 of 111
iv. the writing the TOE User Data and TSF Data into the logical MRTD and
v. the writing the TSF Data into the logical MRTD and configuration of the TSF if necessary.
The step (iv) is performed by the Personalization Agent and includes but is not limited to the
creation of
i. the digital MRZ data (EF.DG1),
ii. the digitized portrait (EF.DG2), and
iii. the document security object.
The signing of the Document security object by the Document signer [ICAO-9303] finalizes the
personalization of the genuine MRTD for the MRTD holder. The personalized MRTD (together
with appropriate guidance (AGD_OPE) for TOE use if necessary) is handed over to the MRTD
holder for operational use.
BAC 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 Personalization Agent Authentication Key(s), the
Basic Authentication Control Key and (for this Security Target) the Active Authentication Key.
BAC PP Application note 3:
This Security Target distinguishes between the Personalization Agent as entity known to the
TOE and the Document Signer as entity in the TOE IT environment signing the Document
security object as described in [ICAO-9303]. This approach allows but does not enforce the
separation of these roles. The selection of the authentication keys should consider the
organization, the productivity and the security of the personalization process. Asymmetric
authentication keys provide comfortable security for distributed personalization but their use may
be more time consuming than authentication using symmetric cryptographic primitives.
Authentication using symmetric cryptographic primitives allows fast authentication protocols
appropriate for centralized personalization schemes but relies on stronger security protection in
the personalization environment.
The Personalization Agent authenticates by using two symmetric keys (MAC and ENC). In
Personalisation life-cycle state the TOE enforces mutual authentication between Personalisation
Agent and TOE based on either of the following symmetric key authentication mechanism:
• ICAO BAC authentication mechanism and secure messaging protocol defined in [ICAO-9303]
for 112 bits 3DES with pre-installed MAC, ENC (and KEK) keys as Personalisation Agent
Key set.
• ISO18013 BAP authentication mechanism defined in [ISO18013-3] for AES-128, 192 or 256
bits using AES secure messaging (CMAC, IV value, tags etc.) as specified in EAC TR-03110
[TR-03110-1] with pre-installed MAC, ENC (and KEK) keys as Personalisation Agent Key set.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 16 of 111
1.4.3.4 Phase 4: “Operational Use”
(Step 7) The TOE is used as MRTD’s chip by the traveler and the inspection systems in the
“Operational Use” phase. The user data can be read according to the security policy of the
Issuing State or Organization and can be used according to the security policy of the Issuing
State but they can never be modified.
BAC PP Application note 4: The authorized Personalization Agents might be allowed to add
(not to modify) data in the other data groups of the MRTD application (e.g. person(s) to notify
EF.DG16) in the Phase 4 “Operational Use”. This will imply an update of the Document Security
Object including the re-signing by the Document Signer.
BAC PP Application note 5: The intention of this Security Target 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 2 or later. Since specific production
steps of phase 2 are of minor security relevance (e. g. booklet manufacturing and antenna
integration) these are not part of the CC evaluation under ALC. Nevertheless the decision about
this has to be taken by the certification body resp. the national body of the issuing State or
Organization. In this case the national body of the issuing State or Organization is responsible for
these specific production steps.
Note, that the personalization process and its environment may depend on specific security
needs of an issuing State or Organization. All production, generation and installation procedures
after TOE delivery up to the “Operational Use” (phase 4) have to be considered in the product
evaluation process under AGD assurance class. Therefore, the Security Target has to outline the
split up of P.Manufact, P.Personalization and the related security objectives into aspects relevant
before vs. after TOE delivery.
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 MRTD, nevertheless these parts
are not inevitable for the secure operation of the TOE.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 17 of 111
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 with
o FAU_SAS Audit data storage
o FCS_RND Generation of random numbers
o FIA_API Authentication proof of identity
o FMT_LIM Limited capabilities and availability
o FPT_EMSEC TOE emanation
• 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 / Package Claim
This security target claims strict conformance to:
• Common Criteria Protection Profile - Machine Readable Travel Document with „ICAO
Application", Basic Access Control, BSI-PP-0055, Version 1.10, 25th
March. 2009 [BAC-
PP]
This ST is conforming to assurance package EAL4 augmented with ALC_DVS.2 defined in CC
part 3 [CC-3].
2.3 PP Conformance Rationale
This ST is claimed to be strict conformant to the above mentioned PP [BAC-PP]. A detailed
justification is given in the following.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 18 of 111
2.3.1 Main aspects
• The TOE description (ch. 1.4) is based on the TOE description of [BAC-PP, 2]. It was
only enhanced by product specific details.
• All definitions of the security problem definition in [BAC-PP, 3] have been taken exactly
from the PP in the same wording.
• All security objectives have been taken exactly from [BAC-PP, 4] in the same wording
with one exception (see ch. 2.3.2 below)
• The part of extended components definition has been taken originally from [BAC-PP, 5].
• All SFRs for the TOE have been taken originally from the [BAC-PP, 5.1] added by
according iterations, selections and assignments.
• The security assurance requirements (SARs) have been taken originally from the PP.
2.3.2 Overview of differences between the PP and the ST
Assets
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.
Threats
The threat T.Counterfeit has been added to describe an unauthorized copy or reproduction of a
genuine MRTD’s chip.
T.Counterfeit MRTD’s Chip
Adverse action: An attacker with high attack potential produces an unauthorized copy or
reproduction of a genuine MRTD’s chip to be used as part of a counterfeit
MRTD. This violates the authenticity of the MRTD’s chip used for authentication
of a traveler by possession of a MRTD. The attacker may generate a new data
set or extract completely or partially the data from a genuine MRTD’s chip and
copy them on another appropriate chip to imitate this genuine MRTD’s chip.
Threat agent: having high attack potential, being in possession of one or more legitimate
MRTDs
Asset: authenticity of logical MRTD data,
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 19 of 111
Assumptions
One assumption was added to cover Active Authentication during personalization:
A.Pers_Agent_AA Personalization of the MRTD’s chip (Active Authentication)
Additionally to A.Pers_Agent the Personalization Agent ensures the correctness of the
Active Authentication Public Key (EF.DG15) if stored on the MRTD’s chip.
Security objectives for the TOE
The OT.AC_Pers has been enhanced by a restriction as follows:
OT.AC_Pers Access Control for Personalization of logical MRTD
The TOE must ensure that the logical MRTD 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 Personalization Agents only. The logical MRTD data in EF.DG1 to EF.DG16
and the TSF data may be written only during and cannot be changed after its
personalization. The Document security object can be updated by authorized
Personalization Agents if data in the data groups EF.DG3 to EF.DG16 are added.
For this TOE the logical MRTD data in EF.DG1 to EF.DG16 and the TSF data may be
written only during personalization and cannot be changed or added (filled) afterwards.
The OT.Chip_Auth_Proof was added to cover also Active Authentication as follows:
OT.Chip_Auth_Proof Proof of MRTD’S chip authenticity
The TOE must support the Basic and General Inspection Systems, to verify the identity and
authenticity of the MRTD’s chip as issued by the identified issuing State or Organization by
means of the Active Authentication as defined in [ICAO-9303]. The authenticity prove provided
by MRTD’s chip shall be protected against attacks with high attack potential.
Security Objectives for the Environment
The OE.Auth_Key_MRTD was added to consider the AA Key pair.
The OE.AA_MRTD has been added by the Basic and General inspection systems.
These additions to the original objectives of the PP do not contradict with any other objective nor
mitigate a threat (or part of a threat) meant to be addressed by security objectives for the TOE in
the PP.
Their definitions are:
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 20 of 111
OE.Auth_Key_MRTD MRTD Authentication Key
The issuing State or Organization has to establish the necessary public key infra-structure in
order to
i. generate the MRTD’s Active Authentication Key Pair,
ii. store the Active Authentication Private Key, and store the Active Authentication Public
Key in the Active Authentication Public Key data in EF.DG15 (if generated), and
iii. support inspection systems of receiving States or organizations to verify the
authenticity of the MRTD’s chip used for genuine MRTD by certification of the Active
Authentication Public Key by means of the Document Security Object.
OE.Exam_MRTD Examination of the MRTD passport book
The inspection system of the Receiving State must examine the MRTD presented by the traveler
to verify its authenticity by means of the physical security measures and to detect any
manipulation of the physical MRTD. The Basic Inspection System for global interoperability
i. includes the Country Signing Public Key and the Document Signer Public Key of each
issuing State or Organization, and
ii. implements the terminal part of the Basic Access Control [ICAO-9303]. .
OE.AA_MRTD Active Authentication – Inspection Systems
An Active Authentication (Basic, General or Extended) Inspection system performs all the
functions of the Basic, General, respectively Extended Inspection System, and verifies the IC
authenticity with an RSA or ECDSA signature generated by the MRTD (if available).
Security functional requirements
The Security Target enhances the following security functional requirements to support Active
Authentication:
• FDP_ACF.1 Security attribute based access control- Basic Access Control
• FMT_MTD.1/KEY_WRITE Management of TSF data – Key Write
• FMT_MTD.1/KEY_READ Management of TSF data – Key Read
• FPT_EMSEC.1/ TOE Emanation
• FMT_SMR.1 Security roles
This Security Target adds the following security functional requirements to support Active
Authentication:
• FCS_COP.1/SIG_GEN Cryptographic operation – RSA or ECDSA Signature
• FIA_API.1/AA Authentication proof of identity
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 21 of 111
3 Security Problem Definition
3.1 Introduction
3.1.1 Assets
The assets to be protected by the TOE include the User Data on the MRTD’s chip.
Logical MRTD Data
The logical MRTD data consists of the EF.COM and the data groups DG1 to DG16 (with
different security needs) and the Document security object EF.SOD according to LDS
[ICAO-9303]. These data are user data of the TOE. The EF.COM lists the existing
elementary files (EF) with the user data. The EF.DG1 to EF.DG13 and EF.DG16 contain
personal data of the MRTD holder. The Active Authentication Public Key (EF.DG15) is
used by the inspection system for Active Authentication of the chip. The Chip
Authentication Public Key (EF.DG14) is used by the inspection system for the Chip
Authentication. The EF.SOD is used by the inspection system for Passive Authentication
of the logical MRTD.
Due to interoperability reasons as the ‘ICAO Doc 9303’ [ICAO-9303] the TOE described
in this security target specifies only the BAC mechanisms with resistance against
enhanced basic attack potential granting access to:
• Logical MRTD standard User Data (i.e. Personal Data) of the MRTD holder (EF.DG1,
EF.DG2, EF.DG5 to EF.DG13, EF.DG16)
• Chip Authentication Public Key in EF.DG14
• Active Authentication Public Key in EF.DG15
• Document Security Object (SOD) in EF.SOD
• Common data in EF.COM
The TOE prevents access to sensitive User Data
• Sensitive biometric reference data (EF.DG3, EF.DG4)
A sensitive asset is the following more general one.
Authenticity of the MRTD’s chip
The authenticity of the MRTD’s chip personalized by the issuing State or Organization for
the MRTD holder is used by the traveler to proof his possession of a genuine MRTD.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 22 of 111
3.1.2 Subjects
This security target considers the following subjects:
Manufacturer
The generic term for the IC Manufacturer producing the integrated circuit and the MRTD
Manufacturer completing the IC to the MRTD’s chip. The Manufacturer is the default user
of the TOE during the Phase 2 Manufacturing. The TOE does not distinguish between the
users IC Manufacturer and MRTD Manufacturer using this role Manufacturer.
Personalization Agent
The agent is acting on the behalf of the issuing State or Organisation to personalize the
MRTD for the holder by some or all of the following activities
i. establishing the identity the holder for the biographic data in the MRTD,
ii. enrolling the biometric reference data of the MRTD holder i.e. the portrait, the
encoded finger image(s) and/or the encoded iris image(s)
iii. writing these data on the physical and logical MRTD for the holder as defined for
global, international and national interoperability,
iv. writing the initial TSF data and
v. signing the Document Security Object defined in [ICAO-9303].
Terminal
A terminal is any technical system communicating with the TOE through the
contactless/contact interface.
Inspection system
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..
The Basic Inspection System (BIS)
i. contains a terminal for the contactless/contact based communication with the
MRTD’s chip,
ii. implements the terminals part of the Basic Access Control Mechanism and
iii. gets the authorization to read the logical MRTD under the Basic Access Control
by optical reading the MRTD or other parts of the passport book providing this
information.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 23 of 111
iv. is recommend to perform Active Authentication (AA). AA verifies the identity and
authenticity of the MTRD’s chip as part of a genuine MRTD issued by a known
State of organization.
The General Inspection System (GIS) is a Basic Inspection System which implements
additional the Chip Authentication Mechanism.
The Extended Inspection System (EIS) in addition to the General Inspection System
i. implements the Terminal Authentication Protocol and
ii. is authorized by the issuing State or Organization through the Document Verifier
of the receiving State to read the sensitive biometric reference data.
The security attributes of the EIS are defined of the Inspection System Certificates.
MRTD Holder
The rightful holder of the MRTD for whom the issuing State or Organization personalized
the MRTD.
Traveler
Person presenting the MRTD to the inspection system and claiming the identity of the
MRTD holder.
Attacker
A threat agent trying
i. to identify and to trace the movement the MRTD’s chip remotely (i.e. without
knowing or optically reading the physical MRTD),
ii. to read or to manipulate the logical MRTD without authorization, or
iii. to forge a genuine MRTD.
BAC PP Application note 7: An impostor is attacking the inspection system as TOE IT
environment independent on using a genuine, counterfeit or forged MRTD. Therefore the
impostor may use results of successful attacks against the TOE but the attack itself is not
relevant for the TOE.
3.2 Assumptions
The assumptions describe the security aspects of the environment in which the TOE will be used
or is intended to be used.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 24 of 111
A.MRTD_Manufact MRTD manufacturing on steps 4 to 6
It is assumed that appropriate functionality testing of the MRTD is used. It is assumed
that security procedures are used during all manufacturing and test operations to
maintain confidentiality and integrity of the MRTD and of its manufacturing and test data
(to prevent any possible copy, modification, retention, theft or unauthorized use).
A.MRTD_Delivery MRTD delivery during steps 4 to 6
Procedures shall guarantee the control of the TOE delivery and storage process and
conformance to its objectives:
• Procedures shall ensure protection of TOE material/information under delivery and
storage.
• Procedures shall ensure that corrective actions are taken in case of improper operation in
the delivery process and storage.
• Procedures shall ensure that people dealing with the procedure for delivery have got the
required skill.
A.Pers_Agent Personalization of the MRTD’s chip
The Personalization Agent ensures the correctness of
i. the logical MRTD with respect to the MRTD holder,
ii. the Document Basic Access Keys,
iii. the Chip Authentication Public Key (EF.DG14) if stored on the MRTD’s chip,
iv. the Active Authentication Public Key (EF.DG15) if stored on the MRTD’s chip, and
v. the Document Signer Public Key Certificate (if stored on the MRTD’s chip).
The Personalization Agent signs the Document Security Object. The Personalization
Agent bears the Personalization Agent Authentication to authenticate himself to the TOE
by symmetric cryptographic mechanisms.
A.Pers_Agent_AA Personalization of the MRTD’s chip (Active Authentication)
Additionally to A.Pers_Agent the Personalization Agent ensures the correctness of the
Active Authentication Public Key (EF.DG15) if stored on the MRTD’s chip.
A.Insp_Sys Inspection Systems for global interoperability
The Inspection System is used by the border control officer of the receiving State
i. examining an MRTD presented by the traveler and verifying its authenticity and
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 25 of 111
ii. verifying the traveler as MRTD holder.
The Basic Inspection System for global interoperability
i. includes the Country Signing Public Key and the Document Signer Public Key of
each issuing State or Organization, and
ii. implements the terminal part of the Basic Access Control [ICAO-9303].
The Basic Inspection System reads the logical MRTD being under Basic Access Control
and performs the Passive Authentication to verify the logical MRTD.
BAC PP Application note 8: According to [ICAO-9303] the support of the Passive
Authentication mechanism is mandatory whereas the Basic Access Control is optional.
This ST does not address Primary Inspection Systems therefore the BAC is mandatory
within this ST.
A.BAC-Keys Cryptographic quality of Basic Access Control Keys
The Document Basic Access Control Keys being generated and imported by the issuing
State or Organization have to provide sufficient cryptographic strength. As a
consequence of the ‘ICAO Doc 9303’ [ICAO-9303], the Document Basic Access Control
Keys are derived from a defined subset of the individual printed MRZ data. It has to be
ensured that these data provide sufficient entropy to withstand any attack based on the
decision that the inspection system has to derive Document Access Keys from the printed
MRZ data with enhanced basic attack potential.
BAC PP Application note 9: When assessing the MRZ data resp. the BAC keys entropy
potential dependencies between these data (especially single items of the MRZ) have to
be considered and taken into account. E.g. there might be a direct dependency between
the Document Number when chosen consecutively and the issuing date.
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.
3.3.1 Threats to be averted by the TOE and its environment
The TOE in collaboration with its IT environment shall avert the threats as specified below.
T.Chip_ID Identification of MRTD’s chip
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 26 of 111
Adverse action: An attacker trying to trace the movement of the MRTD by identifying remotely
the MRTD’s chip by establishing or listening to communications through the
contactless/contact based communication interface.
Threat agent: having enhanced basic attack potential, not knowing the optically readable MRZ
data printed on the MRTD data page in advance
Asset: Anonymity of user,
T.Skimming Skimming the logical MRTD
Adverse action: An attacker imitates an inspection system trying to establish a communication to
read the logical MRTD or parts of it via the contactless/contact communication
channel of the TOE.
Threat agent: having enhanced basic attack potential, not knowing the optically readable MRZ
data printed on the MRTD data page in advance
Asset: confidentiality of logical MRTD data
T.Eavesdropping Eavesdropping to the communication between TOE and
inspection system
Adverse action: An attacker is listening to an existing communication between the MRTD’s chip
and an inspection system to gain the logical MRTD or parts of it. The inspection
system uses the MRZ data printed on the MRTD data page but the attacker does
not know these data in advance.
Threat agent: having enhanced basic attack potential, not knowing the optically readable MRZ
data printed on the MRTD data page in advance
Asset: confidentiality of logical MRTD data
T.Forgery Forgery of data on MRTD’s chip
Adverse action: An attacker alters fraudulently the complete stored logical MRTD or any part of it
including its security related data in order to deceive on an inspection system by
means of the changed MRTD holder’s identity or biometric reference data.
This threat comprises several attack scenarios of MRTD forgery. The attacker
may alter the biographical data on the biographical data page of the passport
book, in the printed MRZ and in the digital MRZ to claim another identity of the
traveler. The attacker may alter the printed portrait and the digitized portrait to
overcome the visual inspection of the inspection officer and the automated
biometric authentication mechanism by face recognition. The attacker may alter
the biometric reference data to defeat automated biometric authentication
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 27 of 111
mechanism of the inspection system. The attacker may combine data groups of
different logical MRTDs to create a new forged MRTD, e.g. the attacker writes
the digitized portrait and optional biometric reference finger data read from the
logical MRTD of a traveler into another MRTD’s chip leaving their digital MRZ
unchanged to claim the identity of the holder this MRTD. The attacker may also
copy the complete unchanged logical MRTD to another contactless/contact chip.
Threat agent: having enhanced basic attack potential, being in possession of one or more
legitimate MRTDs
Asset: authenticity of logical MRTD data,
The TOE shall avert the threats as specified below.
T.Abuse-Func Abuse of Functionality
Adverse action: An attacker may use functions of the TOE which shall not be used in
“Operational Use” phase in order (i) to manipulate User Data, (ii) to manipulate
(explore, bypass, deactivate or change) security features or functions of the TOE
or (iii) to disclose or to manipulate TSF Data.
This threat addresses the misuse of the functions for the initialization and the
personalization in the operational state after delivery to MRTD holder.
Threat agent: having high attack potential, being in possession of a legitimate MRTD
Asset: confidentiality and authenticity of logical MRTD and TSF data, correctness of
TSF
T.Information_Leakage Information Leakage from MRTD’s chip
Adverse action: An attacker may exploit information which is leaked from the TOE during its
usage in order to disclose confidential TSF data. The information leakage may
be inherent in the normal operation or caused by the attacker.
Leakage may occur through emanations, variations in power consumption, I/O
characteristics, clock frequency, or by changes in processing time requirments.
This leakage may be interpreted as a covert channel transmission but is more
closely related to measurement of operating parameters which may be derived
either from measurements of the contactless/contact interface (emanation) or
direct measurements (by contact to the chip still available even for a contactless
chip) and can then be related to the specific operation being performed.
Examples are the Differential Electromagnetic Analysis (DEMA) and the
Differential Power Analysis (DPA). Moreover the attacker may try actively to
enforce information leakage by fault injection (e.g. Differential Fault Analysis).
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 28 of 111
Threat agent: having high attack potential, being in possession of a legitimate MRTD
Asset: confidentiality of logical MRTD and TSF data
T.Phys-Tamper Physical Tampering
Adverse action: An attacker may perform physical probing of the MRTD’s chip in order (i) to
disclose TSF Data, or (ii) to disclose/reconstruct the MRTD’s chip Embedded
Software. An attacker may physically modify the MRTD’s chip in order to (i)
modify security features or functions of the MRTD’s chip, (ii) modify security
functions of the MRTD’s chip Embedded Software, (iii) modify User Data or (iv)
to modify TSF data.
The physical tampering may be focused directly on the disclosure or
manipulation of TOE User Data (e.g. the biometric reference data for the
inspection system) or TSF Data (e.g. authentication key of the MRTD’s chip) or
indirectly by preparation of the TOE to following attack methods by modification
of security features (e.g. to enable information leakage through power analysis).
Physical tampering requires direct interaction with the MRTD’s chip internals.
Techniques commonly employed in IC failure analysis and IC reverse
engineering efforts may be used. Before that, the hardwaresecurity mechanisms
and layout characteristics need to be identified. Determination of software design
including treatment of User Data and TSF Data may also be a pre-requisite. The
modification may result in the deactivation of a security function. Changes of
circuitry or data can be permanent or temporary.
Threat agent: having high attack potential, being in possession of a legitimate MRTD
Asset: confidentiality and authenticity of logical MRTD and TSF data, correctness of
TSF
T.Malfunction Malfunction due to Environmental Stress
Adverse action: An attacker may cause a malfunction of TSF or of the MRTD’s chip Embedded
Software by applying environmental stress in order to (i) deactivate or modify
security features or functions of the TOE or (ii) circumvent, deactivate or modify
security functions of the MRTD’s chip Embedded Software.
This may be achieved e.g. by operating the MRTD’s chip outside the normal
operating conditions, exploiting errors in the MRTD’s chip Embedded Software or
misusing administration function. To exploit these vulnerabilities an attacker
needs information about the functional operation.
Threat agent: having high attack potential, being in possession of a legitimate MRTD
Asset: confidentiality and authenticity of logical MRTD and TSF data, correctness of
TSF
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 29 of 111
T.Counterfeit MRTD’s chip2
Adverse action: An attacker with high attack potential produces an unauthorized copy or
reproduction of a genuine MRTD’s chip to be used as part of a counterfeit
MRTD. This violates the authenticity of the MRTD’s chip used for authentication
of a traveler by possession of a MRTD. The attacker may generate a new data
set or extract completely or partially the data from a genuine MRTD’s chip and
copy them on another appropriate chip to imitate this genuine MRTD’s chip.
Threat agent: having high attack potential, being in possession of one or more legitimate
MRTDs
Asset: authenticity of logical MRTD data,
3.4 Organizational 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).
P.Manufact Manufacturing of the MRTD’s chip
The Initialization Data are written by the IC Manufacturer to identify the IC uniquely. The
MRTD Manufacturer writes the Pre-personalization Data which contains at least the
Personalization Agent Key.
P.Personalization Personalization of the MRTD by issuing State or Organization
only
The issuing State or Organization guarantees the correctness of the biographical data,
the printed portrait and the digitized portrait, the biometric reference data and other data
of the logical MRTD with respect to the MRTD holder. The personalization of the MRTD
for the holder is performed by an agent authorized by the issuing State or Organization
only.
2
Added by the ST author
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 30 of 111
P.Personal_Data Personal data protection policy
The biographical data and their summary printed in the MRZ and stored on the MRTD’s
chip (EF.DG1), the printed portrait and the digitized portrait (EF.DG2), the biometric
reference data of finger(s) (EF.DG3), the biometric reference data of iris image(s)
(EF.DG4) and data according to LDS (EF.DG5 to EF.DG13, EF.DG16) stored on the
MRTD’s chip are personal data of the MRTD holder. These data groups are intended to
be used only with agreement of the MRTD holder by inspection systems to which the
MRTD is presented. The MRTD’s chip shall provide the possibility for the Basic Access
Control to allow read access to these data only for terminals successfully authenticated
based on knowledge of the Document Basic Access Keys as defined in [ICAO-9303].
BAC PP Application note 10: The organizational security policy P.Personal_Data is
drawn from the ICAO ‘ICAO Doc 9303’ [ICAO-9303]. Note that the Document Basic
Access Key is defined by the TOE environment and loaded to the TOE by the
Personalization Agent.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 31 of 111
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.
OT.AC_Pers Access Control for Personalization of logical MRTD
The TOE must ensure that the logical MRTD 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 Personalization Agents only. The logical MRTD data in EF.DG1 to EF.DG16
and the TSF data may be written only during and cannot be changed after its
personalization. The Document security object can be updated by authorized
Personalization Agents if data in the data groups EF.DG3 to EF.DG16 are added.
For this TOE the logical MRTD data in EF.DG1 to EF.DG16 and the TSF data may be
written only during personalization and cannot be changed or added (filled) afterwards.
BAC PP Application note 11:The OT.AC_Pers implies that (1) the data of the LDS
groups written during personalization for MRTD holder (at least EF.DG1 and EF.DG2)
can not be changed by write access after personalization, (2) the Personalization Agents
may (i) add (fill) data into the LDS data groups not written yet, and (ii) update and sign the
Document Security Object accordingly. The support for adding data in the “Operational
Use” phase is optional.
OT.Data_Int Integrity of personal data
The TOE must ensure the integrity of the logical MRTD stored on the MRTD’s chip
against physical manipulation and unauthorized writing. The TOE must ensure that the
inspection system is able to detect any modification of the transmitted logical MRTD data.
OT.Data_Conf Confidentiality of personal data
The TOE must ensure the confidentiality of the logical MRTD data groups EF.DG1 to
EF.DG16. Read access to EF.DG1 to EF.DG16 is granted to terminals successfully
authenticated as Personalization Agent. Read access to EF.DG1, EF.DG2 and EF.DG5
to EF.DG16 is granted to terminals successfully authenticated as Basic Inspection
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 32 of 111
System. The Basic Inspection System shall authenticate itself by means of the Basic
Access Control based on knowledge of the Document Basic Access Key. The TOE must
ensure the confidentiality of the logical MRTD data during their transmission to the Basic
Inspection System.
BAC PP Application note 12: The traveler grants the authorization for reading the
personal data in EF.DG1, EF.DG2 and EF.DG5 to EF.DG16 to the inspection system by
presenting the MRTD. The MRTD’s chip shall provide read access to these data for
terminals successfully authenticated by means of the Basic Access Control based on
knowledge of the Document Basic Access Keys.
The security objective OT.Data_Conf requires the TOE to ensure the strength of the
security function Basic Access Control Authentication. The Document Basic Access Keys
are derived from the MRZ data defined by the TOE environment and are loaded into the
TOE by the Personalization Agent. Therefore the sufficient quality of these keys has to
result from the MRZ data’s entropy. Any attack based on decision of the ‘ICAO Doc 9303’
[ICAO-9303] that the inspection system derives Document Basic Access is ensured by
OE.BAC-Keys. Note that the authorization for reading the biometric data in EF.DG3 and
EF.DG4 is only granted after successful Enhanced Access Control not covered by this
protection profile. Thus the read access must be prevented even in case of a successful
BAC Authentication.
OT.Identification Identification and Authentication of the TOE
The TOE must provide means to store IC Identification and Pre-Personalization Data in
its non-volatile memory. The IC Identification Data must provide a unique identification of
the IC during Phase 2 “Manufacturing” and Phase 3 “Personalization of the MRTD”. The
storage of the Pre-Personalization data includes writing of the Personalization Agent
Key(s). In Phase 4 “Operational Use” the TOE shall identify itself only to a successful
authenticated Basic Inspection System or Personalization Agent.
BAC PP Application note 13: The TOE security objective OT.Identification addresses
security features of the TOE to support the life cycle security in the manufacturing and
personalization phases. The IC Identification Data are used for TOE identification in
Phase 2 “Manufacturing” and for traceability and/or to secure shipment of the TOE from
Phase 2 “Manufacturing” into the Phase 3 “Personalization of the MRTD”. The
OT.Identification addresses security features of the TOE to be used by the TOE
manufacturing. In the Phase 4 “Operational Use” the TOE is identified by the Document
Number as part of the printed and digital MRZ. The OT.Identification forbids the output of
any other IC (e.g. integrated circuit card serial number ICCSN) or MRTD identifier through
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 33 of 111
the contactless/contact interface before successful authentication as Basic Inspection
System or as Personalization Agent.
The TOE must support the General and Basic Inspection Systems to verify the identity
and authenticity of the MRTD’s chip as issued by the identified issuing State or
Organization by means of Active Authentication as defined in [ICAO-9303]5. The
authenticity prove provided by MRTD’s chip shall be protected against attacks with
enhanced basic attack potential.
The following TOE security objectives address the protection provided by the MRTD’s chip
independent of the TOE environment.
OT.Chip_Auth_Proof Proof of MRTD’S chip authenticity3
The TOE must support the Basic and General Inspection Systems to verify the identity
and authenticity of the MRTD’s chip as issued by the identified issuing State or
Organization by means of the Active Authentication as defined in [ICAO-9303]. The
authenticity prove provided by MRTD’s chip shall be protected against attacks with
enhanced basic attack potential.
OT.Prot_Abuse-Func Protection against Abuse of Functionality
The TOE must prevent functions of the TOE which may not be used after TOE delivery
can be abused in order
i. to disclose critical User Data,
ii. to manipulate critical User Data of the IC Embedded Software,
iii. to manipulate Soft-coded IC Embedded Software or
iv. bypass, deactivate, change or explore security features or functions of the TOE.
Details of the relevant attack scenarios depend, for instance, on the capabilities of the
Test Features provided by the IC Dedicated Test Software which are not specified here.
OT.Prot_Inf_Leak Protection against Information Leakage
The TOE must provide protection against disclosure of confidential TSF data stored
and/or processed in the MRTD’s chip
3
Added by the ST author
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 34 of 111
• by measurement and analysis of the shape and amplitude of signals or the time
between events found by measuring signals on the electromagnetic field, power
consumption, clock, or I/O lines and
• by forcing a malfunction of the TOE and/or
• by a physical manipulation of the TOE.
BAC PP Application note 14: This objective pertains to measurements with subsequent
complex signal processing due to normal operation of the TOE or operations enforced by
an attacker. Details correspond to an analysis of attack scenarios which is not given here.
OT.Prot_Phys-Tamper 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 has not been
proven or tested. This is to prevent errors. The environmental conditions may include
external energy (esp. electromagnetic) fields, voltage (on any contacts), clock frequency,
or temperature.
BAC PP Application note 15: A malfunction of the TOE may also be caused using a
direct interaction with elements on the chip surface. This is considered as being a
manipulation (refer to the objective OT.Prot_Phys-Tamper) provided that detailed
knowledge about the TOE´s internals.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 35 of 111
4.2 Security Objectives for the Operational Environment
Issuing State or Organization
The Issuing State or Organization will implement the following security objectives of the TOE
environment.
OE.MRTD_Manufact Protection of the MRTD Manufacturing
Appropriate functionality testing of the TOE shall be used in step 4 to 6.
During all manufacturing and test operations, security procedures shall be used through
phases 4, 5 and 6 to maintain confidentiality and integrity of the TOE and its
manufacturing and test data.
OE.MRTD_ Delivery Protection of the MRTD delivery
Procedures shall ensure protection of TOE material/information under delivery including
the following objectives:
• non-disclosure of any security relevant information,
• identification of the element under delivery,
• meet confidentiality rules (confidentiality level, transmittal form, reception
acknowledgment),
• physical protection to prevent external damage,
• secure storage and handling procedures (including rejected TOE’s),
• traceability of TOE during delivery including the following parameters:
• origin and shipment details,
• reception, reception acknowledgement,
• location material/information.
Procedures shall ensure that corrective actions are taken in case of improper operation in
the delivery process (including if applicable any non-conformance to the confidentiality
convention) and highlight all non-conformance to this process.
Procedures shall ensure that people (shipping department, carrier, reception department)
dealing with the procedure for delivery have got the required skill, training and knowledge
to meet the procedure requirements and be able to act fully in accordance with the above
expectations.
OE.Personalization Personalization of logical MRTD
The issuing State or Organization must ensure that the Personalization Agents acting on
the behalf of the issuing State or Organisation
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 36 of 111
i. establish the correct identity of the holder and create biographic data for the
MRTD,
ii. enrol the biometric reference data of the MRTD holder i.e. the portrait, the
encoded finger image(s) and/or the encoded iris image(s) and
iii. personalize the MRTD for the holder together with the defined physical and logical
security measures to protect the confidentiality and integrity of these data.
OE.Pass_Auth_Sign Authentication of logical MRTD by Signature
The Issuing State or Organization must
i. generate a cryptographic secure Country Signing Key Pair,
ii. ensure the secrecy of the Country Signing Private Key and sign Document Signer
Certificates in a secure operational environment, and
iii. distribute the Certificate of the Country Signing Public Key to receiving States and
organizations maintaining its authenticity and integrity.
The Issuing State or Organization must
i. generate a cryptographic secure Document Signing Key Pair and ensure the
secrecy of the Document Signer Private Keys,
ii. sign Document Security Objects of genuine MRTD in a secure operational
environment only and
iii. distribute the Certificate of the Document Signing Public Key to receiving States
and organizations.
The digital signature in the Document Security Object relates to all data in the data in
EF.DG1 to EF.DG16 if stored in the LDS according to [ICAO-9303].
OE.BAC-Keys Cryptographic quality of Basic Access Control Keys
The Document Basic Access Control Keys being generated and imported by the issuing
State or Organization have to provide sufficient cryptographic strength. As a
consequence of the ‘ICAO Doc 9303’ [ICAO-9303] the Document Basic Access Control
Keys are derived from a defined subset of the individual printed MRZ data. It has to be
ensured that these data provide sufficient entropy to withstand any attack based on the
decision that the inspection system has to derive Document Basic Access Keys from the
printed MRZ data with enhanced basic attack potential.
OE.Auth_Key_MRTD MRTD Authentication Key4
4
Added by the ST author
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 37 of 111
The issuing State or Organization has to establish the necessary public key infra-
structure in order to
i. generate the MRTD’s Active Authentication Key Pair,
ii. store the Active Authentication Private Key, and store the Active Authentication
Public Key in the Active Authentication Public Key data in EF.DG15 (if generated),
and
iii. support inspection systems of receiving States or organizations to verify the
authenticity of the MRTD’s chip used for genuine MRTD by certification of the
Chip and Active Authentication Public Key by means of the Document Security
Object.
Receiving State or organization
The Receiving State or Organization will implement the following security objectives of the TOE
environment.
OE.Exam_MRTD Examination of the MRTD passport book
The inspection system of the Receiving State must examine the MRTD presented by the
traveler to verify its authenticity by means of the physical security measures and to detect
any manipulation of the physical MRTD. The Basic Inspection System for global
interoperability
i. includes the Country Signing Public Key and the Document Signer Public Key of
each issuing State or Organization, and
ii. implements the terminal part of the Basic Access Control [ICAO-9303].
OE.AA_MRTD Active Authentication - Inspection Systems
An Active Authentication (Basic, General or Extended) Inspection system performs all the
functions of the Basic, General, respectively Extended Inspection System, and verifies
the IC authenticity with an RSA or ECDSA signature generated by the MRTD (if
available).
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 38 of 111
OE.Passive_Auth_Verif Verification by Passive Authentication
The border control officer of the Receiving State uses the inspection system to verify the
traveler as MRTD holder. The inspection systems must have successfully verified the
signature of Document Security Objects and the integrity data elements of the logical
MRTD before they are used. The receiving States and organizations must manage the
Country Signing Public Key and the Document Signing Public Key maintaining their
authenticity and availability in all inspection systems.
OE.Prot_Logical_MRTD Protection of data of the logical MRTD
The inspection system of the receiving State or Organization ensures the confidentiality
and integrity of the data read from the logical MRTD. The receiving State examining the
logical MRTD being under Basic Access Control will use inspection systems which
implement the terminal part of the Basic Access Control and use the secure messaging
with fresh generated keys for the protection of the transmitted data (i.e. Basic Inspection
Systems).
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 39 of 111
4.3 Security Objectives Rationale
The following table provides an overview for security objectives coverage.
OT.AC_Pers
5
OT.Data_Int
OT.
Data_Conf
OT.Identification
OT.Prot_Abuse-Func
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfuntion
OT.Chip_Auth_Proof
6
OE.MRTD_Manufact
OE.MRTD_Delivery
OE.Personalization
OE.Pass_Auth_Sign
OE.BAC-Keys
OE.Auth_Key_MRTD
7
OE.Exam_MRTD
8
OE.Pass_Auth_Verif
OE.Prot_Logical_MRTD
OE.AA_MRTD
T.Chip-ID x x
T.Skimming x x
T.Eavesdropping x
T.Forgery x x x x x
T.Abuse-Func x x
T.Information_Leakage x
T.Phys-tamper x
T.Malfunction x
T.Counterfeit9
x x x x
P.Manufact x
P.Personalization x x x
P.Personal_Data x x
A.MRTD_Manufact x
A.MRTD_Delivery x
A.Pers_Agent x
A.Pers_Agent_AA10
x
A.Insp_Sys x x x
5
Added in this ST with respect to [BAC-PP-055]
6
Added in this ST with respect to [BAC-PP-055]
7
Added in this ST with respect to [BAC-PP-055]
8
Added in this ST with respect to [BAC-PP-055]
9
Added in this ST with respect to [BAC-PP-055]
10
Added in this ST with respect to [BAC-PP-055]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 40 of 111
OT.AC_Pers
5
OT.Data_Int
OT.
Data_Conf
OT.Identification
OT.Prot_Abuse-Func
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfuntion
OT.Chip_Auth_Proof
6
OE.MRTD_Manufact
OE.MRTD_Delivery
OE.Personalization
OE.Pass_Auth_Sign
OE.BAC-Keys
OE.Auth_Key_MRTD
7
OE.Exam_MRTD
8
OE.Pass_Auth_Verif
OE.Prot_Logical_MRTD
OE.AA_MRTD
A.BAC-Keys x
Table 1: Security Objective Rationale
The OSP P.Manufact “Manufacturing of the MRTD’s chip” requires a unique identification
of the IC by means of the Initialization Data and the writing of the Pre-personalization Data
as being fulfilled by OT.Identification.
The OSP P.Personalization “Personalization of the MRTD by issuing State or
Organization only” addresses the (i) the enrolment of the logical MRTD by the
Personalization Agent as described in the security objective for the TOE environment
OE.Personalization “Personalization of logical MRTD”, and (ii) the access control for the
user data and TSF data as described by the security objective OT.AC_Pers “Access
Control for Personalization of logical MRTD”. Note the manufacturer equips the TOE with
the Personalization Agent 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 management of TSF to the Personalization Agent.
The OSP P.Personal_Data “Personal data protection policy” requires the TOE
(i) to support the protection of the confidentiality of the logical MRTD by means of the
Basic Access Control and
(ii) enforce the access control for reading as decided by the issuing State or
Organization.
This policy is implemented by the security objectives OT.Data_Int “Integrity of personal
data” describing the unconditional protection of the integrity of the stored data and during
transmission. The security objective OT.Data_Conf “Confidentiality of personal data”
describes the protection of the confidentiality.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 41 of 111
The threat T.Chip_ID “Identification of MRTD’s chip” addresses the trace of the MRTD
movement by identifying remotely the MRTD’s chip through the contactless communication
interface. This threat is countered as described by the security objective OT.Identification
by Basic Access Control using sufficiently strong derived keys as required by the security
objective for the environment OE.BAC-Keys.
The threat T.Skimming “Skimming digital MRZ data or the digital portrait” and
T.Eavesdropping “Eavesdropping to the communication between TOE and inspection
system” address the reading of the logical MRTD trough the contactless interface or
listening the communication between the MRTD’s chip and a terminal. This threat is
countered by the security objective OT.Data_Conf “Confidentiality of personal data”
through Basic Access Control using sufficiently strong derived keys as required by the
security objective for the environment OE.BAC-Keys.
The threat T.Forgery “Forgery of data on MRTD’s chip” addresses the fraudulent alteration
of the complete stored logical MRTD or any part of it. The security objective OT.AC_Pers
“Access Control for Personalization of logical MRTD“ requires the TOE to limit the write
access for the logical MRTD to the trustworthy Personalization Agent (cf.
OE.Personalization). The TOE will protect the integrity of the stored logical MRTD
according the security objective OT.Data_Int “Integrity of personal data” and
OT.Prot_Phys-Tamper “Protection against Physical Tampering”. The examination of the
presented MRTD passport book according to OE.Exam_MRTD “Examination of the MRTD
passport book” shall ensure that passport book does not contain a sensitive
contactless/contact chip which may present the complete unchanged logical MRTD. The
TOE environment will detect partly forged logical MRTD data by means of digital signature
which will be created according to OE.Pass_Auth_Sign “Authentication of logical MRTD
by Signature” and verified by the inspection system according to OE.Passive_Auth_Verif
“Verification by Passive Authentication”.
The threat T.Abuse-Func “Abuse of Functionality” addresses attacks using the MRTD’s
chip as production material for the MRTD and misuse of the functions for personalization in
the operational state after delivery to MRTD holder to disclose or to manipulate the logical
MRTD. This threat is countered by OT.Prot_Abuse-Func “Protection against Abuse of
Functionality”. Additionally this objective is supported by the security objective for the TOE
environment: OE.Personalization “Personalization of logical MRTD” ensuring that the
TOE security functions for the initialization and the personalization are disabled and the
security functions for the operational state after delivery to MRTD holder are enabled
according to the intended use of the TOE.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 42 of 111
The threats T.Information_Leakage “Information Leakage from MRTD’s chip”,
T.Phys-Tamper “Physical Tampering” and T.Malfunction “Malfunction due to
Environmental Stress” are typical for integrated circuits like smart cards under direct attack
with high attack potential. The protection of the TOE against these threats is addressed by
the directly related security objectives OT.Prot_Inf_Leak “Protection against Information
Leakage”, OT.Prot_Phys-Tamper “Protection against Physical Tampering” and
OT.Prot_Malfunction “Protection against Malfunctions”.
The threat T.Counterfeit “MRTD’s chip” addresses the attack of unauthorized copy or
reproduction of the genuine MRTD chip. This attack is thwarted by chip an identification
and authenticity proof required by OT.Chip_Auth_Proof “Proof of MRTD’s chip
authentication” using an authentication key pair to be generated by the issuing state or
organization. The Active Authentication Public Key has to be written into EF.DG15 as
demanded by OE.Auth_Key_MRTD “MRTD Authentication Key”. According to
OE.AA_MRTD “Examination of the MRTD passport book” the Inspection system has to
perform the Active Authentication Protocol to verify the authenticity of the MRTD’s chip.
The assumption A.MRTD_Manufact “MRTD manufacturing on step 4 to 6” is covered by
the security objective for the TOE environment OE.MRTD_Manufact “Protection of the
MRTD Manufacturing” that requires to use security procedures during all manufacturing
steps.
The assumption A.MRTD_ Delivery “MRTD delivery during step 4 to 6” is covered by the
security objective for the TOE environment OE.MRTD_ Delivery “Protection of the MRTD
delivery” that requires to use security procedures during delivery steps of the MRTD.
The assumptions A.Pers_Agent “Personalization of the MRTD’s chip” and
A.Pers_Agent_AA “Personalization of the MRTD’s chip (Active Authentication)” are
covered by the security objective for the TOE environment OE.Personalization
“Personalization of logical MRTD” including the enrolment, the protection with digital
signature and the storage of the MRTD holder personal data.
The examination of the MRTD passport book addressed by the assumption A.Insp_Sys
“Inspection Systems for global interoperability” is covered by the security objectives for the
TOE environment OE.Exam_MRTD “Examination of the MRTD passport book” which
requires the inspection system to examine physically the MRTD, the Basic Inspection
System to implement the Basic Access Control, and the General Inspection Systems and
Extended Inspection Systems to implement and to perform the Active Authentication
Protocol to verify the Authenticity of the presented MRTD’s chip. The security objectives for
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 43 of 111
the TOE environment OE.Prot_Logical_MRTD “Protection of data of the logical MRTD”
require the Inspection System to protect the logical MRTD data during the transmission
and the internal handling.
The assumption A.BAC-Keys “Cryptographic quality of Basic Access Control Keys” is
directly covered by the security objective for the TOE environment OE.BAC-Keys
“Cryptographic quality of Basic Access Control Keys” ensuring the sufficient key quality to
be provided by the issuing State or Organization.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 44 of 111
5 Extended Components Definition
This ST uses the extended components defined by the PP [BAC-PP, 5], which are components
defined as extensions to CC part 2. Some of these components are defined in [IC-PP], other
components are defined in the PP.
5.1 Definition of the Family FAU_SAS
To define the security functional requirements of the TOE an sensitive family (FAU_SAS) of the
Class FAU (Security Audit) is defined here. This family describes the functional requirements for
the storage of audit data. It has a more general approach than FAU_GEN, because it does not
necessarily require the data to be generated by the TOE itself and because it does not give
specific details of the content of the audit records.
The family “Audit data storage (FAU_SAS)” is specified as follows.
FAU_SAS Audit data storage
Family behaviour
This family defines functional requirements for the storage of audit data.
Component leveling
FAU_SAS Audit data storage 1
FAU_SAS.1 Requires the TOE to provide the possibility to store audit data.
Management: FAU_SAS.1
There are no management activities foreseen.
Audit: FAU_SAS.1
There are no actions defined to be auditable.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 45 of 111
FAU_SAS.1 Audit storage
Hierarchical to: No other components.
FAU_SAS.1.1 The TSF shall provide [assignment: authorized users] with the capability
to store [assignment: list of audit information] in the audit records.
Dependencies: No dependencies.
5.2 Definition of the Family FCS_RND
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 as the component FCS_CKM.1 is.
The similar component FIA_SOS.2 is intended for non-cryptographic use.
The family “Generation of random numbers (FCS_RND)” is specified as follows.
FCS_RND Generation of random numbers
Family behaviour
This family defines quality requirements for the generation of random numbers which
are intended to be used for cryptographic purposes.
Component leveling:
FCS_RND Generation of random numbers 1
FCS_RND.1 Generation of random numbers requires that random numbers meet a
defined quality metric.
Management: FCS_RND.1
There are no management activities foreseen.
Audit: FCS_RND.1
There are no actions defined to be auditable.
FCS_RND.1 Quality metric for random numbers
Hierarchical to: No other components.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 46 of 111
FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers that
meet [assignment: a defined quality metric].
Dependencies: No dependencies.
5.3 Definition of the Family FIA_API
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.
FIA_API Authentication Proof of Identity
Family behavior
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 Authentication Proof of Identity 1
FIA_API.1 Authentication Proof of Identity.
Management: FIA_API.1
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 .
FIA_API.1 Authentication Proof of Identity
Hierarchical to: No other components.
FIA_API.1.1 The TSF shall provide a [assignment: authentication mechanism] to
prove the identity of the [assignment: authorized user or rule].
Dependencies: No dependencies.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 47 of 111
5.4 Definition of the Family FMT_LIM
The family FMT_LIM describes the functional requirements for the Test Features of the TOE.
The new functional requirements were defined in the class FMT because this class addresses
the management of functions of the TSF. The examples of the technical mechanism used in the
TOE show that no other class is appropriate to address the specific issues of preventing the
abuse of functions by limiting the capabilities of the functions and by limiting their availability.
The family “Limited capabilities and availability (FMT_LIM)” is specified as follows.
FMT_LIM Limited capabilities and availability
Family behaviour
This family defines requirements that limit the capabilities and availability of functions in a
combined manner. Note that FDP_ACF restricts the access to functions whereas the Limited
capability of this family requires the functions themselves to be designed in a specific manner.
Component leveling:
FMT_LIM Limited capabilities and availability
1
2
FMT_LIM.1 Limited capabilities requires that the TSF is built to provide only the
capabilities (perform action, gather information) necessary for its
genuine purpose.
FMT_LIM.2 Limited availability requires that the TSF restrict the use of functions
(refer to Limited capabilities (FMT_LIM.1)). This can be achieved, for
instance, by removing or by disabling functions in a specific phase of
the TOE’s life-cycle.
Management: FMT_LIM.1, FMT_LIM.2
There are no management activities foreseen.
Audit: FMT_LIM.1, FMT_LIM.2
There are no actions defined to be auditable.
To define the IT security functional requirements of the TOE a sensitive family (FMT_LIM) of the
Class FMT (Security Management) is defined here. This family describes the functional
requirements for the Test Features of the TOE. The new functional requirements were defined in
the class FMT because this class addresses the management of functions of the TSF. The
examples of the technical mechanism used in the TOE show that no other class is appropriate to
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 48 of 111
address the specific issues of preventing the abuse of functions by limiting the capabilities of the
functions and by limiting their availability.
The TOE Functional Requirement “Limited capabilities (FMT_LIM.1)” is specified as follows.
FMT_LIM.1 Limited capabilities
Hierarchical to: No other components.
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 Limited availability.
The TOE Functional Requirement “Limited availability (FMT_LIM.2)” is specified as follows.
FMT_LIM.2 Limited availability
Hierarchical to: No other components.
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 Limited capabilities.
BAC PP Application note 16: The functional requirements FMT_LIM.1 and FMT_LIM.2
assume that there are two types of mechanisms (limited capabilities and limited availability)
which together shall provide protection in order to enforce the policy. This also allows that
(i) the TSF is provided without restrictions in the product in its user environment but its
capabilities are so limited that the policy is enforced or conversely (ii) the TSF is designed
with test and support functionality that is removed from, or disabled in, the product prior to
the Operational Use Phase. The combination of both requirements shall enforce the policy.
5.5 Definition of the Family FPT_EMSEC
The sensitive family FPT_EMSEC (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 the SCD and other secret data where the attack is based on external
observable physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s
electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA), timing
attacks, etc. This family describes the functional requirements for the limitation of intelligible
emanations which are not directly addressed by any other component of CC part 2 [CC-2].
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 49 of 111
The family “TOE Emanation (FPT_EMSEC)” is specified as follows.
Family behaviour
This family defines requirements to mitigate intelligible emanations.
Component leveling:
FPT_EMSEC TOE emanation 1
FPT_EMSEC.1 TOE emanation has two constituents:
FPT_EMSEC.1.1 Limit of Emissions requires to not emit intelligible emissions enabling access to
TSF data or user data.
FPT_EMSEC.1.2 Interface Emanation requires not emit interface emanation enabling access to
TSF data or user data.
Management: FPT_EMSEC.1
There are no management activities foreseen.
Audit: FPT_EMSEC.1
There are no actions defined to be auditable.
FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components.
FPT_EMSEC.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_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable to
use the following interface [assignment: type of connection] to gain
access to [assignment: list of types of TSF data] and [assignment:
list of types of user data].
Dependencies: No other components.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 50 of 111
6 Security Requirements
The CC allows several operations to be performed on functional requirements; refinement,
selection, assignment, and iteration are defined in paragraph 2.1.4 of [CC-2]. Each of these
operations is used in this security target.
The refinement operation is used to add detail to a requirement, and thus further restricts a
requirement. Refinement of security requirements that add or change words are in bold text. In
cases where words from a CC requirement were deleted, a separate attachment indicates the
words that were removed.
The selection operation is used to select one or more options provided by the CC in stating a
requirement. Selections that have been made by the PP authors are denoted as underlined text
and the original text of the component is given by a footnote. Selections filled in by the ST author
appear as slanted and underlined text.
The assignment operation is used to assign a specific value to an unspecified parameter, such
as the length of a password. Assignments that have been made by the PP authors are denoted
by showing as underlined text and the original text of the component is given by a footnote.
Assignments to be filled in by the ST author appear as slanted and underlined text.
The iteration operation is used when a component is repeated with varying operations. Iteration
is denoted by showing a slash “/”, and the iteration indicator after the component identifier.
The definition of the subjects “Manufacturer”, “Personalization Agent”, “Basic Inspection System”
and “Terminal” used in the following chapter is given in section 3.1. Note, that all these subjects
are acting for homonymous external entities. All used objects are defined in section 7. The
operations “write”, “read”, “modify”, and “disable read access” are used in accordance with the
general linguistic usage. The operations “transmit”, “receive” and “authenticate” are originally
taken from [2].
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 51 of 111
Definition of security attributes:
Security attribute Values Meaning
none (any Terminal) default role (i.e. without authorisation after start-
up)
Basic Inspection
System
Terminal is authenticated as Basic Inspection
System after successful Authentication in
accordance with the definition in rule 2 of
FIA_UAU.5.2.
terminal authentication
status
Personalisation
Agent
Terminal is authenticated as Personalisation Agent
after successful Authentication in accordance with
the definition in rule 1 of FIA_UAU.5.2.
6.1 Security Functional Requirements for the TOE
This section on security functional requirements for the TOE is divided into sub-section following
the main security functionality.
6.1.1 Class FAU Security Audit
The TOE shall meet the requirement “Audit storage (FAU_SAS.1)” as specified below For
the extended components definition refer to [BAC-PP] chapter 4.
FAU_SAS.1 Audit storage
Hierarchical to: No other components.
FAU_SAS.1.1 The TSF shall provide the Manufacturer11
with the capability to
store the IC Identification Data12
in the audit records.
Dependencies: No dependencies.
BAC PP Application note 17: The Manufacturer role is the default user identity assumed
by the TOE in the Phase 2 Manufacturing. The IC manufacturer and the MRTD
manufacturer in the Manufacturer role write the Initialization Data and/or Pre-
personalization Data as TSF Data of the TOE. The audit records are write-only-once data
of the MRTD’s chip (see
FMT_MTD.1/INI_DIS).
11
[assignment: authorized users]
12
[assignment: list of audit information]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 52 of 111
6.1.2 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
cryptographic key generation algorithms to be implemented and key to be generated by the
TOE.
FCS_CKM.1 Cryptographic key generation – Key Derivation Function by the MRTD
Hierarchical to: No other components.
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm Document Basic
Access Key Derivation Algorithm13
and specified cryptographic key
sizes 112 bit14
that meet the following: [ICAO-9303], Volume 2,
Section IV, Appendix 515
.
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
BAC PP Application note 18: The TOE is equipped with the Document Basic Access Key
generated and downloaded by the Personalization Agent. The Basic Access Control
Authentication Protocol described in [ICAO-9303], normative appendix 5, A5.2, produces
agreed parameters to generate the Triple-DES key and the Retail-MAC message
authentication keys for secure messaging by the algorithm in [ICAO-9303], Normative
appendix A5.1. The algorithm uses the random number RND.ICC generated by the TOE.
13
[assignment: cryptographic key generation algorithm]
14
[assignment: cryptographic key sizes]
15
[assignment: list of standards]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 53 of 111
TSF as required by FCS_RND.1.
FCS_CKM.4 Cryptographic key destruction - MRTD
Hierarchical to: No other components.
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a
specified cryptographic key destruction method physically overwriting
the keys16
that meets the following: none17
.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1
Cryptographic key generation]
BAC PP Application note 19: The TOE shall destroy the Triple-DES encryption key and
the Retail MAC message authentication keys for secure messaging.
6.1.2.1 Cryptographic operation (FCS_COP.1)
The TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified
below (Common Criteria Part 2). The iterations are caused by different cryptographic
algorithms to be implemented by the TOE.
FCS_COP.1/SHA Cryptographic operation – Hash for Key Derivation
Hierarchical to: No other components.
FCS_COP.1.1/
SHA
The TSF shall perform hashing18
in accordance with a specified
cryptographic algorithm SHA-1, SHA-224 or SHA-25619
and
cryptographic key sizes none20
that meet the following: FIPS
180-4 [NIST-180-4]21
.
16
[assignment: cryptographic key destruction method]
17
[assignment: list of standards]
18
[assignment: list of cryptographic operations]
19
[assignment: cryptographic algorithm]
20
[assignment: cryptographic key sizes]
21
[assignment: list of standards]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 54 of 111
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
BAC PP Application note 20: This SFR requires the TOE to implement the hash function
SHA-1 for the cryptographic primitive of the Basic Access Control Authentication
Mechanism (see also FIA_UAU.4) according to [ICAO-9303].
FCS_COP.1/ENC Cryptographic operation – Encryption / Decryption Triple DES
Hierarchical to: No other components.
FCS_COP.1.1/
ENC
The TSF shall perform secure messaging (BAC)– encryption and
decryption22
in accordance with a specified cryptographic algorithm
Triple-DES in CBC mode23
and cryptographic key sizes 112 bit24
that
meet the following: FIPS 46-3 [FIPS46] and [ICAO-9303], Volume 2,
Appendix 5, A5.325
.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
BAC PP Application note 21: This SFR requires the TOE to implement the cryptographic
primitive for secure messaging with encryption of the transmitted data. The keys are
agreed between the TOE and the terminal as part of the Basic Access Control
Authentication Mechanism according to the FCS_CKM.1 and FIA_UAU.4.
22
[assignment: list of cryptographic operations]
23
[assignment: cryptographic algorithm]
24
[assignment: cryptographic key sizes]
25
[assignment: list of standards]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 55 of 111
FCS_COP.1/AUTH Cryptographic operation – Authentication
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1
Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/ The TSF shall perform symmetric authentication – encryption
AUTH and decryption in accordance with a specified cryptographic
algorithm Triple-DES and AES 26
and cryptographic key sizes
respectively 112 bit for Tripple-DES and 128,192 and 256 bit for
AES 27
that meet the following: FIPS 46-3 [FIPS] for Triple-DES and
[NIST-197] 28
.
.
BAC PP Application note 22: This SFR requires the TOE to implement the cryptographic
primitive for authentication attempt of a terminal as Personalization Agent by means of the
symmetric authentication mechanism (cf. FIA_UAU.4).
FCS_COP.1/MAC Cryptographic operation – Retail MAC
Hierarchical to: No other components.
FCS_COP.1.1/
MAC
The TSF shall perform secure messaging – message authentication
code29
in accordance with a specified cryptographic algorithm Retail
MAC30
and cryptographic key sizes respectively 112 bit31
that meet the
following: ISO 9797 (MAC algorithm 3, block cipher DES, Sequence
Message Counter, padding mode 2)32
.
26
[selection: Triple-DES, AES]
27
[selection: 112, 128, 168, 192, 256]
28
[selection: FIPS 46-3 […], FIPS 197 […]
29
[assignment: list of cryptographic operations]
30
[assignment: cryptographic algorithm]
31
[assignment: cryptographic key sizes]
32
[assignment: list of standards]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 56 of 111
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
BAC PP Application note 23: This SFR requires the TOE to implement the cryptographic
primitive for secure messaging with encryption and message authentication code over the
transmitted data. The key is agreed between the TSF by the Basic Access Control
Authentication Mechanism according to the FCS_CKM.1 and FIA_UAU.4.
FCS_COP.1/SIG_GEN Cryptographic operation – Signature generation by travel
document
Hierarchical to: No other components.
FCS_COP.1.1/
SIG_GEN
The TSF shall perform digital signature generation33
in accordance
with a specified cryptographic algorithm ECDSA and RSA34
with
cryptographic key sizes 192, 224, 256 and 320 bits for ECDSA and
1536, 1792 and 2048 bits for RSA35
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,
and SHA256 digest algorithms specified in [NIST-180-4] for both
ECDSA and RSA signatures 36
.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FMT_MSA.2 Secure security attributes
Guidance: 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].
33
[assignment: list of cryptographic operations]
34
[assignment: cryptographic algorithm]
35
[assignment: cryptographic key sizes]
36
[assignment: list of standards]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 57 of 111
6.1.2.2 Random Number Generation (FCS_RND.1)
The TOE shall meet the requirement “Quality metric for random numbers (FCS_RND.1)” as
specified below (Common Criteria Part 2 extended).
FCS_RND.1 Quality metric for random numbers
Hierarchical to: No other components.
FCS_RND.1.1 The TSF shall provide a mechanism to generate random numbers
that meet Class DRG.3 of [KS2011]37
Dependencies: No dependencies.
BAC PP Application note 24: This SFR requires the TOE to generate random numbers
used for the authentication protocols as required by FIA_UAU.4.
ST Application note 2: The class DRG.3 defines requirements for deterministic RNGs. It
shall not be possible to distinguish the generated random numbers from output sequences
from an ideal RNG by statistical tests, and the generated random numbers sequence shall
have at least some minimum amount of Min-entropy (contained in the seed), and enhanced
backward secrecy is ensured. The class DRG.3 includes the requirements of class DRG.2.
While (DRG.2.2) and (DRG.2.3) require forward and backward secrecy (i.e., unknown
output value cannot be determined from known output values), the security capabilities
(DRG.3.2) and (DRG.3.3) additionally require enhanced backward secrecy. This means
that previous output values cannot even be determined with knowledge of the current
internal state and current and future output values. Enhanced backward secrecy might be
relevant, for instance, for software implementations of a DRNG when the internal state has
been compromised while all random numbers generated in the past shall remain secret
(e.g., cryptographic keys).
The requirements to a deterministic random generator of class DRG.3 are (see [KS2011],
ch. 4.8):
37
[assignment: a defined quality metric]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 58 of 111
(DRG.3.1)If initialized with a random seed [selection: using a PTRNG of class PTG.2 as
random source, using a PTRNG of class PTG.3 as random source, using an NPTRNG of
class NTG.1 [assignment: other requirements for seeding]], the internal state of the RNG
shall [selection: have [assignment: amount of entropy], have [assignment: work factor],
require [assignment: guess work].
(DRG.3.2) The RNG provides forward secrecy.
(DRG.3.3) The RNG provides backward secrecy even if the current internal state is known.
(DRG.3.4) The RNG, initialized with a random seed [assignment: requirements for
seeding], generates output for which [assignment: number of strings] strings of bit length
128 are mutually different with probability [assignment: probability].
(DRG.3.5) Statistical test suites cannot practically distinguish the random numbers from
output sequences of an ideal RNG. The random numbers must pass test procedure A
[assignment: additional test suites].
The platform provides a deterministic random number generator which provides random
numbers which meet class DRG.3 of [KS2011]. It is initialised with a random seed using
the certified TRNG of the underlying Hardware platform to Seed. The internal state of the
RNG has at least 100 bit MIN entropy. The RNG provides forward secrecy. Enhanced
backward secrecy is ensured. The random numbers have passed test procedure A.
The predefined class DRG.3 of [KS2011] complies with class K4 of the former definitions of
[AIS20V1] (see [KS2011, 4.1 / 4.8]).
6.1.3 Class FIA Identification and Authentication
BAC PP Application note 25: The following table provides an overview on the
authentication mechanisms used.
Name SFR for the TOE Algorithms and key sizes according to
[ICAO-9303], Appendix 5
Basic Access Control
Authentication
Mechanism
Triple-DES, 112 bit keys (cf.
FCS_COP.1/ENC) and
Retail-MAC, 112 bit keys (cf.
FCS_COP.1/MAC)
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 59 of 111
Name SFR for the TOE Algorithms and key sizes according to
[ICAO-9303], Appendix 5
Active Authentication FIA_API.1/AA RSA and ECDSA, (cf.
FCS_COP.1/SIG_GEN)
RSA: 1536, 1792 and 2048 bits
ECDSA: 192, 224, 256 and 320 bits
Symmetric
Authentication
Mechanism for
Personalization Agents
FIA_UAU.4 Triple-DES with 112 bit keys
or AES with 128, 192 and 256 bit
keys
(cf. FCS_COP.1/AUTH)
Table 2: Overview on authentication SFR
6.1.3.1 Timing of identification (FIA_UID.1)
The TOE shall meet the requirement “Timing of identification (FIA_UID.1)” as specified
below (Common Criteria Part 2).
FIA_UID.1 Timing of identification
Hierarchical to: No other components.
FIA_UID.1.1 The TSF shall allow
1. to read the Initialization Data in Phase 2 “Manufacturing”,
2. to read the random identifier in Phase 3 “Personalization of
the MRTD”,
3. to read the random identifier in Phase 4 “Operational Use” 38
on behalf of the user to be performed before the user is
identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified
before allowing any other TSF-mediated actions on behalf of
that user.
Dependencies: No dependencies.
38
[assignment: list of TSF-mediated actions]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 60 of 111
BAC PP Application note 26: The IC manufacturer and the MRTD manufacturer write the
Initialization Data and/or Pre-personalization Data in the audit records of the IC during the
Phase 2 “Manufacturing”. The audit records can be written only in the Phase 2
Manufacturing of the TOE. At this time the Manufacturer is the only user role available for
the TOE. The MRTD manufacturer may create the user role Personalization Agent for
transition from Phase 2 to Phase 3 “Personalization of the MRTD”. The users in role
Personalization Agent identify themselves by means of selecting the authentication key.
After personalization in the Phase 3 (i.e. writing the digital MRZ and the Document Basic
Access Keys) the user role Basic Inspection System is created by writing the Document
Basic Access Keys. The Basic Inspection System is identified as default user after power
up or reset of the TOE i.e. the TOE will use the Document Basic Access Key to
authenticate the user as Basic Inspection System.
BAC PP Application note 27: In the “Operational Use” phase the MRTD must not allow
anybody to read the ICCSN, the MRTD identifier or any other unique identification before
the user is authenticated as Basic Inspection System (cf. T.Chip_ID). Note that the terminal
and the MRTD’s chip use a (randomly chosen) identifier for the communication channel to
allow the terminal to communicate with more then one RFID. In the TOE of this ST this
identifier is randomly selected and will not violate the OT.Identification.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 61 of 111
6.1.3.2 Timing of authentication (FIA_UAU.1)
The TOE shall meet the requirement “Timing of authentication (FIA_UAU.1)” as specified
below (Common Criteria Part 2).
FIA_UAU.1 Timing of authentication
Hierarchical to: No other components.
FIA_UAU.1.1 The TSF shall allow
1. to read the Initialization Data in Phase 2 “Manufacturing”,
2. to read the random identifier in Phase 3 “Personalization of
the MRTD”,
3. to read the random identifier in Phase 4 “Operational Use” 39
on behalf of the user to be performed before the user is
authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of that
user.
Dependencies: FIA_UID.1 Timing of identification.
BAC PP Application note 28: The Basic Inspection System and the Personalization
Agent authenticate themselves.
39
[assignment: list of TSF-mediated actions]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 62 of 111
6.1.3.3 Single-use authentication mechanisms (FIA_UAU.4)
The TOE shall meet the requirements of “Single-use authentication mechanisms
(FIA_UAU.4)” as specified below (Common Criteria Part 2).
FIA_UAU.4 Single-use authentication mechanisms - Single-use authentication of the
Terminal by the TOE
Hierarchical to: No other components.
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to
1. Basic Access Control Authentication Mechanism,
2. Authentication Mechanism based on Triple-DES40
.
Dependencies: No dependencies.
BAC PP Application note 29: The authentication mechanisms may use either a challenge
freshly and randomly generated by the TOE to prevent reuse of a response generated by a
terminal in a successful authentication attempt. However, the authentication of
Personalisation Agent may rely on other mechanisms ensuring protection against replay
attacks, such as the use of an internal counter as a diversifier.
BAC PP Application note 30: The Basic Access Control Mechanism is a mutual device
authentication mechanism defined in [ICAO-9303]. In the first step the terminal
authenticates itself to the MRTD’s chip and the MRTD’s chip authenticates to the terminal
in the second step. In this second step the MRTD’s chip provides the terminal with a
challenge-response-pair which allows a unique identification of the MRTD’s chip with some
probability depending on the entropy of the Document Basic Access Keys. Therefore the
TOE shall stop further communications if the terminal is not successfully authenticated in
the first step of the protocol to fulfill the security objective OT.Identification and to prevent
T.Chip_ID.
40
[assignment: identified authentication mechanism(s)]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 63 of 111
Multiple authentication mechanisms (FIA_UAU.5)
The TOE shall meet the requirement “Multiple authentication mechanisms (FIA_UAU.5)” as
specified below (Common Criteria Part 2).
FIA_UAU.5 Multiple authentication mechanisms
FIA_UAU.5.1 The TSF shall provide
1. Basic Access Control Authentication Mechanism
2. Symmetric Authentication Mechanism based on Triple-DES
and AES 41
to support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity
according to the following rules:
1. The TOE accepts the authentication attempt as
Personalization Agent by one of the following mechanisms
(a) The Basic Access Control Authentication Mechanism
with the Personalization Agent Keys,
(b) The Symmetric Authentication Mechanism with the
Personalization Agent Key,
2. The TOE accepts the authentication attempt as Basic
Inspection System only by means of the Basic Access
Control Authentication Mechanism with the Document Basic
Access Keys.
Dependencies: No dependencies.
BAC PP Application note 31: In case the ‘Common Criteria Protection Profile Machine
Readable Travel Document with „ICAO Application", Extended Access Control’ [EAC-PP]
should also be fulfilled the Personalization Agent should not be authenticated by using the
BAC or the symmetric authentication mechanism as they base on the two-key Triple-DES.
The Personalization Agent could be authenticated by using the symmetric AES-based
authentication mechanism or other (e.g. the Terminal Authentication Protocol using the
Personalization Key, cf. [EAC-PP] FIA_UAU.5.2).
BAC PP Application note 32: The Basic Access Control Mechanism includes the secure
messaging for all commands exchanged after successful authentication of the inspection
system. The Personalization Agent may use Symmetric Authentication Mechanism without
secure messaging mechanism as well if the personalization environment prevents
eavesdropping to the communication between TOE and personalization terminal. The
Basic Inspection System may use the Basic Access Control Authentication Mechanism
with the Document Basic Access Keys.
41
[assignment: list of multiple authentication mechanisms]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 64 of 111
6.1.3.4 Re-authenticating (FIA_UAU.6)
The TOE shall meet the requirement “Re-authenticating (FIA_UAU.6)” as specified below
(Common Criteria Part 2).
FIA_UAU.6 Re-authenticating – Re-authenticating of Terminal by the TOE
Hierarchical to: No other components.
FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions
each command sent to the TOE during a BAC mechanism
based communication after successful authentication of the
terminal with Basic Access Control Authentication
Mechanism42
.
Dependencies: No dependencies.
BAC PP Application note 33: The Basic Access Control Mechanism specified in [ICAO-
9303] includes the secure messaging for all commands exchanged after successful
authentication of the Inspection System. The TOE checks by secure messaging in
MAC_ENC mode each command based on Retail-MAC whether it was sent by the
successfully authenticated terminal (see FCS_COP.1/MAC for further details). The TOE
does not execute any command with incorrect message authentication code. Therefore the
TOE re-authenticates the user for each received command and accepts only those
commands received from the previously authenticated BAC user.
BAC PP Application note 34: Note that in case the TOE should also fulfill [EAC-PP] the
BAC communication might be followed by a Chip Authentication mechanism establishing a
new secure messaging that is distinct from the BAC based communication. In this case the
condition in FIA_UAU.6 above should not contradict to the option that commands are sent
to the TOE that are no longer meeting the BAC communication but are protected by a more
secure communication channel established after a more advanced authentication process.
42
[assignment: list of conditions under which re-authentication is required]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 65 of 111
6.1.3.5 Authentication Failure Handling (FIA_AFL.1)
The TOE shall meet the requirement “Authentication Failure Handling (FIA_AFL.1)” as
specified below.
FIA_AFL.1 Authentication Failure Handling
Hierarchical to: No other components.
FIA_AFL.1.1 The TSF shall detect when an administrator configurable
positive integer within one to 3276743
consecutive
unsuccessful authentication attempts occur related to BAC
authentication44
.
FIA_AFL.1.2 When the defined number of unsuccessful authentication
attempts has been met or surpassed, the TSF shall wait an
administrator configurable time before the next
authentication attempt can be performed45
.
Dependencies: FIA_UAU.1 Timing of authentication
Application note 35:
In this ST the assigned values for FIA_AFL.1.1 and FIA_AFL.1.2 ensure especially the
strength of authentication function as terminal part of the Basic Access Control
Authentication Protocol to resist enhanced basic attack potential.
In FIA_AFL.1.1 the TSF shall detect when an administrator configurable positive integer
within range of acceptable values 1 to 32767 consecutive unsuccessful authentication
attempts occur related to BAC authentication protocol.
FIA_AFL.1.2 specifies when the defined number of unsuccessful authentication attempts
has been met or surpassed, that the TSF shall wait for an administrator configurable time
between the receiving the terminal challenge eIFD and sending the TSF response eICC
during the BAC authentication attempts.
The terminal challenge eIFD and the TSF response eICC are described in [EAC-PP],
Appendix C. The refinement by inclusion of the word “consecutive” allows the TSF to return
to normal operation of the BAC authentication protocol (without time out) after successful
43
[selection: [assignment: positive integer number], an administrator configurable positive integer within [assignment:
range of acceptable values]
44
[assignment: list of authentication events]
45
[assignment: list of actions]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 66 of 111
run of the BAC authentication protocol. The unsuccessful authentication attempt shall be
stored non-volatile in the TOE thus the “consecutive unsuccessful authentication attempts”
are count independent on power-on sessions but reset to zero after successful
authentication only.
FIA_API.1/AA Authentication Proof of Identity - MRTD
The TOE shall meet the requirement “Authentication Proof of Identity (FIA_API.1)” as
specified below (Common Criteria Part 2 extended).
Hierarchical to: No other components.
FIA_API.1/AA The TSF shall provide an Active Authentication Protocol
according to [ICAO-9303]46
to prove the identity of the TOE47
.
Dependencies: No dependencies.
6.1.4 Class FDP User Data Protection
6.1.4.1 Subset access control (FDP_ACC.1)
The TOE shall meet the requirement “Subset access control (FDP_ACC.1)” as specified
below (Common Criteria Part 2).
FDP_ACC.1 Subset access control - Basic Access Control
Hierarchical to: No other components.
FDP_ACC.1.1 The TSF shall enforce the Basic Access Control SFP48
on
terminals gaining write, read and modification access to the
data in the EF.COM, EF.SOD, EF.DG1 to EF.DG16 of the
logical MRTD49
.
Dependencies: FDP_ACF.1 Security attribute based access control
46
[assignment: authentication mechanism]
47
[assignment: authorized user or rule]
48
[assignment: access control SFP]
49
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 67 of 111
6.1.4.2 Security attribute based access control (FDP_ACF.1)
The TOE shall meet the requirement “Security attribute based access control
(FDP_ACF.1)” as specified below (Common Criteria Part 2).
FDP_ACF.1 Security attribute based access control- Basic Access Control50
Hierarchical to: No other components.
FDP_ACF.1.1 The TSF shall enforce the Access Control SFP51
to objects
based on the following:
1. Subjects:
a. Personalization Agent
b. Basic Inspection System
c. Terminal
2. Objects:
a. data EF.DG1 to EF.DG16 of the logical MRTD
b. data in EF.COM
c. data in EF.SOD
3. Security attributes
a. authentication status of terminals 52
.
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed:
1. the successfully authenticated Personalization Agent is
allowed to write and to read the data of the EF.COM,
EF.SOD, EF.DG1 to EF.DG16 of the logical MRTD,
2. the successfully authenticated Basic Inspection System is
allowed to read data in EF.COM, EF.SOD, EF.DG1,
EF.DG2 and EF.DG5 to EF.DG16 of the logical MRTD
and perform Active Authentication,
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to
objects based on the following additional rules: none53
.
50
The bold text below has been added to allow the use of active authentication.
51
[assignment: access control SFP]
52
[assignment: list of subjects and objects controlled under the indicated SFP, and. for each, the SFP-relevant security
attributes, or named groups of SFP-relevant security attributes]
53
[assignment: rules, based on security attributes, that explicitly authorize access of subjects to objects]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 68 of 111
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects
based on the rule:
1. Any terminal is not allowed to modify any of the EF.DG1
to EF.DG16 of the logical MRTD,
2. An Any terminal is not allowed to read any of the EF.DG1
to EF.DG16 of the logical MRTD.
3. The Basic Inspection System is not allowed to read the
data in EF.DG3 and EF.DG4
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
BAC PP Application note 36: The inspection system needs special authentication and
authorization for read access to DG3 and DG4 not defined in this protection profile (cf.
[EAC-PP] for details).
6.1.4.3 Inter-TSF-Transfer
BAC PP Application note 37: FDP_UCT.1 and FDP_UIT.1 require the protection of the
User Data transmitted from the TOE to the terminal by secure messaging with encryption
and message authentication codes after successful authentication of the terminal. The
authentication mechanisms as part of Basic Access Control Mechanism include the key
agreement for the encryption and the message authentication key to be used for secure
messaging.
The TOE shall meet the requirement “Basic data exchange confidentiality (FDP_UCT.1)”
as specified below (Common Criteria Part 2).
FDP_UCT.1 Basic data exchange confidentiality - MRTD
Hierarchical to: No other components.
FDP_UCT.1.1 The TSF shall enforce the Access Control SFP54
to be able to
transmit and receive55
user data in a manner protected from
unauthorized disclosure.
54
[assignment: access control SFP(s) and/or information flow control SFP(s)]
55
[selection: transmit, receive]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 69 of 111
Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
The TOE shall meet the requirement “Data exchange integrity (FDP_UIT.1)” as specified
below (Common Criteria Part 2).
FDP_UIT.1/ Data exchange integrity - MRTD
Hierarchical to: No other components.
FDP_UIT.1.1 The TSF shall enforce the Access Control SFP56
to be able to
transmit and receive57
user data in a manner protected from
modification, deletion, insertion and replay58
errors.
FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data,
whether modification, deletion, insertion and replay59
has occur-
red.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
6.1.5 Class FMT Security Management
BAC PP Application note 38: The SFR FMT_SMF.1 and FMT_SMR.1 provide basic
requirements to the management of the TSF data.
The TOE shall meet the requirement “Specification of Management Functions
(FMT_SMF.1)” as specified below (Common Criteria Part 2).
FMT_SMF.1 Specification of Management Functions
56
[assignment: access control SFP(s) and/or information flow control SFP(s)]
57
[selection: transmit, receive]
58
[selection: modification, deletion, insertion, replay]
59
[selection: modification, deletion, insertion, replay]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 70 of 111
Hierarchical to: No other components.
FMT_SMF.1.1 The TSF shall be capable of performing the following
management functions:
1. Initialization,
2. Pre-personalization
3. Personalization60
.
Dependencies: No Dependencies
The TOE shall meet the requirement “Security roles (FMT_SMR.1)” as specified below
(Common Criteria Part 2).
FMT_SMR.1 Security roles
Hierarchical to: No other components.
FMT_SMR.1.1 The TSF shall maintain the roles
1. Manufacturer,
2. Personalization Agent,
3. Basic Inspection System61
.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Dependencies: FIA_UID.1 Timing of identification.
BAC PP Application note 39: The SFR FMT_LIM.1 and FMT_LIM.2 address the
management of the TSF and TSF data to prevent misuse of test features of the TOE over
the life cycle phases.
The TOE shall meet the requirement “Limited capabilities (FMT_LIM.1)” as specified below.
For the extended components definition is referred to [BAC-PP] chapter 4.
60
[assignment: list of security management functions to be provided by the TSF]
61
[assignment: the authorized identified roles]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 71 of 111
FMT_LIM.1 Limited capabilities
Hierarchical to: No other components.
FMT_LIM.1.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,
2. TSF data to be disclosed or manipulated,
3. software to be reconstructed and
4. substantial information about construction of TSF to be
gathered which may enable other attacks62
.
Dependencies: FMT_LIM.2 Limited availability.
The TOE shall meet the requirement “Limited availability (FMT_LIM.2)” as specified below.
For the extended components definition refer to [BAC-PP] chapter 4.
FMT_LIM.2 Limited availability
Hierarchical to: No other components.
FMT_LIM.2.1 The TSF shall be designed in a manner that limits their
availability 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,
2. TSF data to be disclosed or manipulated,
3. software to be reconstructed and
4. substantial information about construction of TSF to be
gathered which may enable other attacks63
.
Dependencies: FMT_LIM.2 Limited capabilities.
BAC PP Application note 40: The formulation of “Deploying Test Features …” in
FMT_LIM.2.1 might be a little bit misleading since the addressed features are no longer
available (e.g. by disabling or removing the respective functionality). Nevertheless the
combination of FMT_LIM.1 and FMT_LIM.2 is introduced provide an optional approach to
62
[assignment: Limited capability and availability policy]
63
[assignment: Limited capability and availability policy]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 72 of 111
enforce the same policy. Note that the term “software” in item 3 of FMT_LIM.1.1 and
FMT_LIM.2.1 refers to both IC Dedicated and IC Embedded Software.
BAC PP Application note 41: The following SFR are iterations of the component
Management of TSF data (FMT_MTD.1). The TSF data include but are not limited to those
identified below.
The TOE shall meet the requirement “Management of TSF data (FMT_MTD.1)” as
specified below (Common Criteria Part 2). The iterations address different management
functions and different TSF data.
FMT_MTD.1/INI_ENA Management of TSF data – Writing of Initialization Data and
Pre-personalization Data
Hierarchical to: No other components.
FMT_MTD.1/INI_ENA The TSF shall restrict the ability to write64
the Initialization
Data and Pre-personalization Data65
to the Manufacturer66
.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
BAC PP Application note 42: The pre-personalization Data includes but is not limited to
the authentication reference data for the Personalization Agent which is the symmetric
cryptographic Personalization Agent Key.
FMT_MTD.1/INI_DIS Management of TSF data – Disabling of Read Access to
Initialization Data and Pre-personalization Data
Hierarchical to: No other components.
FMT_MTD.1.1/INI_DIS The TSF shall restrict the ability to disable read access for
users to67
the Initialization Data68
to the Personalization
Agent69
.
64
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
65
[assignment: list of TSF data]
66
[assignment: the authorized identified roles]
67
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
68
[assignment: list of TSF data]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 73 of 111
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
BAC PP Application note 43: According to P.Manufact the IC Manufacturer and the
MRTD Manufacturer are the default users assumed by the TOE in the role Manufacturer
during the Phase 2 “Manufacturing” but the TOE is not requested to distinguish between
these users within the role Manufacturer. The TOE may restrict the ability to write the
Initialization Data and the Pre-personalization Data by (i) allowing to write these data only
once and (ii) blocking the role Manufacturer at the end of the Phase 2. The IC
Manufacturer may write the Initialization Data which includes but are not limited to the IC
Identifier as required by FAU_SAS.1. The Initialization Data provides a unique identification
of the IC which is used to trace the IC in the Phase 2 and 3 “personalization” but is not
needed and may be misused in the Phase 4 “Operational Use”. Therefore the external read
access shall be blocked. The MRTD Manufacturer will write the Pre-personalization Data.
FMT_MTD.1/g Management of TSF data – Key Write70
Hierarchical to: No other components.
FMT_MTD.1.1/KEY_WRITE The TSF shall restrict the ability to write71
the Document
Basic Access Keys and the Active Authentication
Keys72
to the Personalization Agent73
.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1/KEY_READ Management of TSF data – Key Read74
Hierarchical to: No other components.
69
[assignment: the authorized identified roles]
70
The bold text below has been added to allow the use of active authentication.
71
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
72
[assignment: list of TSF data]
73
[assignment: the authorized identified roles]
74
The bold text below has been added to allow the use of active authentication.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 74 of 111
FMT_MTD.1.1/KEY_READ The TSF shall restrict the ability to read75
the Document
Basic Access Keys, the Active Authentication Private
Key and the Personalization Agent Keys76
to none77
.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
BAC PP Application note 44: The Personalization Agent generates, stores and ensures
the correctness of the Document Basic Access Keys.
6.1.6 Protection of the Security Functions
The TOE shall prevent inherent and forced illicit information flow for User Data and TSF
Data. The security functional requirement FPT_EMSEC.1 addresses the inherent leakage.
With respect to forced leakage they have to be considered in combination with the security
functional requirements “Failure with preservation of secure state (FPT_FLS.1)” and “TSF
testing (FPT_TST.1)” on the one hand and “Resistance to physical attack (FPT_PHP.3)” on
the other. The SFR “Limited capabilities (FMT_LIM.1)”, “Limited availability (FMT_LIM.2)”
and “Resistance to physical attack (FPT_PHP.3)” prevent deactivation and manipulation of
the security features or misuse of TOE functions.
The TOE shall meet the requirement “TOE Emanation (FPT_EMSEC.1)” as specified
below. For the extended components definition refer to [BAC-PP] chapter 4
FPT_EMSEC.1 TOE Emanation78
Hierarchical to: No other components.
FPT_EMSEC.1.1 The TOE shall not emit variations in power consumption or
timing during command execution79
in excess of non-useful
information80
enabling access to Personalisation Agent
75
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
76
[assignment: list of TSF data]
77
[assignment: the authorized identified roles]
78
The bold text below has been added to allow the use of active authentication.
79
[assignment: types of emissions]
80
[assignment: specified limits]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 75 of 111
Authentication Key, Active Authentication Private Key, 81
and none82
FPT_EMSEC.1.2 The TSF shall ensure any users83
are unable to use the
following interface smart card circuit contacts84
to gain access
to Personalization Agent Authentication Key, Active
Authentication Private Key,85
and none86
.
Dependencies: No other components.
BAC PP Application note 45: The TOE shall prevent attacks against the listed secret data
where the attack is based on external observable physical phenomena of the TOE. Such
attacks may be observable at the interfaces of the TOE or may be originated from internal
operation of the TOE or may be caused by an attacker that varies the physical environment
under which the TOE operates. The set of measurable physical phenomena is influenced
by the technology employed to implement the smart card. The MRTD’s chip has to provide
a smart card contactless/contact interface but may have also (not used by the terminal but
maybe by an attacker) sensitive contacts according to ISO/IEC 7816-2 as well. Examples
of measurable phenomena include, but are not limited to variations in the power
consumption, the timing of signals and the electromagnetic radiation due to internal
operations or data transmissions.
The following security functional requirements address the protection against forced illicit
information leakage including physical manipulation.
The TOE shall meet the requirement “Failure with preservation of secure state
(FPT_FLS.1)” as specified below (Common Criteria Part 2).
81
[assignment: list of types of TSF data]
82
[assignment: list of types of user data]
83
[assignment: type of users]
84
[assignment: type of connection]
85
[assignment: list of types of TSF data]
86
[assignment: list of types of user data]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 76 of 111
FPT_FLS.1 Failure with preservation of secure state
Hierarchical to: No other components.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following
types of failures occur:
(1) exposure to operating conditions where therefore a
malfunction could occur,
(2) failure detected by TSF according to FPT_TST.187
.
Dependencies: ADV_SPM.1 Informal TOE security policy model
The TOE shall meet the requirement “TSF testing (FPT_TST.1)” as specified below
(Common Criteria Part 2).
FPT_TST.1 TSF testing
Hierarchical to: No other components.
FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up88
to demonstrate the correct operation of the TSF.
FPT_TST.1.2 The TSF shall provide authorized users with the capability to
verify the integrity of TSF data.
FPT_TST.1.3 The TSF shall provide authorized users with the capability to
verify the integrity of stored TSF executable code.
BAC PP Application note 46: If the MRTD’s chip uses state of the art smart card
technology it will run the some self tests at the request of the authorized user and some
self tests automatically. E.g. a self test for the verification of the integrity of stored TSF
executable code required by FPT_TST.1.3 may be executed during initial start-up by the
“authorized user” Manufacturer in the Phase 2 Manufacturing. Other self tests may run
automatically to detect failure and to preserve of secure state according to FPT_FLS.1 in
the Phase 4 “Operational Use”, e.g. to check a calculation with a private key by the reverse
calculation with the corresponding public key as countermeasure against Differential
Failure Attacks. The security target writer shall perform the operation claimed by the
concrete product under evaluation.
87
[assignment: list of types of failures in the TSF]
88
[selection: during initial start-up, periodically during normal operation, at the request of the authorized user, at the
conditions ]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 77 of 111
The TOE shall meet the requirement “Resistance to physical attack (FPT_PHP.3)” as
specified below (Common Criteria Part 2).
FPT_PHP.3 Resistance to physical attack
Hierarchical to: No other components.
FPT_PHP.3.1 The TSF shall resist physical manipulation and physical pro-
bing89
to the TSF90
by responding automatically such that the
SFRs are always enforced.
Dependencies: No dependencies.
BAC PP Application note 47: The TOE will implement appropriate measures to
continuously counter physical manipulation and physical probing. Due to the nature of
these attacks (especially manipulation) the TOE can by no means detect attacks on all of
its elements. Therefore, permanent protection against these attacks is required ensuring
that the TSP could not be violated at any time. Hence, “automatic response” means here (i)
assuming that there might be an attack at any time and (ii) countermeasures are provided
at any time.
BAC PP Application note 48: The SFRs “Non-bypassability of the TSF FPT_RVM.1” and
“TSF domain separation FPT_SEP.1” are no longer part of [2]. These requirements are
now an implicit part of the assurance requirement ADV_ARC.1.
The following security functional requirements protect the TSF against bypassing and
support the separation of TOE parts.
89
[assignment: physical tampering scenarios]
90
[assignment: list of TSF devices/elements]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 78 of 111
6.2 Security Assurance Requirements for the TOE
The security assurance requirements (SAR) for the evaluation of the TOE and its development
and operating environment are those taken from the
Evaluation Assurance Level 4 (EAL4)
and augmented by the following component:
ALC_DVS.2
The following table lists all SARs for the evaluation of the TOE:
Assurance class Assurance component Denotation
ADV_ARC.1 Security architecture
description
ADV_COMP.1 Design compliance with
the platform certification
report, guidance and
ETR_COMP
ADV_FSP.4 Complete functional
specification
ADV_IMP.1 Implementation
representation of the TSF
Development
ADV_TDS.3 Basic modular design
AGD_OPE.1 Operational user guidance
Guidance documents
AGD_PRE.1 Preparative procedures
ALC_CMC.4 Production support,
acceptance procedures
and automation
ALC_CMS.4 Problem tracking CM
coverage
Life-cycle support
ALC_COMP.1 Integration of the
application into the
underlying platform and
Consistency check for
delivery and acceptance
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 79 of 111
Assurance class Assurance component Denotation
procedures
ALC_DEL.1 Delivery procedures
ALC_DVS.2 Sufficiency of security
measures
ALC_LCD.1 Developer defined life-
cycle state
ALC_TAT.1 Tools and techniques –
Well-defined development
tools
ASE_CCL.1 Conformance claims
ASE_COMP.1 Consistency of Security
Target
ASE_ ECD.1 Extended components
definition
ASE_INT.1 ST Introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 IT security requirements
ASE_SPD.1 Security problem definition
Security Target evaluation
ASE_TSS.1 TOE summary
specification
ATE_COMP.1 Composite product
functional testing
ATE_COV.2 Analysis of coverage
ATE_DPT.1 Depth – Testing:
high-level design
ATE_FUN.1 Functional testing
Tests
ATE_IND.2 Independent testing –
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 80 of 111
Assurance class Assurance component Denotation
sample
AVA_COMP.1 Composite product
vulnerability assessment
Vulnerability assessment
AVA_VAN.3 Focused vulnerability
analysis
Table 1: Security Assurance Requirements
The selection of the component ALC_DVS.2 provides a higher assurance of the security of the
MRTD’s development and manufacturing especially for the secure handling of the MRTD’s
material.
The Assurance Requirements for the selected level EAL 4 augmented are described in the
Common Criteria for IT Security Evaluation documents. They are not listed in detail here.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 81 of 111
6.3 Security Requirements Rationale
6.3.1 Functional Security Requirements Rationale
The following table provides an overview for security functional requirements coverage.
OT.AC_Pers
OT.Data_Int
OT.
Data_Conf
OT.Identification
OT:Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfuntion
OT.Prot_Abuse-Func
OT.Chip_Auth_Proof
91
FAU_SAS.1 x
FCS_CKM.1 x x x
FCS_CKM.4 x x
FCS_COP.1/SHA x x x x
FCS_COP.1/ENC x x x
FCS_COP.1/AUTH x x
FCS_COP.1/MAC x x x
FCS_COP.1/SIG_GEN 92
x
FCS_RND.1 x x x
FIA_UID.1 x x
FIA_AFL.1 x x
FIA_API.1/AA 93
x
FIA_UAU.1 x x
FIA_UAU.4 x x x
FIA_UAU.5 x x x
FIA_UAU.6 x x x
FDP_ACC.1 x x x
FDP_ACF.1 x x x
FDP_UCT.1 x x x
FDP_UIT.1 x x x
FMT_SMF.1 x x x
91
TOE objective added in this ST with respect to [PP-BAC]
92
SFR added in this ST with respect to [PP-BAC]
93
SFR added in this ST with respect to [PP-BAC]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 82 of 111
OT.AC_Pers
OT.Data_Int
OT.
Data_Conf
OT.Identification
OT:Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfuntion
OT.Prot_Abuse-Func
OT.Chip_Auth_Proof
91
FMT_SMR.1 x x x
FMT_LIM.1 x
FMT_LIM.2 x
FMT_MTD.1/INI_ENA x
FMT_MTD.1/INI_DIS x
FMT_MTD.1/KEY_WRITE x x x x
FMT_MTD.1/KEY_READ x x x x
FPT_EMSEC.1 x x
FPT_TST.1 x x
FPT_FLS.1 x x x
FPT_PHP.3 x x x
Table 3: Coverage of Security Objective for the TOE by SFR
The security objective OT.AC_Pers “Access Control for Personalization of logical MRTD”
addresses the access control of the writing the logical MRTD. The write access to the logical
MRTD data are defined by the SFR FDP_ACC.1 and FDP_ACF.1 as follows: only the
successfully authenticated Personalization Agent is allowed to write the data of the groups
EF.DG1 to EF.DG16 of the logical MRTD only once.
The authentication of the terminal as Personalization Agent shall be performed by TSF according
to SRF FIA_UAU.4 and FIA_UAU.5. The Personalization Agent can be authenticated either by
using the BAC mechanism (FCS_CKM.1, FCS_COP.1/SHA, FCS_RND.1 (for key generation),
and FCS_COP.1/ENC as well as FCS_COP.1/MAC) with the personalization key or for reasons
of interoperability with the [BSI-PP-0056, Version 1.10, 25th March 2009 ] by using the symmetric
authentication mechanism (FCS_COP.1/AUTH).
In case of using the BAC mechanism the SFR FIA_UAU.6 describes the re-authentication and
FDP_UCT.1 and FDP_UIT.1 the protection of the transmitted data by means of secure
messaging implemented by the cryptographic functions according to FCS_CKM.1,
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 83 of 111
FCS_COP.1/SHA, FCS_RND.1 (for key generation), and FCS_COP.1/ENC as well as
FCS_COP.1/MAC for the ENC_MAC_Mode.
The SFR FMT_SMR.1 lists the roles (including Personalization Agent) and the SFR FMT_SMF.1
lists the TSF management functions (including Personalization) setting the Document Basic
Access Keys according to the SFR FMT_MTD.1/KEY_WRITE as authentication reference data.
The SFR FMT_MTD.1/KEY_READ prevents read access to the secret key of the Personalization
Agent Keys and ensure together with the SFR FCS_CKM.4, FPT_EMSEC.1, FPT_FLS.1 and
FPT_PHP.3 the confidentially of these keys.
The security objective OT.Data_Int “Integrity of personal data” requires the TOE to protect the
integrity of the logical MRTD stored on the MRTD’s chip against physical manipulation and
unauthorized writing. The write access to the logical MRTD data is defined by the SFR
FDP_ACC.1 and FDP_ACF.1 in the same way: only the Personalization Agent is allowed to write
the data of the groups EF.DG1 to EF.DG16 of the logical MRTD (FDP_ACF.1.2, rule 1) and
terminals are not allowed to modify any of the data groups EF.DG1 to EF.DG16 of the logical
MRTD (cf. FDP_ACF.1.4). The SFR FMT_SMR.1 lists the roles (including Personalization Agent)
and the SFR FMT_SMF.1 lists the TSF management functions (including Personalization). The
authentication of the terminal as Personalization Agent shall be performed by TSF according to
SRF FIA_UAU.4, FIA_UAU.5 and FIA_UAU.6 using either FCS_COP.1/ENC and
FCS_COP.1/MAC or FCS_COP.1/AUTH.
The security objective OT.Data_Int “Integrity of personal data” requires the TOE to ensure that
the inspection system is able to detect any modification of the transmitted logical MRTD data by
means of the BAC mechanism. The SFR FIA_UAU.6, FDP_UCT.1 and FDP_UIT.1 requires the
protection of the transmitted data by means of secure messaging implemented by the
cryptographic functions according to FCS_CKM.1, FCS_COP.1/SHA, FCS_RND.1 (for key
generation), and FCS_COP.1/ENC and FCS_COP.1/MAC for the ENC_MAC_Mode. The SFR
FMT_MTD.1/KEY_WRITE requires the Personalization Agent to establish the Document Basic
Access Keys in a way that they cannot be read by anyone in accordance to
FMT_MTD.1/KEY_READ.
The security objective OT.Data_Conf “Confidentiality of personal data” requires the TOE to
ensure the confidentiality of the logical MRTD data groups EF.DG1 to EF.DG16. The SFR
FIA_UID.1 and FIA_UAU.1 allow only those actions before identification respective
authentication which do not violate OT.Data_Conf. In case of failed authentication attempts
FIA_AFL.1 enforces additional waiting time prolonging the necessary amount of time for
facilitating a brute force attack. The read access to the logical MRTD data is defined by the
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 84 of 111
FDP_ACC.1 and FDP_ACF.1.2: the successful authenticated Personalization Agent is allowed to
read the data of the logical MRTD (EF.DG1 to EF.DG16). The successful authenticated Basic
Inspection System is allowed to read the data of the logical MRTD (EF.DG1, EF.DG2 and
EF.DG5 to EF.DG16). The SFR FMT_SMR.1 lists the roles (including Personalization Agent and
Basic Inspection System) and the SFR FMT_SMF.1 lists the TSF management functions
(including Personalization for the key management for the Document Basic Access Keys).
The SFR FIA_UAU.4 prevents reuse of authentication data to strengthen the authentication of
the user. The SFR FIA_UAU.5 enforces the TOE to accept the authentication attempt as Basic
Inspection System only by means of the Basic Access Control Authentication Mechanism with
the Document Basic Access Keys. Moreover, the SFR FIA_UAU.6 requests secure messaging
after successful authentication of the terminal with Basic Access Control Authentication
Mechanism which includes the protection of the transmitted data in ENC_MAC_Mode by means
of the cryptographic functions according to FCS_COP.1/ENC and FCS_COP.1/MAC (cf. the SFR
FDP_UCT.1 and FDP_UIT.1). (for key generation), and FCS_COP.1/ENC and FCS_COP.1/
MAC for the ENC_MAC_Mode. The SFR FCS_CKM.1, FCS_CKM.4, FCS_COP.1/SHA and
FCS_RND.1 establish the key management for the secure messaging keys. The
SFRFMT_MTD.1/KEY_WRITE addresses the key management and FMT_MTD.1/KEY_READ
prevents reading of the Document Basic Access Keys.
Note, neither the security objective OT.Data_Conf nor the SFR FIA_UAU.5 requires the
Personalization Agent to use the Basic Access Control Authentication Mechanism or secure
messaging.
The security objective OT.Identification “Identification and Authentication of the TOE” address
the storage of the IC Identification Data uniquely identifying the MRTD’s chip in its non-volatile
memory. This will be ensured by TSF according to SFR FAU_SAS.1.
Furthermore, the TOE shall identify itself only to a successful authenticated Basic Inspection
System in Phase 4 “Operational Use”. The SFR FMT_MTD.1/INI_ENA allows only the
Manufacturer to write Initialization Data and Pre-personalization Data (including the
Personalization Agent key). The SFR FMT_MTD.1/INI_DIS allows the Personalization Agent to
disable Initialization Data if their usage in the phase 4 “Operational Use” violates the security
objective OT.Identification. The SFR FIA_UID.1 and FIA_UAU.1 do not allow reading of any data
uniquely identifying the MRTD’s chip before successful authentication of the Basic Inspection
Terminal and will stop communication after unsuccessful authentication attempt. In case of failed
authentication attempts FIA_AFL.1 enforces additional waiting time prolonging the necessary
amount of time for facilitating a brute force attack.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 85 of 111
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 which may not be used after TOE Delivery.
The security objective OT.Prot_Inf_Leak “Protection against Information Leakage” requires the
TOE to protect confidential TSF data stored and/or processed in the MRTD’s chip against
disclosure

 by measurement and analysis of the shape and amplitude of signals or the time between
events found by measuring signals on the electromagnetic field, power consumption, clock,
or I/O lines which is addressed by the SFR FPT_EMSEC.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.
The security objective OT.Prot_Phys-Tamper “Protection against Physical Tampering” is
covered by the SFR FPT_PHP.3.
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 the integrity of TSF data and TSF code, (ii) the SFR FPT_FLS.1 which
requires a secure state in case of detected failure or operating conditions possibly causing a
malfunction.
The security objective OT.Chip_Auth_Proof “Proof of MRTD’s chip authenticity” is ensured by
Active Authentication provided by FIA_API.1/AA proving the identity of the TOE.
The Active Authentication defined by FCS_COP.1/SIG_GEN for the generation of the RSA and
ECDSA Signature is performed using a TOE internally stored confidential private key as required
by FMT_MTD.1/KEY_WRITE and FMT_MTD.1/KEY_READ. According to FDP_ACF.1, only the
successfully authenticated Basic, Generic and Extended Inspection Systems are allowed to
request active authentication (FDP_ACF.1.2, rule 2).
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 86 of 111
6.3.2 Dependency Rationale
The dependency analysis for the security functional requirements shows that the basis for mutual
support and internal consistency between all defined functional requirements is satisfied. All
dependencies between the chosen functional components are analyzed, and non-dissolved
dependencies are appropriately explained.
The table 8 shows the dependencies between the SFR of the TOE.
SFR Dependencies
Support of the
Dependencies
FAU_SAS.1 No dependencies n.a.
FCS_CKM.1 [FCS_CKM.2 Cryptographic key
distribution or FCS_COP.1
Cryptographic operation],
FCS_CKM.4 Cryptographic key
destruction
Fulfilled by
FCS_COP.1/ENC, and
FCS_COP.1/MAC
Fulfilled by FCS_CKM.4
FCS_CKM.4 [FDP_ITC.1 Import of user data
without security attributes,
FDP_ITC.2 Import of user data with
security attributes, or FCS_CKM.1
Cryptographic key generation]
Fulfilled by FCS_CKM.1
FCS_COP.1/SHA [FDP_ITC.1 Import of user data
without security attributes,
FDP_ITC.2 Import of user data with
security attributes, or FCS_CKM.1
Cryptographic key generation],
FCS_CKM.4 Cryptographic key
destruction
Justification 1 for non-
satisfied dependencies
Fulfilled by
FCS_CKM.4
FCS_COP.1/ENC [FDP_ITC.1 Import of user data
without security attributes,
FDP_ITC.2 Import of user data with
security attributes, or FCS_CKM.1
Cryptographic key generation],
FCS_CKM.4 Cryptographic key
destruction
Fulfilled by
FCS_CKM.1 and
FCS_CKM.4,
FCS_COP.1/AUTH [FDP_ITC.1 Import of user data
without security attributes,
FDP_ITC.2 Import of user data with
security attributes, or FCS_CKM.1
Cryptographic key generation],
FCS_CKM.4 Cryptographic key
destruction
Justification 2 for non-
satisfied dependencies
FCS_COP.1/MAC [FDP_ITC.1 Import of user data
without security attributes,
FDP_ITC.2 Import of user data with
security attributes, or FCS_CKM.1
Cryptographic key generation],
FCS_CKM.4 Cryptographic key
destruction
Fulfilled by
FCS_CKM.1 and
FCS_CKM.4
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 87 of 111
SFR Dependencies
Support of the
Dependencies
FCS_COP.1/SIG_GEN [FDP_ITC.1 Import of user data
without security attributes, or
FDP_ITC.2 Import of user data with
security attributes, or FCS_CKM.1
Cryptographic key generation]
FCS_CKM.4 Cryptographic key
destruction
Fulfilled by
FCS_CKM.1, FCS_CKM.4
FCS_RND.1 No dependencies n.a.
FIA_AFL.1 FIA_UAU.1 Timing of authentication Fulfilled
FIA_API.1/AA No dependencies n.a.
FIA_UID.1 No dependencies n.a.
FIA_UAU.1 FIA_UID.1 Timing of authentication Fulfilled
FIA_UAU.4/ No dependencies n.a.
FIA_UAU.5/ No dependencies n.a.
FIA_UAU.6/ No dependencies n.a.
FDP_ACC.1 FDP_ACF.1 Security attribute
based access control
Fulfilled by FDP_ACF.1
FDP_ACF.1
FDP_ACC.1 Subset access control,
FMT_MSA.3 Static attribute
initialization
Fulfilled by FDP_ACC.1,
justification 3 for non-satisfied
dependencies
FDP_UCT.1 [FTP_ITC.1 Inter-TSF trusted
channel, or FTP_TRP.1 Trusted
path], [FDP_ACC.1 Subset access
control, or FDP_IFC.1 Subset
information flow control]
Fulfilled by FDP_ACC.1,
justification 4 for non-satisfied
dependencies
FDP_UIT.1 [FTP_ITC.1 Inter-TSF trusted
channel, or FTP_TRP.1 Trusted
path], [FDP_ACC.1 Subset access
control, or FDP_IFC.1 Subset
information flow control]
FDP_ACC.1, justification 4
for non-satisfied
dependencies
FMT_SMF.1 No dependencies n.a.
FMT_SMR.1 FIA_UID.1 Timing of identification Fulfilled
FMT_LIM.1 FMT_LIM.2 Fulfilled
FMT_LIM.2 FMT_LIM.1 Fulfilled
FMT_MTD.1/INI_ENA
FMT_SMF.1 Specification of
management functions,
FMT_SMR.1 Security roles
Fulfilled
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 88 of 111
SFR Dependencies
Support of the
Dependencies
FMT_MTD.1/INI_DIS
FMT_SMF.1 Specification of
management functions,
FMT_SMR.1 Security roles
Fulfilled
FMT_MTD.1/KEY_WRITE
FMT_SMF.1 Specification of
management functions,
FMT_SMR.1 Security roles
Fulfilled
FMT_MTD.1/KEY_READ
FMT_SMF.1 Specification of
management functions,
FMT_SMR.1 Security roles
Fulfilled
FPT_EMSEC.1 No dependencies n.a.
FPT_FLS.1 No dependencies n.a.
FPT_PHP.3 No dependencies n.a.
FPT_TST.1 No dependencies n.a.
Table 4: Dependencies between the SFR for the TOE
Justification for non-satisfied dependencies between the SFR for TOE:
No. 1: The hash algorithm required by the SFR FCS_COP.1/SHA does not need any key
material. Therefore neither a key generation (FCS_CKM.1) nor an import (FDP_ITC.1/2) is
necessary.
No. 2: The SFR FCS_COP.1/AUTH uses the symmetric Personalization Key permanently stored
during the Pre-Personalization process (cf. FMT_MTD.1/INI_ENA) by the manufacturer. Thus
there is neither the necessity to generate or import a key during the addressed TOE life cycle by
the means of FCS_CKM.1 or FDP_ITC. Since the key is permanently stored within the TOE
there is no need for FCS_CKM.4, too.
No. 3: The access control TSF according to FDP_ACF.1 uses security attributes which are
defined during the personalization and are fixed over the whole life time of the TOE. No
management of these security attribute (i.e. SFR FMT_MSA.1 and FMT_MSA.3) is necessary
here.
No. 4: The SFR FDP_UCT.1 and FDP_UIT.1 require the use of secure messaging between the
MRTD and the BIS. There is no need for SFR FTP_ITC.1, e.g. to require this communication
channel to be logically distinct from other communication channels since there is only one
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 89 of 111
channel. Since the TOE does not provide a direct human interface a trusted path as required by
FTP_TRP.1 is not applicable here.
6.3.3 Security Assurance Requirements Rationale
The EAL4 was chosen to permit a developer to gain maximum assurance from positive security
engineering based on good commercial development practices which, though rigorous, do not
require substantial specialist knowledge, skills, and other resources. EAL4 is the highest level at
which it is likely to be economically feasible to retrofit to an existing product line. EAL4 is
applicable in those circumstances where developers or users require a moderate to high level of
independently assured security in conventional commodity TOEs and are prepared to incur
sensitive security specific engineering costs.
The selection of the component ALC_DVS.2 provides a higher assurance of the security of the
MRTD’s development and manufacturing especially for the secure handling of the MRTD’s
material.
The component ALC_DVS.2 has no dependencies.
.
6.3.4 Security Requirements – Mutual Support and Internal Consistency
The following part of the security requirements rationale shows that the set of security
requirements for the TOE consisting of the security functional requirements (SFRs) and the
security assurance requirements (SARs) together form a mutually supportive and internally
consistent whole.
The analysis of the TOE´s security requirements with regard to their mutual support and internal
consistency demonstrates:
• The dependency analysis section 6.3.2 Dependency Rationale for the security functional
requirements shows that the basis for mutual support and internal consistency between all
defined functional requirements is satisfied. All dependencies between the chosen functional
components are analyzed, and non-satisfied dependencies are appropriately explained.
• The assurance class EAL4 is an established set of mutually supportive and internally
consistent assurance requirements. The dependency analysis for the sensitive assurance
components in section 6.3.3 Security Assurance Requirements Rationale shows that the
assurance requirements are mutually supportive and internally consistent as all (sensitive)
dependencies are satisfied and no inconsistency appears.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 90 of 111
Inconsistency between functional and assurance requirements could only arise if there are
functional-assurance dependencies which are not met, a possibility which has been shown not to
arise in sections 6.3.2 Dependency Rationale and 6.3.3 Security Assurance Requirements
Rationale. Furthermore, as also discussed in section 6.3.3 Security Assurance Requirements
Rationale, the chosen assurance components are adequate for the functionality of the TOE. So
the assurance requirements and security functional requirements support each other and there
are no inconsistencies between the goals of these two groups of security requirements.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 91 of 111
7 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 which can be associated into following groups:
• Identification and Authentication mechanisms
• Cryptographic functions support
• Access control /Storage and protection of logical MRTD 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 IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0
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.
The following overview shows how these features satisfy the security functional requirements
specified in chapter 6.1.
Remark:
The numbering of the security functions is consistent with the Security Target [ST-SAC-EAC],
which covers the IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 certified under BSI-DSZ-CC-
0866 in SAC/EAC configuration, where its supports in addition to BAC and Active Authentication
also PACEV2 and Extended Access Control (EACv1) in accordance with respectively [ICAO-
SAC] and [TR-03110-1] and [TR-03110-3].
7.1 SF.I&A 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.
The TOE supports the following authentication mechanisms:
• Basic Access Control Authentication mechanism (BAC)
• Authentication of the Personalization Agent with a personalisation key set based on a
symmetric authentication mechanism.
• Active Authentication
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 92 of 111
SF.I&A.0 Basic Access Control Authentication mechanism (BAC)
This security functionality accomplishes the ICAO symmetric Basic Access Control Authentication
Mechanism used by the Basic Inspection System knowing the Document Basic Access Keys (printed
on the passport).
The implementation of BAC contributes to:
• FIA_UID.1 Timing of Identification
• FIA_UAU.1 Timing of Authentication
• FIA_UAU.4 Single-use authentication of the Terminal by the TOE
• FIA_UAU.5 Multiple authentication mechanisms
• FIA_UAU.6 Re-authenticating of Terminal by the TOE
• FMT_SMR.1 Security Roles
• FCS_COP.1/AUTH
• FIA_AFL.1 Authentication Failure Handling
SF.I&A.4 Authentication of the Personalization Agent based on a symmetric
authentication mechanism
In PERSONALISATION life-cycle state the TOE enforces mutual authentication between
Personalisation Agent and TOE based on either of the following symmetric key authentication
mechanisms.
• ICAO BAC authentication mechanism and secure messaging protocol defined in [ICAO-9303]
for 112 bits 3DES with pre-installed MAC, ENC (and KEK) keys as Personalisation Agent Key
set.
• ISO18013 BAP authentication mechanism defined in [ISO18013-3] for AES-128, 192 or 256
bits using AES secure messaging (CMAC, IV value, tags etc.) as specified in EAC TR-03110
[TR-03110-1] with pre-installed MAC, ENC (and KEK) keys as Personalisation Agent Key set.
The Personalization Agent authenticates by two symmetric keys (MAC and ENC). The KEK key may
be used for secure replacement of an existing key set.
The Personalisation Key values and as well as the secure messaging protocol are installed and
configured into the TOE by the Manufacturer during pre-personalisation. In both PRE-
PERSONALISATION and PERSONALISATION life-cycle state the TOE supports the reading of IC
Identification data for supporting key diversification of the Personalisation Agent Key set.
The implementation contributes to
• FIA_UID.1 Timing of Identification
• FIA_UAU.1 Timing of authentication
• FIA_UAU.4 Single-use authentication of the Terminal by the TOE
• FIA_UAU.5 Multiple authentication mechanisms
• FMT_SMR.1 Security Roles
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 93 of 111
SF.I&A.5 Active Authentication of the MRTD’s chip
This protocol provides evidence of the MRTD’s chip authenticity as described in [ICAO-9303]. The
TOE support Active Authentication for both RSA and ECDSA mechanisms. Active Authentication may
be used by Generic, Basic and Extended Inspection Systems.
The implementation of Active Authentication contributes to
• FIA_API.1/AA Authentication Proof of Identity – MRTD
• FMT_MTD.1/KEY_WRITE, Management of TSF data – Key Write
• FMT_MTD.1/KEY_READ, Management of TSF data – Key Read
• FCS_COP.1/SIG_GEN, Cryptographic operation – Signature generation by travel document
(RSA and ECDSA)
7.2 SF.CF Cryptographic functions support
Cryptographic function support is provided by the underlying JCOP platform, i.e. the TOE relies
on the underlying platform for performing its required cryptographic operations.
SF.CF Cryptographic functions include:
• 3DES and AES cipher operations for secure messaging
• Digest calculations (SHA-1, SHA-224, and SHA-256)
• Signature generation (ECDSA, RSA)
• Cryptographic key generation
• Key Destruction
• True Random Number generation
With respect to the ECC domain parameters for the elliptic curve cryptographic functions
supported by the TOE in this section, the following application note is applicable.
ST Application note 3
The ECC Brainpool and NIST domain parameters are regarded cryptographically strong by the
German Certification body, the Bundesamt für Sicherheit in der Informationstechnik (BSI) see
[TR-02102]. The FRP256v1 have been defined by French Certification Body, Agence Nationale
de la Sécurité des Systèmes d'Information (ANSSI) and are also regarded as cryptographically
strong, see [ANSSI-FRP256V1].
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 94 of 111
SF.CF.1 3DES and AES cipher operations for secure messaging
3DES (112 bit keys) and AES (128, 192 and 256 bit keys) are provided by the platform. The TOE
uses 3DES and AES for en-/decryption (CBC and ECB) and Message Authentication Code (MAC for
DES, CMAC for AES) generation and verification.
The implementation of this security function contributes to:
• FCS_COP.1/ ENC Cryptographic operation – Encryption / Decryption Triple DES
• FCS_COP.1/ MAC Cryptographic operation Retail MAC
SF.CF.2 Digest calculations (SHA-1, SHA-224, and SHA-256)
The platform digest functions are used by the ePassport implementations of:
• Active Authentication
SHA-1, SHA-224 and SHA-256 are used by the TOE for the hash calculation and the
creation of the ISO9796 signature format with explicit hash identifier prior to calling the
platform RSA signature generation function.
• [Basic Access Control]
The TOE implements the hash function SHA-1 for the cryptographic primitive to derive the
keys for secure messaging from the shared secrets of the Basic Access Control
Authentication Mechanism (cf. [ICAO-9303], Volume 2, Appendix 5 to Section IV. par. A5.1).
The implementation of this security function contributes to:
• FCS_COP.1/SIG_GEN
• FIA_API.1/AA
• FCS_COP.1/SHA Cryptographic operation – Hash for Key Derivation by MRTD and
according the application in paragraph 6.1.2.1 in this ST.
SF.CF.3 Signature generation (ECDSA, RSA)
Signature generation functions performed by the ePassport implementation for:
• Active Authentication - ECDSA cf. [ISO15946-2]:
o Supported key sizes within the scope of this ST are 192, 224, 256 and 320 bits
o Supported domain parameters for ECDSA in accordance with [RFC-5639], [NIST-
186-3] and [ANSSI-FRP256V1]:

 Brainpool192r1

 Brainpool224r1

 Brainpool256r1
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 95 of 111

 Brainpool320r1

 NIST P-192 (secp192r1)

 NIST P-224 (secp224r1)

 NIST P-256 (secp256r1)

 ANSSI FRP256v1
o Supported signature formats:

 ECDSA_SHA-1

 ECDSA_SHA-224

 ECDSA_SHA-256
• Active Authentication - RSA cf. [ISO9796-2]:
o Supported key sizes within the scope of this ST are 1536, 1792 and 2048 bits
o Supported signature formats:

 ISO9796 with SHA-1 (with implicit hash identifier)

 ISO9796 with SHA-224 (with explicit hash identifier)

 ISO9796 with SHA-256 (with explicit hash identifier)
The implementation of this security function contributes to:
• FCS_COP.1/SIG_GEN (Supports ECDSA and RSA signature generation)
SF.CF.6 Cryptographic key generation
The TOE uses Java Card platform functionality for key generation. The TOE supports (on board)
session key generation for the following cryptographic keys:
• BAC protocol
(available in TOE’s OPERATIONAL life-cycle state)
o MAC and ENC 3DES session keys for secure messaging in MAC_ENC mode. The
TOE performs Cryptographic key generation according to the Document Basic
Access Key Derivation Algorithm and a key size of 112 bits.
• MUTUAL Authentication protocol used by Personalisation Agent
(available in TOE’s PERSONALISATION life-cycle state)
o MAC and ENC 3DES, AES-128, AES-192 or AES-256 bits session keys for secure
messaging in MAC_ENC mode derived using static installed Personalisation Agent
Key set
The implementation of this security function contributes to:
• FCS_CKM.1 Cryptographic key generation – Key Derivation Function by the MRTD
• FCS_COP.1/SHA Cryptographic operation – Hash for Key Derivation by MRTD and
according the application in paragraph 6.1.2.1 in this ST.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 96 of 111
SF.CF.7 Destruction of cryptographic keys
• The TOE uses Java Card platform functionality for key destruction. A special
javacard.security method of the JCOP platform is used. The transient keys will be
reset by the JCOP platform if a deselect of the ePassport application or a reset occurs in an
authenticated phase of the TOE.
• The TOE destroys all session keys in accordance with FCS_CKM.4 after detection of an
error in a received command by verification of the MAC
• The TOE clears the memory area of any session keys before starting the communication
with the terminal in a new after-reset-session.
The implementation of this security function contributes to:
• FCS_CKM.4/ Cryptographic key destruction
SF.CF.8 Random number generation
The TOE uses platform for true random number generation.
• Platform function used by the ePassport implementation provides random number
generation in accordance with class DRG.3 of [KS2011]
The implementation of this security function contributes to:
• FCS_RND.1/ Quality metric for random numbers
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 97 of 111
7.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 NXP
J3E120_M65 (JCOP2.4.2R3) platform. The JCOP platform provides protection against physical
attack and performs self tests as described in [JCOP-ST].
The JCOP 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 IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 Applet uses transient memory where a hardware
reset always reverts the IDeal Pass v2 - SAC/EAC JC ePassport v4.0.0 Applet into an
unauthenticated state.
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
7.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.
The implementation of this security function contributes to:
• FDP_ACC.1 Subset access control - Basic Access Control
• FDP_ACF.1 Security attribute based access control - Basic Access Control
• FDP_UIT.1 Data exchange integrity - MRTD
• FDP_UCT.1 Basic data exchange confidentiality - MRTD
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 98 of 111
7.5 SF.SM Secure Messaging
SF.SM.1 Secure Messaging
Secure messaging MAC and ENC operations are performed by the TOE’s platform.
In PERSONALISATION life-cycle state the TOE supports 3DES or AES secure messaging in
ENC_MAC mode, after a successful mutual authentication between TOE and Personalisation Agent
terminal have been accomplished (see SF.I&A.4):
• ICAO secure messaging protocol defined in [ICAO-9303] for 112 bits 3DES with pre-installed
MAC, ENC (and KEK) keys as Personalisation Agent Key set.
• ISO18013 BAP secure messaging defined in [ISO18013-3] for AES-128, 192 or 256 bits
using AES secure messaging (CMAC, IV value, tags etc.) as specified in EAC TR-03110 [TR-
03110-1] with pre-installed MAC, ENC (and KEK) keys as Personalisation Agent Key set.
In OPERATIONAL life-cycle state the TOE runs secure messaging in ENC_MAC mode uses 112 bit
Triple-DES in CBC mode only after successful BAC authentication. The MAC is calculated according
to the Retail MAC cryptographic algorithm specified in [ISO9797], MAC algorithm 3, block cipher
DES, Sequence Message Counter, padding mode 2. Secure messaging in ENC_MAC mode is
established during BAC and is based on SF.CF.1, 6 and 8.
The implementation of this security function contributes to:
• FCS_COP.1/ENC: Encryption/Decryption 3DES
• FCS_COP.1/MAC: Cryptographic operation – Retail MAC
• FDP_UCT.1 Basic data exchange confidentiality
• FDP_UIT.1 Data exchange integrity
SF.SM.2 Secure Messaging – Re-authentication
In OPERATIONAL life-cycle state, the Retail MAC for 3DES is part of every APDU
command/response when secure messaging is active after a successful BAC authentication has been
accomplished. Re-authentication after reset of the SM protocol is assured by accepting only valid
mandatory MAC cryptograms.
In PERSONALISATION life-cycle state either the Retail MAC for 3DES or the CMAC for AES are part
of every APDU command/response when secure messaging is active after a successful mutual
authentication between TOE and Personalisation Agent has been accomplished. Re-authentication
after reset of the SM protocol is assured by accepting only valid (mandatory) MAC or CMAC
cryptograms.
The implementation of this security function contributes to:
• FIA_UAU.6 Re-authenticating – Re-authenticating of Terminal by the TOE
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 99 of 111
7.6 SF.LCM Security and life cycle management
For the IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 the following life-cycle phases have been identified:
1. Manufacturing phase
2. Personalisation phase
3. Operational phase
4. Termination phase
The life-time phases are reflected within the IDeal Pass v2 - SAC/EAC JC ePassport applet by an internal
life-cycle state machine and supports the following life-cycle states:
1. Not instantiated (applet resides in EEPROM or ROM)
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
-
(Applet not instantiated)
IC Manufacturer
-
(Applet not instantiated)
MRTD Manufacturer
(Platform initialisation)
Manufacturing phase
PRE-PERSONALISATION MRTD Manufacturer
(Pre-personalisation)
Personalisation phase PERSONALISATION Personalisation Agent
Operational phase OPERATIONAL Basic or Extended Inspection
system
Termination phase TERMINATED None
Table 5: Life-cycle phases and states
All role holders in Manufacturing, Pre-Personalisation and Personalisation phases are Identified by
cryptographic authentication keys. In Operational phase the BAC password is required to authenticate the
Basic or Extended Inspection System in order to get access to the non-sensitive ICAO LDS datagroups.
The IDeal Pass v2 - SAC/EAC JC ePassport 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, personalisation and operational phases. The
phases (and corresponding life-cycle states) are controlled by APDU commands. The life-cycle phase and
state transitions are irreversible.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 100 of 111
In case the TOE has detected an integrity error or perturbation attack, all MRTD functionality is
permanently blocked.
SF.LCM.1
Management of phases, roles and MRTD life-cycle states – Manufacturing phase
This security feature supports the management of roles and life-cycle state during Manufacturing
phase.
The implementation of this security function contributes to:
• FMT_SMF.1 Specification of Management Functions (Initialization part)
• FMT_SMR.1.1 Security roles (Manufacturer)
• FMT_MTD.1/INI_ENA Management of TSF data – Writing of Initialization Data and
Pre-personalization Data
• FMT_MTD.1/INI_DIS Management of TSF data – Disabling of Read Access to
Initialization Data and Pre-personalization Data
SF.LCM.2
Management of phases, roles and MRTD life-cycle states – Personalisation phase
This security feature supports the management of roles and life-cycle state during Personalisation
phase.
The implementation of this security function contributes to:
• FMT_SMF.1 Specification of Management Functions
(Personalization)
• FMT_SMR.1.1 Security roles (Personalization Agent)
• FMT_MTD.1/KEY_WRITE (Management of TSF data – Key Write)
Restriction of the ability to write (load) the Active Authentication Private Key, the BAC
keys or refresh the Personalisation Agent Key Set to the Personalisation Agent in
PERSONALISATION life-cycle state.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 101 of 111
SF.LCM.4 Protection of test features
The test features of the JCOP platform are protected by ways described in JCOP ST and guidance
documentation. The IDeal Pass v2 - SAC/EAC JC ePassport Applet does not have any dedicated test
features implemented.
The platform implementation provides this security function and contributes to:
• FMT_LIM.1 Limited capabilities
• FMT_LIM.2 Limited availability
SF.LCM.5 Protection of keys and BAC password
In the TOE’s PRE-PERSONALISATION life-cycle state the personalisation Agent Key Set is installed
on the TOE’s platform and protected by the platform.
In all other TOE life-cycle states the Personalization Agent Key set (MAC, ENC, KEK), the BAC keys
(derived from MRZ ) and the Active Authentication Private Key are also protected from disclosure.
The IDeal Pass v2 - SAC/EAC JC ePassport Applet only stores keys in Java Card specified Key
structures, which are protected by JCOP platform.
The implementation of this security function contributes to:
• FMT_MTD.1/KEY_READ Management of TSF data – Key Read
• FPT_EMSEC.1 TOE emanation
SF.LCM.6 IC Identification data
During initialisation the IDeal Pass v2 - SAC/EAC JC ePassport Applet is installed and initiated with
the
Pre-Personalisation Agent key and the IC Identification data.
The INSTALL for INSTALL method of the JCOP platform will be used to store the IC Identification
data.
• 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
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 102 of 111
8 Annex
8.1 Glossary
Term Definition
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
Initialization Data and Pre-personalization Data.
Authenticity Ability to confirm the MRTD and its data elements on the MRTD’s chip were
created by the issuing State or Organization
Basic Access
Control (BAC)
Security mechanism defined in [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 terminal that uses the Standard Inspection Procedure to authenticate itself to
the MRTD chip using BAC or PACE. The Standard ePassport Inspection
Procedure does not authenticate the terminal as inspection system. A basic
inspection system is only authorized to access less-sensitive data contained in
an ICAO compliant ePassport Application.
Basic Inspection
System (BIS)
An inspection system which implements the terminals part of the Basic Access
Control Mechanism and authenticates themselves to the MRTD’s chip using
the Document Basic Access Keys drawn form printed MRZ data for reading
the logical MRTD.
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.
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.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 103 of 111
Term Definition
Certificate chain Hierarchical sequence of Inspection System Certificate (lowest level),
Document Verifier Certificate and Country Verifying Certification Authority
Certificates (highest level), where the certificate of a lower lever is signed with
the private key corresponding to the public key in the certificate of the next
higher level. The Country Verifying Certification Authority Certificate is signed
with the private key corresponding to the public key it contains (self-signed
certificate).
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.
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]
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]
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.
Forgery Fraudulent alteration of any part of the genuine document, e.g. changes to the
biographical data or the portrait.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 104 of 111
Term Definition
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
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.
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]
Initialization 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).
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 a 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]
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 105 of 111
Term Definition
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 MRTD Data of the MRTD holder stored according to the Logical Data Structure
[ICAO-9303] as specified by ICAO on the contactless integrated circuit. It
presents contactless readable data including (but not limited to)
personal data of the MRTD holder
the digital Machine Readable Zone Data (digital MRZ data, DG1),
the digitized portraits (DG2),
the biometric reference data of finger(s) (DG3) or iris image(s) (DG4) or both
and
the other data according to LDS (DG5 to DG16).
Logical travel
document
Data stored according to the Logical Data Structure as specified by ICAO in
the contactless integrated circuit including (but not limited to)
data contained in the machine-readable zone (mandatory),
digitized photographic image (mandatory) and
fingerprint image(s) and/or iris image(s) (optional).
Machine readable
travel document
(MRTD)
Official document issued by a State or Organization which is used by the
holder for international travel (e.g. passport, visa, official document of identity)
and which contains mandatory visual (eye readable) data and a separate
mandatory data summary, intended for global use, reflecting essential data
elements capable of being machine read. [ICAO-9303]
Machine readable
visa (MRV):
A visa or, where appropriate, an entry clearance (hereinafter collectively
referred to as visas) conforming to the specifications contained herein,
formulated to improve facilitation and enhance security for the visa holder.
Contains mandatory visual (eye readable) data and a separate mandatory
data summary capable of being machine read. The MRV is normally a label
which is attached to a visa page in a passport.[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]
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.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 106 of 111
Term Definition
MRTD application Non-executable data defining the functionality of the operating system on the
IC as the MRTD’s chip. It includes
the file structure implementing the LDS [ICAO-9303],
the definition of the User Data, but does not include the User Data itself (i.e.
content of DG1 to DG13 and DG 16) and
the TSF Data including the definition the authentication data but except the
authentication data itself.
MRTD Basic Access
Control
Mutual authentication protocol followed by secure messaging between the
inspection system and the MRTD’s chip based on MRZ information as key
seed and access condition to data stored on MRTD’s chip according to LDS.
MRTD holder The rightful holder of the MRTD for whom the issuing State or Organization
personalized the MRTD.
MRTD’s Chip A contactless or contact based integrated circuit chip complying with ISO/IEC
14443 and programmed according to the Logical Data Structure as specified
by ICAO, [ICAO-9303].
MRTD’s chip
Embedded Software
Software embedded in a MRTD’s chip and not being developed by the IC
Designer. The MRTD’s chip Embedded Software is designed in Phase 1 and
embedded into the MRTD’s chip in Phase 2 of the TOE life-cycle.
Optional biometric
reference data
Data stored for biometric authentication of the MRTD holder in the MRTD’s
chip as (i) encoded finger image(s) (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.
Passive
authentication
(i) verification of the digital signature of the Document Security Object and (ii)
comparing the hash values of the read LDS data fields with the hash values
contained in the Document Security Object.
Personalization The process by which the portrait, signature and biographical data are applied
to the document.
Personalization
Agent
The agent acting on the behalf of the issuing State or organisation to
personalize the MRTD for the holder by (i) establishing the identity the holder
for the biographic data in the MRTD, (ii) enrolling the biometric reference data
of the MRTD holder i.e. the portrait, the encoded finger image(s) or (ii) the
encoded iris image(s) and (iii) writing these data on the physical and logical
MRTD for the holder.
Personalization
Agent Authentication
Information
TSF data used for authentication proof and verification of the Personalization
Agent.
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 107 of 111
Term Definition
Personalization
Agent Authentication
Key
Symmetric cryptographic key used (i) by the Personalization Agent to prove
their identity and get access to the logical MRTD according to the SFR
FIA_UAU.4/BT FIA_UAU.6/BT and FIA_API.1/SYM_PT and (ii) by the MRTD’s
chip to verify the authentication attempt of a terminal as Personalization Agent
according to the SFR FIA_UAU.4, FIA_UAU.5 and FIA_UAU.6.
Physical travel
document
Travel document in form of paper, plastic and chip using secure printing to
present data including (but not limited to)
- biographical data,
- data of the machine-readable zone,
- photographic image and
- other data.
Pre-personalization
Data
Any data that is injected into the non-volatile memory of the TOE by the MRTD
Manufacturer (Phase 2) for traceability of non-personalized MRTD’s and/or to
secure shipment within or between life cycle phases 2 and 3. It contains (but is
not limited to) the Personalization Agent Key Pair and Chip Life-Cycle
Production data (CPLC data).
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.
secondary image A repeat image of the holder’s portrait reproduced elsewhere in the document
by whatever means.
secure messaging in
encrypted mode
Secure messaging using encryption and message authentication code
according to ISO/IEC 7816-4
Skimming Imitation of the inspection system to read the logical MRTD or parts of it via
the contactless or contact based communication channel of the TOE without
knowledge of the printed MRZ data.
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.
Travel document A passport or other official document of identity issued by a State or organi-
zation, which may be used by the rightful holder for international travel. [ICAO-
9303]
Traveler Person presenting the MRTD to the inspection system and claiming the
identity of the MRTD holder.
TSF data Data created by and for the TOE, that might affect the operation of the TOE
(CC part 1).
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 108 of 111
Term Definition
Unpersonalised
MRTD
MRTD material prepared to produce an personalized MRTD containing an
initialized and pre-personalized MRTD’s chip.
User data Data created by and for the user, that does not affect the operation of the TSF
(CC part 1).
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.
8.2 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
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 109 of 111
8.3 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] Protection Profile - Machine Readable Travel Document with „ICAO
Application",Basic Access Control, BSI-PP-0055, 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] Common Criteria Protection Profile Machine Readable Travel Document with
„ICAO Application", Extended Access Control, BSI-PP-0056, Version 1.10,
25th March 2009
[EAC-PP-V2] Common Criteria Protection Profile - Machine Readable Travel Document
with „ICAO Application", Extended Access Control, BSI-PP-0056-V2, Version
1.3.2. December 5th, 2012
[FIPS 186-2] FIPS PUB 186-2, Digital Signature Standard (DSS), 2000 January 27
[FIPS46] Federal Information Processing Standards Publication FIPS PUB 46-3, Data
Encryption Standard (DES), Reaffirmed 1999 October 25, U.S. department of
Commerce/National Institute of Standards and Technology
[ICAO-9303] ICAO 9303: Machine Readable Travel Documents Part 3: Machine readable
passport, Vol. 2: Specifications for Electronically Enabled MRTDs with
Biometric Identification Capability – Third Edition 2008 - International Civil
Aviation Organization (ICAO)
[IC-PP] PP conformant to Smartcard IC Platform Protection Profile, Version 1.0, July
2001; registered and certified by Bundesamt für Sicherheit in der
Informationstechnik (BSI) under the reference BSI-PP-0002-2001
[ISO15946-1] ISO/IEC 15946-1. Information technology – Security techniques –
Cryptographic techniques based on elliptic curves – Part 1: General, 2002
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 110 of 111
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
[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.
[JCOP-ADM] JCOP V2.4.2 Revision 3 Secure Smart Card Controller -
Administrator Manual for NXP J3E145_M64, J3E120_M65, J3E082_M65,
J2E145_M64, J2E120_M65, J2E082_M65, J3E081_M64, J3E081_M66,
J2E081_M64, J3E081_M64_DF, J3E081_M66_DF, J3E016_M64,
J3E041_M64, J3E016_M66, J3E041_M66, J3E016_M64_DF,
J3E041_M64_DF, J3E016_M66_DF and J3E041_M66_DF Secure Smart
Card Controller Revision 3
Rev.0.5, 16 July 2013, NXP (NSCIB-CC-13-37760)
[JCOP-ST] Security Target JCOP2.4.2R3
NXP J3E145_M64, J3E120_M65,J3E082_M65, J2E145_M64, J2E120_M65
and J2E082_M65 Secure Smart Card Controller Revision 3
Rev. 01.01 — 25th July 2013, NXP (NSCIB-CC-13-37760)
[JCOP-UM] JCOP V2.4.2 Revision 3 Secure Smart Card Controller -
User manual for NXP J3E145_M64, J3E120_M65, J3E082_M65,
J2E145_M64, J2E120_M65, J2E082_M65, J3E081_M64, J3E081_M66,
J2E081_M564, J3E081_M64_DF, J3E081_M66_DF, J3E016_M64,
J3E041_M64, J3E016_M66, J3E041_M66, J3E016_M64_DF,
J3E041_M64_DF, J3E016_M66_DF and J3E041_M66_DF Secure Smart
Card Controller Revision 3
Rev.0.6, 16 July 2013, NXP (NSCIB-CC-13-37760)
[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
[RFC-5639] Lochter, Manfred; Merkle, Johannes. Elliptic Curve Cryptography (ECC)
Brainpool Standard Curves and Curve Generation, RFC 5639, 2010
Security Target Lite
IDeal Pass v2 - SAC/EAC JC ePassport 4.0.0 (BAC configuration) 2014-01-22
Public release.
© Morpho B.V.
Page 111 of 111
Reference Description
[SIC-PP] Security IC Platform Protection Profile, Version 1.0, June 2007; registered
and certified BSI (Bundesamt für Sicherheit in der Informationstechnik) under
the reference BSI-PP-0035-2007
[ST-BAC] 7301-9302-107 Security Target IDeal Pass v2 SAC/EAC JC ePassport 4.0.0
(BAC configuration) - Morpho
[ST-SAC-EAC] 7301-9301-107 Security Target IDeal Pass v2 SAC/EAC JC ePassport 4.0.0
(SAC/EAC configuration) - Morpho
[TR-02102] TR-02102 Technische Richtlinie Kryptographische Algorithmen und
Schlüssellängen, Version 2013.02, January 9th
2013 by BSI
[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
[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] Technical Guideline TR-03111: Elliptic Curve Cryptography Based on ISO
15946, Version 1.00
Bundesamt für Sicherheit in der Informationstechnik (BSI)