MultiApp v2 Pace SAC Common Criteria / ISO 15408

MultiApp v2 Pace SAC Common Criteria / ISO 15408
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
MultiApp v2 Pace
SAC
Common Criteria / ISO 15408
Security Target – Public version
EAL4+
Copyright Gemalto SA – 2012.
Page : 1/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
CONTENT
1.
ST INTRODUCTION ................................................................................................................................... 4
1.1
ST IDENTIFICATION .................................................................................................................................. 4
1.2
ST OVERVIEW .......................................................................................................................................... 5
1.3
REFERENCES ............................................................................................................................................ 6
1.3.1
External References......................................................................................................................... 6
1.3.2
Internal References ......................................................................................................................... 7
1.4
ACRONYMS AND GLOSSARY ..................................................................................................................... 8
1.5
TOE OVERVIEW..................................................................................................................................... 13
1.5.1
TOE definition ............................................................................................................................... 13
1.5.2
TOE usage and security features for operational use ................................................................... 13
1.5.3
Non-TOE hardware/software/firmware required by the TOE ....................................................... 14
1.6
TOE BOUNDARIES .................................................................................................................................. 14
1.7
TOE INTENDED USAGE ........................................................................................................................... 16
1.8
TOE LIFE-CYCLE .................................................................................................................................... 17
1.8.1
Four phases ................................................................................................................................... 17
1.8.2
Actors ............................................................................................................................................ 18
1.8.3
Init on module at Gemalto site ...................................................................................................... 19
1.8.4
Init on inlay at Gemalto site .......................................................................................................... 20
1.8.5
Init on wafer at Founder site ......................................................................................................... 21
2. CONFORMANCE CLAIMS ..................................................................................................................... 22
2.1
CC CONFORMANCE CLAIM .................................................................................................................... 22
2.2
PP CLAIM, .............................................................................................................................................. 22
2.3
PACKAGE CLAIM .................................................................................................................................... 22
2.4
CONFORMANCE STATEMENT .................................................................................................................. 22
3. SECURITY PROBLEM DEFINITION .................................................................................................... 23
3.1
INTRODUCTION ...................................................................................................................................... 23
3.1.1
Assets ............................................................................................................................................. 23
3.1.2
Subjects ......................................................................................................................................... 23
3.2
ASSUMPTIONS ........................................................................................................................................ 24
3.3
THREATS ................................................................................................................................................ 25
3.4
ORGANIZATIONAL SECURITY POLICIES................................................................................................... 27
4. SECURITY OBJECTIVES ........................................................................................................................ 28
4.1
SECURITY OBJECTIVES FOR THE TOE .................................................................................................... 28
4.2
SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ............................................................. 29
5. EXTENDED COMPONENTS DEFINITION .......................................................................................... 31
5.1
DEFINITION OF THE FAMILY FAU_SAS.................................................................................................. 31
5.1.1
Definition of the Family FCS_RND .............................................................................................. 31
5.1.2
Definition of the Family FMT_LIM ............................................................................................... 32
5.1.3
Definition of the Family FPT_EMSEC.......................................................................................... 33
6. SECURITY REQUIREMENTS................................................................................................................. 35
6.1
SECURITY FUNCTIONAL REQUIREMENTS FOR THE TOE ......................................................................... 35
6.1.1
Class FAU Security Audit.............................................................................................................. 35
6.1.2
Class Cryptographic Support (FCS) ............................................................................................. 35
6.1.3
Class FIA Identification and Authentication ................................................................................. 37
6.1.4
Class FDP User Data Protection .................................................................................................. 39
6.1.5
Class FMT Security Management ................................................................................................. 41
6.1.6
Class FPT Protection of the Security Functions ........................................................................... 43
6.2
SECURITY ASSURANCE REQUIREMENTS FOR THE TOE .......................................................................... 45
7. TOE SUMMARY SPECIFICATION........................................................................................................ 46
7.1
TOE SECURITY FUNCTIONS ................................................................................................................... 46
7.1.1
TSFs provided by the MultiApp V2 PACE Software ..................................................................... 46
7.1.1.1
7.1.1.2
SF.REL: Reliability ................................................................................................................................... 46
SF.AC: Access Control .............................................................................................................................. 47
Copyright Gemalto SA – 2012.
Page : 2/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
7.1.1.3
7.1.1.4
7.1.2
SF.SYM_AUT: Symmetric Authentication Mechanisms .......................................................................... 48
SF.SM: Secure Messaging ......................................................................................................................... 49
TSFs provided by the Infineon chip ............................................................................................... 50
FIGURES
Figure 1: TOE Boundaries ....................................................................................................................................................... 15
Figure 2: LC1: Init on module at Gemalto site ......................................................................................................................... 19
Figure 3: LC1bis: Init on inlay at Gemalto site ........................................................................................................................ 20
Figure 4: LC2 Init on wafer at Founder site ............................................................................................................................. 21
Figure 5: Manufacturer key ...................................................................................................................................................... 48
TABLES
Table 1: Card Production Life Cycle Data ................................................................................................................................. 5
Table 2: Identification of the actors.......................................................................................................................................... 18
Table 3: FIA_AFL.1 refinement ............................................................................................................................................... 39
Table 4: Security Functions provided by the MultiApp V2 PACE Software. .......................................................................... 46
Table 5: Correspondence between TOE ES life cycle states and life cycle phases. ................................................................. 47
Table 6: SF provided by the IFX chips .................................................................................................................................... 50
Copyright Gemalto SA – 2012.
Page : 3/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
1. ST INTRODUCTION
1.1 ST IDENTIFICATION
Title:
MultiApp V2 PACE - SAC public Security Target
Version:
v1.1 issued 30 January 2012
ST reference:
ST_D1250513
Origin:
Gemalto
Author:
Antoine DE LAVERNETTE
Product identification:
MultiApp V2 PACE
Security Controllers:
IFX SLE66CLX1440PE m2091 a13
TOE identification:
eTravel SAC/EAC v1.3 on MultiApp V2 PACE
TOE documentation:
Operational User Guidance [OPE_MRTD]
Preparative procedures [PRE_MRTD]
The TOE identification is provided by the Card Production Life Cycle Data (CPLCD) of the TOE,
located in OTP and in EEPROM. These data are available by executing a dedicated command.
The TOE and the product differ, as further explained in §1.6 TOE boundaries:
 The TOE is the eTravel SAC/EAC v1.3 on MultiApp V2 PACE
 The MultiApp V2 PACE product also includes 2 applets in ROM.
CPLC field
Length
Value
IC Fabricator
2
IFX
IC Type
2
SLE66CLX1440PE
Operating System Identifier
2
n.a.
Operating System release date
2
n.a.
Operating System release level
2
n.a.
IC Fabrication Date
2
n.a.
IC Serial Number
4
Unique identification of the chip written by
the ICC Manufacturer
IC Batch Identifier
2
n.a.
IC Module Fabricator
2
n.a.
IC Module Packaging Date
2
n.a.
ICC Manufacturer
2
‘Gemalto’
IC Embedding Date
2
n.a.
IC Pre-personalizer
2
‘Gemalto’
IC Pre-personalization Date
2
n.a.
Copyright Gemalto SA – 2012.
Page : 4/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
CPLC field
Length
Value
IC Pre-personalization Eqiopment
Identifier
4
n.a.
IC Personalizer
2
n.a.
IC Personalization Date
2
n.a.
IC Personalization Equipment Identifier
4
n.a.
Table 1: Card Production Life Cycle Data
IT Security Evaluation scheme
IT
Security
Certification
scheme
Serma Technologies
Agence Nationale de la Sécurité des Systèmes d’Information
(ANSSI)
1.2 ST OVERVIEW
The ST is based on Protection Profile Machine Readable Travel Document SAC (PACE V2)
Supplemental Access Control [PP-MRTD-SAC].
The Target of Evaluation (TOE) is the contactless integrated circuit chip of machine readable travel
documents (MRTD’s chip) based on the requirements of the International Civil Aviation Organization
(ICAO). More specifically the TOE consists of operating system of MRTD’s chip with ICAO application.
The TOE is programmed according to Logical Data Structure as defined in [ICAO-9303].
This Security Target defines the security requirements for the TOE. The main security objective is to
provide the secure enforcing functions and mechanisms to maintain the integrity and confidentiality of
the MRTD application and data during its life cycle.
The main objectives of this ST are:
 To introduce TOE and the MRTD application,
 To define the scope of the TOE and its security features,
 To describe the security environment of the TOE, including the assets to be protected
and the threats to be countered by the TOE and its environment during the product
development, production and usage.
 To describe the security objectives of the TOE and its environment supporting in terms
of integrity and confidentiality of application data and programs and of protection of the
TOE.
 To specify the security requirements which includes the TOE security functional
requirements, the TOE assurance requirements and TOE security functions.
Copyright Gemalto SA – 2012.
Page : 5/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
1.3 REFERENCES
1.3.1 External References
[ASM-EAC]
Technical Guideline – Advanced Security Mechanisms for Machine Readable Travel
Documents – Extended Access Control (EAC),
Version 1.0, TR-03110
[BIO]
BIOMETRICS DEPLOYMENT OF MACHINE READABLE TRAVEL DOCUMENTS,
Technical Report, Development and Specification of Globally Interoperable Biometric
Standards for Machine Assisted Identity Confirmation using Machine Readable
Travel Documents,
Version 2.0, ICAO TAG MRTD/NTWG, 21 May 2004
[CC-1]
Common Criteria for Information Technology Security Evaluation
Part 1: Introduction and general model,
CCMB-2006-09-001, version 3.1 rev 3, July 2009
[CC-2]
Common Criteria for Information Technology Security Evaluation
Part 2: Security functional components,
CCMB-2007-09-002, version 3.1 rev 3, July 2009
[CC-3]
Common Criteria for Information Technology Security Evaluation
Part 3: Security assurance components,
CCMB-2007-09-003, version 3.1 rev 3, July 2009
[CEM]
Common Methodology for Information Technology Security Evaluation
Methodology
CCMB-2007-09-004, version 3.1 rev 3, July 2009
[ST-IC]
[ST-IC-1440]
[ST-IC-1440]
ST of IFX SLE66CLX1440PE(M) and derivates - Version 1.2 – 2008–09-19
[CR-IC]
[CR-IC-1440]
[CR-IC-1440]
Certification Report, BSI-DSZ-CC-0523-2008-MA-1 (09-06-2009)
SLE66CLX1440PE(M) / m2090 - a13
[FIPS180-2]
Federal Information Processing Standards Publication 180-2 SECURE HASH
STANDARD (+Change Notice to include SHA-224),
U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology,
2002 August 1
[FIPS46-3]
Federal Information Processing Standards Publication FIPS PUB 46-3, DATA
ENCRYPTION STANDARD (DES),
U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology,
Reaffirmed 1999 October 25
[ISO15946-1]
ISO/IEC 15946: Information technology – Security techniques – Cryptographic
techniques based on elliptic curves – Part 1: General,
2002
[ISO15946-2]
ISO/IEC 15946: Information technology – Security techniques – Cryptographic
techniques based on elliptic curves – Part 2: Digital Signatures,
2002
Copyright Gemalto SA – 2012.
Page : 6/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
[ISO15946-3]
ISO/IEC 15946: Information technology – Security techniques – Cryptographic
techniques based on elliptic curves – Part 3: Key establishment,
2002
[ISO7816]
ISO 7816, Identification cards – Integrated circuit(s) cards with contacts, Part 4:
Organization, security and commands for interchange, FDIS2004
[ISO9796-2]
ISO/IEC 9797: Information technology – Security techniques – Digital Signature
Schemes giving message recovery – Part 2: Integer factorisation based mechanisms,
2002
[ISO9797-1]
ISO/IEC 9797: Information technology – Security techniques – Message Authentication
Codes (MACs) – Part 1: Mechanisms using a block cipher,
1999
[ICAO-9303]
9303 Part 3 Vol 2 – ICAO Machine Readable Travel Document Third edition 2008
[ICAO-TR-SAC]
ICAO TR –Supplemental Access Control for Machine Readable Travel Documents,
Version 1.00, March 23, 2010
[PKCS#3]
PKCS #3: Diffie-Hellman Key-Agreement Standard,
An RSA Laboratories Technical Note,
Version 1.4, Revised November 1, 1993
[PKI]
MRTD Technical Report, PKI for Machine Readable Travel Documents Offering ICC
Read-Only Access
International Civil Aviation Organization
Version 1.1, October 01 2004
[PP-IC-0002]
Smartcard IC Platform protection Profile
BSI-PP-0002, version 1.0, July 2001
[PP-IC-0035]
Smartcard IC Platform protection Profile
BSI-PP-0035
[PP-MRTD-BAC]
Common Criteria Protection Profile - Machine Readable Travel Document with ICAO
Application, Basic Access Control
Bundesamt für Sicherheit in der Informationstechnik
th
BSI-PP-0055, version 1.10, 25 March 2009
[PP-MRTD-EAC]
Common Criteria Protection Profile – Machine Readable Travel Document with “ICAO
Application”, Extended Access Control
Bundesamt für Sicherheit in der Informationstechnik
th
BSI-PP-0056, Version 1.10, 25 March 2009
[PP-MRTD-SAC]
Protection Profile – Machine Readable Travel Document SAC (PACE V2)
Supplemental Access Control
rd
ANSSI-CC-PP-2010/06, Version 1.0, 03 October 2010
[SS]
ANNEX to Section III SECURITY STANDARDS FOR MACHINE READABLE
TRAVEL DOCUMENTS,
Excerpts from ICAO Doc 9303, Part 1
Machine Readable Passports, Fifth Edition – 2003
[TR-ECC]
Elliptic Curve Cryptography according to ISO 15946,
Technical Guideline, TR-ECC,
BSI, 2006
[GP211]
Global Platform Card Specification v 2.1.1 - March 2003
1.3.2 Internal References
[IGS]
Installation, Generation and Start Up Procedures
[PRE_MRTD]
D1144772 Preparative procedures - MultiApp V2 PACE MRTD CYLLENE2
Copyright Gemalto SA – 2012.
Page : 7/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
[OPE_MRTD]
D1144771 Operational User Guidance - MultiApp V2 PACE MRTD CYLLENE2
1.4 ACRONYMS AND GLOSSARY
Acr.
Term
Definition
AA
Active
Security mechanism defined in [PKI] option by which means the MTRD’s
Authentication 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
Optional informative part of the PP containing additional supporting
note
[PP- information that is considered relevant or useful for the construction,
MRTD-EAC] 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
BAC
Basic Access Security mechanism defined in [PKI] by which means the MTRD’s chip
Control
proves and the inspection system protect their communication by means of
secure messaging with Basic Access Keys (see there).
CAN
Card
Access Password derived from a short number printed on the front side of the
Number
datapage.
SAC
Supplemental Security mechanism defined in [ICAO-TR-SAC] by which means the MTRD’s
Access Control chip proves and the inspection system protect their communication by
means of secure messaging with Supplemental Access Keys (see there).
BIS
Basic
Inspection
System
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 (biodata)
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. [SS]
Biometric
Data stored for biometric authentication of the MRTD holder in the MRTD’s
Reference Data chip as (i) digital portrait and (ii) optional biometric reference data.
Counterfeit
An unauthorized copy or reproduction of a genuine security document made
by whatever means. [SS]
CSCA Country
Signing
Certification
Authority
CPLCD Card
Production Life
Cycle Data
Self-signed certificate of the Country Signing CA Public Key (KPuCSCA)
issued by CSCA stored in the inspection system.
CVCA Country
Verifying
Certification
Authority
The Country Verifying Certification Authority enforces the privacy policy of
the issuing Country or Organization with respect to the protection of
sensitive biometric reference data stored in the MRTD. The CVCA
represents the country specific root of the PKI of Inspection Systems.
Copyright Gemalto SA – 2012.
The TOE identification is provided by the Card Production Life Cycle Data
(CPLCD) of the TOE, located in OTP and in EEPROM. These data are
available by executing a dedicated command
Page : 8/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
DH
Diffie-Hellman Algorithm for Chip Authentication protocol
Key Agreement
Algorithm
DV
Document
Verifier
The Document Verifier enforces the privacy policy of the receiving Country
with respect to the protection of sensitive biometric reference data to be
handled by the Extended Inspection Systems. The DV manages the
authorization of the Extended Inspection Systems for the sensitive data of
the MRTD in the limits provided by the Issuing State or Organization in form
EC-DH Elliptic
Curve Algorithm
for ChipVerifier
Authentication
protocol
of the Document
Certificates.
Diffie-Hellman
Key Agreement
Algorithm
SOD
Document
Pair of symmetric Triple-DES keys used for secure messaging with
Basic Access encryption (key KENC) and message authentication (key KMAC) of data
Keys
transmitted between the MRTD’s chip and the inspection system [PKI]. 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
A RFC3369 CMS Signed Data Structure, signed by the Document Signer
Security Object (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). [PKI]
Eavesdropper
A threat agent with moderate attack
potential reading the communication
between the MRTD’s chip and the inspection system to gain the data on the
MRTD’s chip.
Enrolment
EAC
EIS
GIS
The process of collecting biometric samples from a person and the
subsequent preparation and storage of biometric reference templates
representing that person's identity. [BIO]
Extended
Security mechanism identified in [PKI] by which means the MTRD’s chip (i)
Access Control 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
Extended
The
EIS in addition
to the General
Inspection
SystemPrivate
(GIS) Key
(i) implements
themselves
with Personalization
Agent
Authentication
and to get
Inspection
the
Protocol
and and
(ii) TSF
is authorized
by the issuing
writeTerminal
and readAuthentication
access to the logical
MRTD
data.
System
State or Organization through the Document Verifier of the receiving State to
read the sensitive biometric reference data.
Forgery
Fraudulent alteration of any part of the genuine document, e.g. changes to
the biographical data or the portrait. [SS]
General
Inspection
System
Global
Interoperability
The GIS is a Basic Inspection System (BIS) which implements additional the
Chip Authentication Mechanism.
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 eyereadable
readable data
in all MRTDs.
IC
Dedicated That
partand
of machine
the IC Dedicated
Software
(refer to[BIO]
above) which provides
Support
functions after TOE Delivery. The usage of parts of the IC Dedicated
Software
Software might be restricted to certain phases.
IC
Dedicated That part of the IC Dedicated Software (refer to above) which is used to test
Test Software the TOE before TOE Delivery but which does not provide any functionality
thereafter.
Copyright Gemalto SA – 2012.
Page : 9/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
Impostor
Improperly
Documented
person
Initialisation
Data
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. [SS]
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. [BIO]
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. [BIO]
IS
Inspection
system
A technical system used by the border control officer of the receiving State
(i) examining an MRTD presented by the traveller and verifying its
authenticity and (ii) verifying the traveller as MRTD holder.
IC
Integrated
circuit
Electronic component(s) designed to perform processing
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]
LDS
and/or
Logical
Data The collection of groupings of Data Elements stored in the optional capacity
Structure
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
(LDS) as specified by ICAO on the contactless integrated circuit. It presents
contactless readable data including (but not limited to) personal data of the
MRTD holder (1) the digital Machine Readable Zone Data (digital MRZ data,
EF.DG1), (2) the digitized portraits (EF.DG2), (3) the biometric reference
data of finger(s) (EF.DG3) or iris image(s) (EF.DG4) or both and (4) the
Logical travel Data
accordingtoto
the(EF.DG5
Logical Data
Structure as specified by ICAO in
other stored
data according
LDS
to EF.DG16).
document
the contactless integrated circuit including (but not limited to) (1) data
contained in the machine-readable zone (mandatory), (2) digitized
photographic image (mandatory) and (3) fingerprint image(s) and/or iris
image(s)document
(optional).issued by a State or Organization which is used by the
MRTD Machine
Official
readable travel holder for international travel (e.g. passport, visa, official document of identity)
document
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]
MRV
Machine
A visa or, where appropriate, an entry clearance (hereinafter collectively
readable visa 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
MRZ
Machine
Fixed
located
front of the
MRTD or MRP Data Page
which dimensional
is attached toarea
a visa
pageon
in the
a passport.
[ICAO-9303]
Readable Zone 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]
Copyright Gemalto SA – 2012.
Page : 10/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
Machineverifiable
biometrics
feature
MRTD
administrator
MRTD
application
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. [SS]
The Issuing State or Organization which is allowed to perform administrative
commands (update data of the MRTD application, invalidation of the
application) in the phase 4 Operational Use.
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 EF.DG1 to EF.DG14 and EF.DG16),
- the TSF Data including the definition the authentication data but except the
authentication data itself.
MRTD
Basic Mutual authentication protocol followed by secure messaging between the
Access Control 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 integrated circuit chip complying with ISO/IEC 14443 and
ICAOT, [10], p. 14. programmed according to the Logical Data Structure as
specified by ICAOT, [10], p. 14.
MRTD’s
chip Software embedded in a MRTD’s chip and not being developed by the IC
Embedded
Designer. The MRTD’s chip Embedded Software is designed in Phase 1 and
Software
embedded into the MRTD’s chip in Phase 2 of the TOE life-cycle.
Optional
Data stored for biometric authentication of the MRTD holder in the MRTD’s
biometric
chip as (i) encoded finger image(s) (EF.DG3) or (ii) encoded iris image(s)
reference data (EF.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
verification of the digital signature of the Document Security Object
authentication
comparison 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. [SS]
Personalization The agent acting on the behalf of the issuing State or organisation to
Agent
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
for the holder. proof and verification of the
Personalization TSF
data
used MRTD
for authentication
Agent
Personalization Agent.
Authentication
Information
Personalization Symmetric cryptographic key used (i) by the Personalization Agent to prove
Agent
their identity and get access to the logical MRTD according to the SFR
Authentication FIA_UAU.4/BT FIA_UAU.6/BT and FIA_API.1/SYM_PT and (ii) by the
Key
MRTD’s chip to verify the authentication attempt of a terminal as
Personalization Agent according to the SFR FIA_UAU.4/MRTD,
FIA_UAU.5/MRTD and FIA_UAU.6/MRTD.
Copyright Gemalto SA – 2012.
Page : 11/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
Physical travel Travel document in form of paper, plastic and chip using secure printing to
document
present data including (but not limited to):
biographical data,
data of the machine-readable zone,
photographic image and
other data.
preAny data that is injected into the non-volatile memory of the TOE by the MRTD
personalization Manufacturer (Phase 2) for traceability of non-personalized MRTD’s and/or
Data
to secure shipment within or between life cycle phases 2 and 3. It contains
(but is not limited to) the Personalization Agent Key Pair.
pre
– MRTD’s chip equipped with pre-personalization data.
personalized
MRTD’s chip
PIS
Primary
Inspection
System
A inspection system that contains a terminal for the contactless
communication with the MRTD’s chip and does not implement the terminals
part of the Basic Access Control Mechanism.
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. [SS]
secure
messaging
encrypted
mode
Skimming
Secure messaging using encryption and message authentication code
in according to ISO/IEC 7816-4
travel
document
traveler
TSF data
Imitation of the inspection system to read the logical MRTD or parts of it via
the contactless communication channel of the TOE without knowledge of the
printed MRZ data.
A passport or other official document of identity issued by a State or
organization, which may be used by the rightful holder for international
travel. [BIO]
Person presenting the MRTD to the inspection system and claiming the
identity of the MRTD holder.
Data created by and for the TOE, that might affect the operation of the TOE
(CC part 1 [1 ]).
Unpersonalized MRTD material prepared to produce an personalized MRTD containing an
MRTD
initialised 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 [1 ]).
Verification
The process of comparing a submitted biometric sample against the
biometric reference template of a single enrolee whose identity is being
claimed, to determine whether it matches the enrolee’s template. [BIO]
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.
Copyright Gemalto SA – 2012.
Page : 12/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
1.5 TOE OVERVIEW
This Security Target defines the security objectives and requirements for the contactless 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 methods PACE V2
Access Control specified in [ICAO-TR-SAC]. PACE V2 will replace BAC access control. In this
transition period, and for legacy reasons, MultiApp V2 PACE also supports BAC when it is connected
to a BIS.
1.5.1 TOE definition
The Target of Evaluation (TOE) is the contactless integrated circuit chip of machine readable travel
documents (MRTD’s chip) programmed according to the Logical Data Structure (LDS) [ICAO-9303]
and providing the Basic Access Control - BAC, the Supplemental Access Control - SAC, and Extended
Access Control – EAC, according to the ‘ICAO Doc 9303’ [ICAO-9303], ‘ICAO TR SAC’ [ICAO-TRSAC], and BSI TR-03110 [ASM-EAC], respectively.
The TOE comprises
 the circuitry of the MRTD’s chip (the integrated circuit, IC),
 the IC Dedicated Software with the parts IC Dedicated Test Software and IC Dedicated
Support Software,
 the IC Embedded Software (operating system),
 the MRTD application and
 the associated guidance documentation.
1.5.2 TOE usage and security features for operational use
A State or Organization issues MRTDs to be used by the holder for international travel. The traveler
presents an 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), (iii) the CAN for visual and machine reading using OCR methods on
the data page and (iv) data elements on the MRTD’s chip according to LDS for 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 a genuine MRTD of an issuing State or Organization.
As an alternative to the MRZ or the CAN, this ST allows the use of the PIN as a password for the
PACE V2 mechanism. In this case the IS invites the traveler to securely enter his PIN.
For this security target the MRTD is viewed as unit of
(a) the physical MRTD as travel document in form of paper, plastic and chip. It presents visual
readable data including (but not limited to) personal data of the MRTD holder
(1) the biographical data on the biographical data page of the passport book,
(2) the printed data in the Machine Readable Zone (MRZ) and
(3) the printed portrait.
(b) the logical MRTD as 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
(1) the digital Machine Readable Zone Data (digital MRZ data, EF.DG1),
(2) the digitized portraits (EF.DG2),
1
(3) the biometric reference data of finger(s) (EF.DG3) or iris image(s) (EF.DG4) or both
(4) the other data according to LDS (EF.DG5 to EF.DG16) and
(5) the Document security object.
1
These additional biometric reference data are optional
Copyright Gemalto SA – 2012.
Page : 13/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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 access control, Active
Authentication of the MRTD’s chip, and the Data Encryption of additional sensitive biometrics as
optional security measure in the ICAO Doc 9303 [ICAO-9303]. The Passive Authentication Mechanism
and the Data Encryption are performed completely and independently of the TOE by the TOE
environment. The ICAO defines the advanced security method PACE V2 access control to the logical
MRTD in [ICAI-TR-SAC]
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 PACE V2 access control
mechanism. The PACE V2 access control mechanism will replace the BAC access control
mechanism. It offers a higher security level as explained in [ICAO-TR-SAC]. This security target does
not address the Active Authentication and the Extended Access Control. They are optional security
mechanisms.
The PACE V2 access control is a security feature which is mandatory in the TOE. The inspection
system (i) reads optically the MRTD or the CAN, or let the traveler enter his PIN, (ii) authenticates itself
as inspection system by means of Document PACE V2 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-TR-SAC].
1.5.3 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.
1.6 TOE BOUNDARIES
Application note: The TOE is the module designed to be the core of an MRTD passport. The TOE is a
contactless integrated circuit. The TOE is connected to an antenna and capacitors and is mounted on
a plastic film. This inlay is then embedded in the coversheet or datapage of the MRTD passport and
provides a contactless interface for the passport holder identification.
The Target of Evaluation (TOE) is the contactless integrated circuit chip of machine readable travel
documents (MRTD’s chip) programmed according to the Logical Data Structure [ICAO-TR-SAC] and
[ASM-EAC] and providing:
 the Basic Access Control (BAC) according to the ICAO document [PKI]
 the PACE V2 Access Control (SAC) according to the ICAO document [ICAO-TR-SAC]
 the Extended Access Control according to the BSI document [ASM]
Application note: Additionally to the [PP-MRTD-SAC], the TOE has a set of administrative commands
for the management of the product during the product life.
The TOE comprises of:
 the circuitry of the MRTD’s chip (the integrated circuit, IC),
Copyright Gemalto SA – 2012.
Page : 14/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET




the IC Dedicated Software with the parts IC Dedicated Test Software and IC Dedicated
Support Software,
the IC Embedded Software (operating system),
the MRTD application, and
the associated guidance documentation.
Application note: Components within the TOE boundary are refined in the following manner:
 the Integrated Circuit (IC),
 the IC Dedicated Test Software,
 the IC Dedicated Support Software (Boot Rom Software, Mifare Operating System),
 the eTravel EAC on MultiApp V2 PACE Embedded Software (ES),
 the NVM Embedded Software,
 part of the MRTD Logical Data Structure,
 the guidance documentation of the eTravel EAC on MultiApp V2 PACE product:
o the preparation guide (assurance family AGD-PRE),
o the operational guide (assurance family AGD-OPE).
The eTravel EAC on MultiApp V2 PACE Embedded Software (ES) is implemented in the ROM of the
chip. This ES provides mechanisms to load executable code into the non-volatile-memory of the chip
(EEPROM). These mechanisms are included in the TOE and are part of the evaluation.
The TOE is delivered to the Personalization Agent with data and guidance documentation in order to
perform the personalization of the product. In addition the Personalization Key is delivered from the
MRTD Manufacturer to the Personalization Agent or from the Personalization Agent to the MRTD
Manufacturer.
Applet
IAS Classic
Applet
MPCOS
Legend
Non-TSF
TOE boundary
eTravel SAC
Native Application
eTravel EAC
Native Application
TSF
Applications
JavaCard API
Java
API
JCRE
VM
OPEN
Object
Deletion
Logical
Channels
Installer
Exernal
Memory
RMI
Applet
Deletion
Manager
Card
Factory
ICAO NAX interface
Memory Manager
Communication
Cryptography
JKernel
HAL API
RESET
MEM
COM
SEC
CRY
IC
Hardware
Figure 1: TOE Boundaries
Copyright Gemalto SA – 2012.
Drivers
Page : 15/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
1.7 TOE INTENDED USAGE
State or organization issues MRTD to be used by the holder for international travel. The traveler
presents a MRTD to the inspection system to prove his or her identity.
The MRTD in context of this security target contains:
 visual (eye readable) biographical data and portrait of the holder,
 a separate data summary (MRZ data) for visual and machine reading using OCR methods in
the Machine readable zone (MRZ),
 data elements on the MRTD’s chip according to [ICAO-9303] for contactless machine reading.
The authentication of the traveler is based on the possession of a valid MRTD personalized for a
holder with the claimed identity as given on the biographical data page and 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 a genuine MRTD of an issuing State or
Organization.
For this security target the MRTD is viewed as unit of:
 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:
o the biographical data on the biographical data page of the passport book,
o the printed data in the Machine-Readable Zone (MRZ),
o the printed portrait.
 the logical MRTD as 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:
o the digital Machine Readable Zone Data (digital MRZ data, EF.DG1),
o the digitized portraits (EF.DG2),
o the optional biometric reference data of finger(s) (EF.DG3) or iris image(s) (EF.DG4)
,
or both
o the other data according to LDS (EF.DG5 to EF.DG16),
o the Document Security Object (SOD).
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) [SS]. These security measures include the
binding of the MRTD’s chip to the passport book.
This ST assumes that the issuing State or Organization uses EF.DG3 and/or EF.DG4 and protects
these data by means of Extended Access Control.
Copyright Gemalto SA – 2012.
Page : 16/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
1.8 TOE LIFE-CYCLE
1.8.1 Four phases
The TOE life cycle is described in terms of the four life cycle phases. With respect to [PP-BSI-0035],
the TOE life cycle is additionally subdivided into 7 steps.
Phase 1 “Development”:
(Step1) The TOE is developed in phase 1. The IC developer develops the integrated circuit, the IC
Dedicated Software and the guidance documentation associated with these TOE components.
(Step2) The Embedded Software developer uses the guidance documentation for the integrated circuit
and the guidance documentation for relevant parts of the IC Dedicated Software and develops the IC
Embedded Software (operating system), the MRTD application and the guidance documentation
associated with these TOE components.
The manufacturing documentation of the IC including the IC Dedicated Software and the IC Embedded
Software (operating system) is securely delivered to the IC manufacturer. The IC Embedded Software
in the nonvolatile programmable memories, the MRTD application and the guidance documentation is
securely delivered to the MRTD manufacturer.
Phase 2 “Manufacturing”:
(Step3) In a first step the TOE integrated circuit is produced containing the MRTD’s chip Dedicated
Software and the parts of the MRTD’s chip Embedded Software loaded by the IC manufacturer. The IC
manufacturer writes the IC Identification Data onto the chip to control the IC as MRTD material during
the IC manufacturing and the delivery process to the MRTD manufacturer. The IC is securely delivered
from the IC manufacturer to the MRTD manufacturer.
(Step4) The MRTD manufacturer combines the IC with hardware for the physical interface in the
passport book. This step includes the loading of the soft mask in the EEPROM.
(Step5) The MRTD manufacturer (i) creates the MRTD application and (ii) equips MRTD’s chips with
pre-personalization Data.
Creation of the application implies the creation of MF and ICAO.DF.
The pre-personalized MRTD together with the IC Identifier is securely delivered from the MRTD
manufacturer to the Personalization Agent. The MRTD manufacturer also provides the relevant parts
of the guidance documentation to the Personalization Agent.
Phase 3 “Personalization of the MRTD”:
(Step6) The personalization of the MRTD includes (i) the survey of the MRTD holder’s biographical
data, (ii) the enrolment of the MRTD holder’s biometric reference data (i.e. the digitized portraits and
the optional biometric reference data), (iii) the printing of the visual readable data onto the physical
MRTD, (iv) the writing of the TOE User Data and TSF Data into the logical MRTD, and (v)
configuration of the TSF if necessary.
The step (iv) is performed by the Personalization Agent and includes but is not limited to the creation of
(i) the digital MRZ data (EF.DG1), (ii) the digitized portrait (EF.DG2), and (iii) the Document security
object (SOD).
The signing of the Document security object by the document signer [PKI] finalizes the personalization
of the genuine MRTD for the MRTD holder. The personalized MRTD (together with appropriate
guidance for TOE use if necessary) is handed over to the MRTD holder for operational use.
Application note: The TSF data (data for the operation of the TOE upon which the enforcement of the
SFR relies cf [CC-1] §97) comprise (but are not limited to) the personalization authentication keys and
the PACE V2 authentication control key. TSF data also include the source code.
Copyright Gemalto SA – 2012.
Page : 17/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
Application note: 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].
Phase 4 “Operational Use”
(Step7) 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 or
organization but they can never be modified.
Application note: In this ST, the role of the Personalization Agents is strictly limited to the phase 3
Personalization. In the phase 4 Operational Use updating and addition of the data groups of the MRTD
application is forbidden.
1.8.2 Actors
Actors
Integrated Circuit (IC) Developer
Embedded Software Developer
Integrated Circuit (IC) Manufacturer
Initializer
Pre-personalizer
Inlay manufacturer
Book manufacturer
Personalization Agent
Identification
IFX
Gemalto
IFX
Gemalto or IFX
Gemalto or IFX
Gemalto or another Inlay manufacturer
Gemalto or another printer
The agent who is acting on the behalf of the issuing
State or Organization and personalize the MRTD for the
holder by activities establishing the identity of the holder
with biographic data.
MRTD Holder
The rightful holder of the MRTD for whom the issuing
State or Organization personalizes the MRTD.
Table 2: Identification of the actors
Copyright Gemalto SA – 2012.
Page : 18/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
1.8.3 Init on module at Gemalto site
Sites
Phase 1
Development
Step 1
Step 2
Embedded Software
Development
IC design and dedicated
software development
Development sites
Step 3
TOE under construction
Secured by Environment
Integration
Photomask fabrication
Phase 2
Manufacturing
IC manufacturing
Step 4
IC initialization
Inluding soft mask loading
Step 5
IC pre-personalization including
File System Creation part1
Inlay manufacturing
IC manufacturer
MRTD manufacturer
Inlay manufacturer
Inlay manufacturing
Phase 3
Personalization
Step 6
TOE operational
Secured by TOE
Personalization including
File System Creation part 2 and
Book manufacturing
Phase 4
Usage
Step 7
Usage
Personalizer
Holder = End User
End of life
Figure 2: LC1: Init on module at Gemalto site
Figure 2: LC1: Init on module at Gemalto site describes the standard Life Cycle.
The module is manufactured at the founder site. It is then shipped to Gemalto site where it is initialized
and pre-personalized and then shipped to the Personalizer directly or after through the Inlay
manufacturer.
During the shipment from Gemalto to the Personalizer, the module is protected by a diversified key.
Copyright Gemalto SA – 2012.
Page : 19/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
1.8.4 Init on inlay at Gemalto site
Sites
Phase 1
Development
Step 1
Step 2
Embedded Software
Development
IC design and dedicated
software development
Development sites
Step 3
Integration
TOE under construction
Secured by Environment
Photomask fabrication
Phase 2
Manufacturing
IC manufacturing
IC manufacturer
Inlay manufacturing
Step 4
Inlay initialization
Inluding soft mask loading
MRTD module manufacturer
Step 5
Phase 3
Personalization
Step 6
Inlay pre-personalization including
File System Creation
Personalization including
book manufacturing
TOE operational
Secured by TOE
Personalizer
Phase 4
Usage
Step 7
Usage
End of life
User
Figure 3: LC1bis: Init on inlay at Gemalto site
LC1 bis is a small alternative to LC1.
Figure 3: LC1bis: Init on inlay at Gemalto site describes the Life Cycle when the Gemalto manufactures
the inlays before the initialization.
The module is manufactured at the founder site. It is then shipped to Gemalto site where the inlay is
manufactured. The inlay is initialized and pre-personalized and then shipped to the Personalizer.
During the shipment from Gemalto to the Personalizer, the module is protected by a diversified key.
Copyright Gemalto SA – 2012.
Page : 20/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
1.8.5 Init on wafer at Founder site
Sites
Phase 1
Development
Step 1
Step 2
Embedded Software
Development
IC design and dedicated
software development
Development sites
Step 3
Integration
TOE under construction
Secured by Environment
Photomask fabrication
Phase 2
Manufacturing
IC manufacturing
Step 4
IC initialization
Inluding soft mask loading
IC manufacturer
Step 5
IC pre-personalization including
File System Creation
Inlay manufacturing
Inlay manufacturer
Inlay manufacturing
TOE operational
Secured by TOE
Phase 3
Personalization
Phase 4
Usage
Step 6
Personalization including
book manufacturing
Step 7
Usage
Personalizer
User
End of life
Figure 4: LC2 Init on wafer at Founder site
Figure 4: LC2 Init on wafer at Founder site describes the Life Cycle when the customer whishes to
receive wafers directly from the founder. In this case, initialization and pre-personalization, which
include sensitive operations such as the loading of patches, take place at the founder site. The
creation of files is started by the founder and completed by the personalizer.
During the shipment from the founder to the Personalizer, the module is protected by a diversified key.
Copyright Gemalto SA – 2012.
Page : 21/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
2. CONFORMANCE CLAIMS
2.1 CC CONFORMANCE CLAIM
This security target claims conformance to
 Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
General Model; CCMB-2009-07-001, version 3.1 rev 3, July 2009 [CC-1]
 Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
Components; CCMB-2009-07-002, version 3.1 rev 3, July 2009 [CC-2]
 Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
Requirements; CCMB-2009-07-003, version 3.1 rev 3, July 2009 [CC-3]
as follows
 Part 2 extended,
 Part 3 conformant.
The

Common Methodology for Information Technology Security Evaluation, Evaluation
Methodology; CCMB-2009-07-004, version 3.1 rev 3, July 2009, [CEM] has to be taken into
account.
2.2 PP CLAIM,
The MultiApp V2 PACE SAC security target claims strict conformance to the Protection Profile
“Machine Readable Travel Document with SAC (PACE V2) Supplemental Access Control ANSSI-CCrd
PP-2010/06, Version 1.0, 03 October 2010 ([PP-MRTD-SAC]).
The TOE also claims conformance to other Protection Profiles. This is described in other Security
Targets:
The MultiApp V2 PACE EAC security target claims strict conformance to the Protection Profile
“Machine Readable Travel Document with ICAO Application, Extended Access Control” BSI-PP-0056
version 1.10 ([PP-MRTD-EAC]).
The MultiApp V2 PACE BAC security target claims demonstrable conformance to the Protection Profile
“Machine Readable Travel Document with ICAO Application, Basic Access Control” BSI-PP-0055
version 1.10 ([PP-MRTD-BAC]).
2.3 PACKAGE CLAIM
This ST is conforming to assurance package EAL4 augmented with ALC_DVS.2 and AVA_VAN.5
defined in CC part 3 [CC-3].
2.4 CONFORMANCE STATEMENT
This ST strictly conforms to [PP-MRTD-SAC].
Copyright Gemalto SA – 2012.
Page : 22/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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, EF.DG1 to EF.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 Chip Authentication Public Key
(EF.DG 14) is used by the inspection system for the Chip Authentication. The EF.SOD is used by the
inspection system for Passive Authentication of the logical MRTD.
The TOE described in this security target specifies only the PACE V2 mechanisms with resistance
against high attack potential granting access to:
 Logical MRTD standard User Data (i.e. Personal Data) of the MRTD holder (EF.DG1, EF.DG2,
EF.DG5 to EF.DG13, EF.DG16),
 Chip Authentication Public Key in EF.DG14,
 Active Authentication Public Key in EF.DG15,
 Document Security Object (SOD) in EF.SOD,
 Common data in EF.COM.
The TOE prevents read access to sensitive User Data
2
 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 prove his possession of a genuine MRTD.
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 behalf of the issuing State or Organization to personalize the MRTD for the
holder by some or all of the following activities: (i) establishing the identity of 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 static keys and (v) signing the Document Security Object defined
in [ICAO-9303].
2
Cf [PP-MRTD-EAC] for details how to access these User data under EAC protection
Copyright Gemalto SA – 2012.
Page : 23/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
Terminal
A terminal is any technical system communicating with the TOE through the contactless interface.
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.
 The Basic Inspection System (BIS) (i) contains a terminal for the 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.
 The Supplemental Inspection System (SIS) (i) contains a terminal for the communication
with the MRTD’s chip, (ii) implements the terminals part of the PACE V2 Access Control
Mechanism and (iii) gets the authorization to read the logical MRTD under the PACE V2
Access Control by optical reading the MRTD or other parts of the passport book providing this
information.
 The General Inspection System (GIS) is a Basic Inspection System which implements
additionally the Chip Authentication Mechanism.
 The Extended Inspection System (EIS) in addition to the General Inspection System (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.
Application note: This Security Target does not distinguish between the SIS, GIS, and EIS because
the Active Authenticate and the Extended Access Control are outside the scope.
MRTD Holder
The rightful holder of the MRTD for whom the issuing State or Organization personalized the MRTD.
Traveler
Person presenting the MRTD to the inspection system and claiming the identity of the MRTD holder.
Attacker
A threat agent trying (i) to identify and to trace the movement of the MRTD’s chip remotely (i.e. without
knowing or optically reading the printed MRZ data, the printed CAN, nor the PIN), (ii) to read or to
manipulate the logical MRTD without authorization, or (iii) to forge a genuine MRTD.
Application note: An impostor is attacking the inspection system as TOE IT environment independent
on using a genuine, counterfeit or forged MRTD. Therefore the impostor may use results of successful
attacks against the TOE but the attack itself is not relevant for the TOE but for the TOE IR
environment. It shall be addressed by security measures on the TOE IT environment.
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.
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.
Copyright Gemalto SA – 2012.
Page : 24/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET

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 in step 6
The Personalization Agent ensures the correctness of (i) the logical MRTD with respect to the MRTD
holder, (ii) the Document PACE V2 Access Keys, derived from the MRZ the CAN or the PIN, (iii) the
Chip Authentication Public Key (EF.DG14) if stored on the MRTD’s chip, and (iv) 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.Insp_Sys Inspection Systems for global interoperability in step 7
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 (ii) verifying the traveler as MRTD
holder. The Supplemental 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 PACE V2 Access Control [ICAO-TR-SAC]. The Supplemental
Inspection System reads the logical MRTD under PACE V2 Access Control and performs the Passive
Authentication to verify the logical MRTD.
Application note: This ST does not address Primary Inspection System therefore PACE V2, which
replaces BAC is mandatory within this ST..
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.
The TOE in collaboration with its IT environment shall avert the threats as specified below.
T.Chip_ID
Identification of MRTD’s chip
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 communication interface. The attacker cannot
read and does not know the MRZ data, the CAN printed on the MRTD data page, nor the PIN in
advance.
T.Skimming
Skimming the logical MRTD
An attacker imitates the inspection system to read the logical MRTD or parts of it via the
communication channel of the TOE. The attacker cannot read and does not know the MRZ data, the
CAN printed on the MRTD data page, nor the PIN in advance.
T.Eavesdropping
Eavesdropping to the communication between TOE and inspection
system
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, the CAN
printed on the MRTD data page, or the PIN but the attacker does not know these data in advance.
Note in case of T.Skimming the attacker is establishing a communication with the MRTD’s chip not
knowing the MRZ data, the CAN printed on the MRTD data page, or the PIN and without a help of the
inspection system, which knows these data. In case of T.Eavesdropping the attacker uses the
communication of the inspection system.
T.Forgery
Forgery of data on MRTD’s chip
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.
Copyright Gemalto SA – 2012.
Page : 25/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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 mechanism of the inspection system. The
attacker may combine data groups of different logical MRTDs to create a new forged MRTD, e.g. the
attacker writes the digitized portrait and optional biometric reference finger data read from the logical
MRTD of a traveler into another MRTD’s chip leaving their digital MRZ unchanged to claim the identity
of the holder this MRTD. The attacker may also copy the complete unchanged logical MRTD to
another contactless chip.
The TOE shall avert the threats as specified below.
T.Abuse-Func
Abuse of Functionality
An attacker may use functions of the TOE which shall not be used in the phase “Operational Use” 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.
T.Information_Leakage
Information Leakage from MRTD’s chip
An attacker may exploit information which is leaked from the TOE during its usage in order to disclose
confidential TSF data. The information leakage may be inherent in the normal operation or caused by
the attacker.
Leakage may occur through emanations, variations in power consumption, I/O characteristics, clock
frequency, or by changes in processing time requirements.
This leakage may be interpreted as a covert channel transmission but is more closely related to
measurement of operating parameters which may be derived either from measurements of the
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).
T.Phys-Tamper
Physical Tampering
An attacker may perform physical probing of the MRTD’s chip in order (i) to disclose confidential 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 hardware security
mechanisms and layout characteristics need to be identified.
Determination of software design including treatment of User Data and TSF Data may also be a prerequisite. The modification may result in the deactivation of a security function. Changes of circuitry or
data can be permanent or temporary.
T.Malfunction
Malfunction due to Environmental Stress
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.
Copyright Gemalto SA – 2012.
Page : 26/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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.
3.4 ORGANIZATIONAL SECURITY POLICIES
The TOE shall comply with the following Organizational Security Policies (OSP) as security rules,
procedures, practices, or guidelines imposed by an organization upon its operations (see [CC-1]§A.6.3.
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.
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
3
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 PACE
V2 Access Control to allow read access to these data only for terminals successfully authenticated
based on knowledge of the Document PACE V2 Access Keys as defined in [ICAO-TR-SAC].
3
Note that EF.DG3 and EF.DG4 are only readable after successful EAC authentication not being covered by this ST.
Copyright Gemalto SA – 2012.
Page : 27/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
4. SECURITY OBJECTIVES
This chapter describes the security objectives for the TOE and the security objectives for the TOE
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.DG 3 to EF.DG16 are added.
Application note: This ST does not support the addition of data in the “Operational Use” phase.
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 Supplemental Inspection System. The Supplemental Inspection System shall
authenticate itself by means of the PACE V2 Access Control based on knowledge of the Document
PACE V2 Access Key. The TOE must ensure the confidentiality of the logical MRTD data during their
transmission to the Supplemental Inspection System.
OT.Identification
Identification and Authentication of the TOE
The TOE must provide means to store IC Identification and Pre-Personalization Data in its nonvolatile
memory. The IC Identification Data must provide a unique identification of the IC during Phase 2
“Manufacturing” and Phase 3 “Personalization of the MRTD”. The storage of the Pre-Personalization
data includes writing of the Personalization Agent Authentication key(s). In Phase 4 “Operational Use”
the TOE shall identify itself only to a successful authenticated Supplemental Inspection System or
Personalization Agent.
Application note: In a multi-applicative product, data allowing to identify the IC or the MRTD can be
disclosed by other applications. Therefore this objective on the TOE shall also apply to the other
applications.
The following TOE security objectives address the protection provided by the MRTD’s chip
independent of the TOE environment.
OT.Prot_Abuse-Func Protection against Abuse of Functionality
After delivery of the TOE to the MRTD Holder, the TOE must prevent the abuse of test and support
functions that may be maliciously be used to (i) disclose critical User Data, (ii) manipulate critical User
Data of the IC Embedded Software, (iii) 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
Copyright Gemalto SA – 2012.
Protection against Information Leakage
Page : 28/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
The TOE must provide protection against disclosure of confidential TSF data stored and/or processed
in the MRTD’s chip
 by measurement and analysis of the shape and amplitude of signals or the time between
events found by measuring signals on the electromagnetic field, power consumption, clock, or
I/O lines and
 by forcing a malfunction of the TOE and/or
 by a physical manipulation of the TOE.
Application note: This objective pertains to measurements with subsequent complex signal
processing due to normal operation of the TOE or operations enforced by an attacker. Details
correspond to an analysis of attack scenarios which is not given here.
OT.Prot_Phys-Tamper Protection against Physical Tampering
The TOE must provide protection of the confidentiality and integrity of the User Data, the TSF Data,
and the MRTD’s chip Embedded Software. This includes protection against attacks with enhancedbasic 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.
Application note: A malfunction of the TOE may also be caught 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.
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),
 traceability of TOE during delivery including the following parameters:
 origin and shipment details,
 reception, reception acknowledgement,
 location material/information.
Copyright Gemalto SA – 2012.
Page : 29/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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 behalf of the
issuing State or Organization (i) establish the correct identity of the holder and create biographical data
for the MRTD, (ii) enroll the biometric reference data of the MRTD holder i.e. the portrait, the encoded
finger image(s) and/or the encoded iris image(s) and (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 CA Key
Pair, (ii) ensure the secrecy of the Country Signing CA Private Key and sign Document Signer
Certificates in a secure operational environment, and (iii) distribute the Certificate of the Country
Signing CA Public Key to receiving States and Organizations maintaining its authenticity and integrity.
The issuing State or Organization must (i) generate a cryptographic secure Document Signer 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 Signer Public Key to receiving States and Organizations. The digital signature in the
Document Security Object relates all data in the data in EF.DG1 to EF.DG16 if stored in the LDS
according to [ICAO-9303].
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 or Organization must examine the MRTD presented by
the traveler to verify its authenticity by means of the physical security measures and to detect any
manipulation of the physical MRTD. The Supplemental Inspection System (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 PACE V2 Access Control [ICAO-TR-SAC].
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
Signer Public Key maintaining their authenticity and availability in all inspection systems.
OE.Prot_Logical_MRTD
Protection of data from 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
PACE V2 Access Control will use inspection systems which implement the terminal part of the PACE
V2 Access Control and use the secure messaging with fresh generated keys for the protection of the
transmitted data (i.e. Supplemental Inspection Systems).
Copyright Gemalto SA – 2012.
Page : 30/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
5. EXTENDED COMPONENTS DEFINITION
This ST uses components defined as extensions to CC part 2. Some of these components are
defined in protection profile [PP-IC-0002], other components are defined in the protection profile [PPMRTD-SAC].
5.1 DEFINITION OF THE FAMILY FAU_SAS
To define the security functional requirements of the TOE a sensitive family (FAU_SAS) of the
Class FAU (Security Audit) is defined here. This family describes the functional requirements for the
storage of audit data. It has a more general approach than FAU_GEN, because it does not
necessarily require the data to be generated by the TOE itself and because it does not give specific
details of the content of the audit records.
The family “Audit data storage (FAU_SAS)” is specified as follows.
FAU_SAS Audit data storage
Family behavior
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.
FAU_SAS.1
Audit storage
Hierarchical to: No other components.
Dependencies: No dependencies.
FAU_SAS.1.1
The TSF shall provide [assignment: authorized users] with the capability to
store [assignment: list of audit information] in the audit records.
5.1.1 Definition of the Family FCS_RND
To define the IT security functional requirements of the TOE an additional family (FCS_RND) of the
Class FCS (cryptographic support) is defined here. This family describes the functional
requirements for random number generation used for cryptographic purposes. The component
FCS_RND is not limited to generation of cryptographic keys unlike the component FCS_CKM.1.
The similar component FIA_SOS.2 is intended for non-cryptographic use.
The family “Generation of random numbers (FCS_RND)” is specified as follows.
FCS_RND Generation of random numbers
Family behavior
Copyright Gemalto SA – 2012.
Page : 31/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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.
Dependencies: No dependencies.
The TSF shall provide a mechanism to generate random numbers that meet
[assignment: a defined quality metric].
FCS_RND.1.1
5.1.2 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 behavior
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:
1
FMT_LIM Limited capabilities and availability
2
FMT_LIM.1
Copyright Gemalto SA – 2012.
Limited capabilities requires that the TSF is built to provide only the
capabilities (perform action, gather information) necessary for its genuine
purpose.
Page : 32/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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 an additional family (FMT_LIM) of the
Class FMT (Security Management) is defined here. This family describes the functional requirements
for the Test Features of the TOE. The new functional requirements were defined in the class FMT
because this class addresses the management of functions of the TSF. The examples of the technical
mechanism used in the TOE show that no other class is appropriate to address the specific issues of
preventing the abuse of functions by limiting the capabilities of the functions and by limiting their
availability.
The TOE Functional Requirement “Limited capabilities (FMT_LIM.1)” is specified as follows.
FMT_LIM.1 Limited capabilities
Hierarchical to: No other components.
Dependencies: FMT_LIM.2 Limited availability.
FMT_LIM.1.1
The TSF shall be designed 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].
The TOE Functional Requirement “Limited availability (FMT_LIM.2)” is specified as follows.
FMT_LIM.2 Limited availability
Hierarchical to: No other components.
Dependencies: FMT_LIM.1 Limited capabilities.
FMT_LIM.2.1
The TSF shall be designed in a manner that limits their availability so that in
conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is
enforced [assignment: Limited capability and availability policy].
Application note: 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.1.3 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 TOE and other secret data where the attack is based on external observable
physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s electromagnetic
radiation, simple power analysis (SPA), differential power analysis (DPA), timing attacks, etc. This
Copyright Gemalto SA – 2012.
Page : 33/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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].
The family “TOE Emanation (FPT_EMSEC)” is specified as follows.
Family behavior
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 to 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.
Dependencies: No other dependencies.
FPT_EMSEC.1.1
FPT_EMSEC.1.2
Copyright Gemalto SA – 2012.
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].
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].
Page : 34/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
6. SECURITY REQUIREMENTS
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.
Refinements in this section are in underline font when the SFR’s refinement is already present in [PPMRTD-SAC], and in bold font when the refinement is done in this ST. When the SFR is refined in the
[PP-MRTD-SAC] and additionally refined in this ST then the font is bold and underline.
6.1.1 Class FAU Security Audit
The TOE shall meet the requirement “Audit storage (FAU_SAS.1)” as specified below (Common
Criteria Part 2 extended).
FAU_SAS.1 Audit storage
Hierarchical to: No other components.
Dependencies: No dependencies.
FAU_SAS.1.1
The TSF shall provide the Manufacturer with the capability to store the IC
Identification Data in the audit records.
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 – Generation of Document V2 Session keys by the
TOE
Hierarchical to: No other components.
Dependencies: [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 Cryptographic operation]
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.1.1
iteration
/TDESsession-ECDH
The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm [algorithm] and specified cryptographic
key sizes [Key size] bit that meet the following: [ICAO-TR-SAC] normative
appendix 5.
Key size
112 bits
Standards
[ICAO-TR-SAC]
normative appendix 5
128 bits
[ICAO-TR-SAC]
normative appendix 5
/TDESsession-Perso
algorithm
ECDH Key Agreement Algorithm - ISO
15946 - 192, 224, 256, 320, and 384
bits
ECDH Key Agreement Algorithm - ISO
15946 - 192, 224, 256, 320, and 384
bits
TDES ISK key derivation
112 bits
/GP
GP session keys
112 bits
[ICAO-9303] normative
appendix 5
[GP211]
/AESsession-ECDH
Copyright Gemalto SA – 2012.
Page : 35/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
The TOE shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as specified below
(Common Criteria Part 2).
FCS_CKM.4 Cryptographic key destruction - MRTD
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4.1
The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method Secure erasing of the value that meets the
following: none.
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 by MRTD
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/SHA
The TSF shall perform hashing in accordance with a specified cryptographic
algorithm SHA-1 and cryptographic key sizes none that meet the following: FIPS
180-2.
FCS_COP.1/ENC Cryptographic operation –Encryption / Decryption triple DES
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/ENC
iteration
/ENC_TDES
/ENC_AES
The TSF shall perform secure messaging (PACE V2) – encryption and
decryption in accordance with a specified cryptographic algorithm [algorithm]
and cryptographic key sizes [Key size] that meet the following: [list of
standards].
algorithm
TDES in CBC mode
AES in CBC mode
FCS_COP.1/AUTH Cryptographic operation – Authentication
Hierarchical to: No other components.
Copyright Gemalto SA – 2012.
Page : 36/50
Key size
112 bits
128 bits
List of standards
FIPS 46-3
FIPS 197
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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/AUTH
The TSF shall perform symmetric authentication – encryption and decryption in
accordance with a specified cryptographic algorithm Triple-DES and
cryptographic key sizes 112 bits that meet the following: FIPS 46-3.
FCS_COP.1/MAC Cryptographic operation – Retail MAC
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/MAC
The TSF shall perform secure messaging – message authentication code in
accordance with a specified cryptographic algorithm [algorithm] and
cryptographic key sizes [key size] that meet the following [list of standards].
iteration
/MAC_TDES
algorithm
TDES Retail MAC
Key size
112 bits
/MAC_AES
AES CMAC
128 bits
List of standards
ISO 9797 method 2 algo
3
FIPS 197
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.
Dependencies: No dependencies.
FCS_RND.1.1
The TSF shall provide a mechanism to generate random numbers that meet K3DRNG ([AIS20]) with seed entropy at least 112 bits and with strength of
mechanism set to high.
6.1.3 Class FIA Identification and Authentication
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.
Dependencies: No dependencies.
FIA_UID.1.1
The TSF shall allow
1. to read the Initialization Data in Phase 2 "Manufacturing",
2. to read the random identifier and the file CardAccess in Phase 3
Copyright Gemalto SA – 2012.
Page : 37/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
FIA_UID.1.2
"Personalization of the MRTD",
3. to read the random identifier and the file CardAccess in Phase 4 "Operational
Use"
on behalf of the user to be performed before the user is identified.
The TSF shall require each user to be successfully identified before allowing any
other TSF-mediated actions on behalf of that user.
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.
Dependencies: FIA_UID.1 Timing of identification.
FIA_UAU.1.1
FIA_UAU.1.2
The TSF shall allow
1. to read the Initialization Data in Phase 2 "Manufacturing",
2. to read the random identifier and the file CardAccess in Phase 3
"Personalization of the MRTD",
3. to read the random identifier and the file CardAccess in Phase 4 "Operational
Use"
on behalf of the user to be performed before the user is authenticated.
The TSF shall require each user to be successfully authenticated before allowing any
other TSF-mediated actions on behalf of that user.
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.
Dependencies: No dependencies.
The TSF shall prevent reuse of authentication data related to
1. PACE V2 Access Control Authentication Mechanism,
2. Authentication Mechanism based on Triple-DES.
FIA_UAU.4.1
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
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1
FIA_UAU.5.2
The TSF shall provide
1. PACE V2 Access Control Authentication Mechanism,
2. Symmetric Authentication Mechanism based on Triple-DES
to support user authentication.
The TSF shall authenticate any user’s claimed identity according to the
following rules:
Copyright Gemalto SA – 2012.
Page : 38/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
1. The TOE accepts the authentication attempt as Personalization Agent by the
Symmetric Authentication Mechanism with Personalization Agent Key ".
2. The TOE accepts the authentication attempt as Supplemental Inspection System
only by means of the PACE V2 Access Control Authentication Mechanism with
the Document PACE V2 Access Keys.
The TOE shall meet the requirement “Re-authenticating (FIA_UAU.6)” as specified below (Common
Criteria Part 2).
FIA_UAU.6 Re-authenticating – Re-authenticating of Terminal by the TOE
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.6.1
The TSF shall re-authenticate the user under the conditions: Failure of MAC
verification in a command received by the TOE..
The TOE shall meet the requirement “Authentication failure handling (FIA_AFL.1)” as specified below
(Common Criteria Part 2).
FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication.
FIA_AFL.1.1
FIA_AFL.1.2
The TSF shall detect when [positive integer number] unsuccessful authentication
attempts occur related to [specified authentication events].
When the defined number of unsuccessful authentication attempts has been [met], the
TSF shall [actions].
Refinement:
Number
of
unsuccessful
authentication attempts
3
1
Specified Authentication events
Actions
Unsuccessful
Mutual
Authentication Command with
Initial Supplier Key KISK
Unsuccessful PACE V2 Access
Control authentication attempt
Initial Supplier Key blocked
Exponentially increasing
time
delay before new authentication
attempt is possible
Table 3: FIA_AFL.1 refinement
6.1.4 Class FDP User Data Protection
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 – PACE V2 Access Control
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1
The TSF shall enforce the PACE V2 Access Control SFP on terminals gaining write,
read and modification access to data in the EF.COM, EF.SOD, EF.DG1 to EF.DG16
of the logical MRTD.
Copyright Gemalto SA – 2012.
Page : 39/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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 – PACE V2 Access Control
Hierarchical to: No other components.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
The TSF shall enforce the PACE V2 Access Control SFP to objects based on
the following:
1. Subjects:
a.
Personalization Agent,
b.
Supplemental 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.
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 Supplemental Inspection System is
allowed to read the data of the EF.COM, EF.SOD, EF.DG1, EF.DG2,
and EF.DG5 to EF.DG16 of the logical MRTD.
The TSF shall explicitly authorize access of subjects to objects based on the
following additional rules: none.
The TSF shall explicitly deny access of subjects to objects based on the
following additional rules:
1. Any terminal is not allowed to modify any of the EF.DG1 to EF.DG16 of
the logical MRTD,
2. Any terminal is not allowed to read any of the EF.DG1 to EF.DG16 of
the logical MRTD,
3. The Supplemental Inspection System is not allowed to read the data in
EF.DG3 and EF.DG4.
FDP_ACF.1.1
FDP_ACF.1.2
FDP_ACF.1.3
FDP_ACF.1.4
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.
Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
FDP_UCT.1.1
The TSF shall enforce the PACE V2 Access Control SFP to transmit and receive user
data in a manner protected from unauthorized disclosure
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
Copyright Gemalto SA – 2012.
Page : 40/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
Hierarchical to: No other components.
Dependencies: [FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
[FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path]
FDP_UIT.1.1
FDP_UIT.1.2
The TSF shall enforce the PACE V2 Access Control SFP to transmit and receive user
data in a manner protected from modification, deletion, insertion and replay errors.
The TSF shall be able to determine on receipt of user data, whether modification,
deletion, insertion and replay has occurred.
6.1.5 Class FMT Security Management
Application note: 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
Hierarchical to: No other components.
Dependencies: No dependencies.
FMT_SMF.1.1
The TSF shall be capable of performing the following management functions:
1. Initialization ,
2. Personalization ,
3. Configuration
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.
Dependencies: FIA_UID.1 Timing of identification.
The TSF shall maintain the roles
1.
Manufacturer ,
2.
Personalization Agent ,
3.
Supplemental Inspection System.
The TSF shall be able to associate users with roles.
FMT_SMR.1.1
FMT_SMR.1.2
The TOE shall meet the requirement “Limited capabilities (FMT_LIM.1)” as specified below (Common
Criteria Part 2 extended).
FMT_LIM.1 Limited capabilities
Hierarchical to: No other components.
Dependencies: FMT_LIM.2 Limited availability.
FMT_LIM.1.1
The TSF shall be designed in a manner that limits their capabilities so that in
conjunction with “Limited availability (FMT_LIM.2)” the following policy is enforced:
Deploying Test Features after TOE Delivery does not allow,
1.
User data to be disclosed or manipulated,
2.
TSF data to be disclosed or manipulated
Copyright Gemalto SA – 2012.
Page : 41/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
3.
4.
software to be reconstructed and
substantial information about construction of TSF to be gathered which may
enable other attacks.
The TOE shall meet the requirement “Limited availability (FMT_LIM.2)” as specified below
(Common Criteria Part 2 extended).
FMT_LIM.2 Limited availability
Hierarchical to: No other components.
Dependencies: FMT_LIM.1 Limited capabilities.
FMT_LIM.2.1
The TSF shall be designed in a manner that limits their availability so that in
conjunction with “Limited capabilities (FMT_LIM.1)” the following policy is enforced:
Deploying Test Features after TOE Delivery does not allow,
1.
User data to be disclosed or manipulated,
2.
TSF data to be disclosed or manipulated
3.
software to be reconstructed and
4.
substantial information about construction of TSF to be gathered which may
enable other attacks.
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 prepersonalization Data
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions.
FMT_SMR.1 Security roles
FMT_MTD.1.1/INI_ENA
The TSF shall restrict the ability to write the Initialization Data and prepersonalization Data to the Manufacturer.
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.
Dependencies: FMT_SMF.1 Specification of management functions.
FMT_SMR.1 Security roles
The TSF shall restrict the ability to disable read access for users to the
Initialization Data to the Personalization Agent.
FMT_MTD.1.1/
INI_DIS
FMT_MTD.1/KEY_WRITE Management of TSF data – Key Write
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions.
FMT_SMR.1 Security roles
FMT_MTD.1.1
/KEY_WRITE
The TSF shall restrict the ability to write the Document PACE V2 Access Keys to the
Personalization Agent.
Copyright Gemalto SA – 2012.
Page : 42/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
FMT_MTD.1/KEY_READ Management of TSF data – Key Read
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions.
FMT_SMR.1 Security roles
The TSF shall restrict the ability to read the Document PACE V2 Access Keys
and Personalization Agent Keys to none.
FMT_MTD.1.1/
KEY_READ
6.1.6 Class FPT Protection of the Security Functions
The TOE shall prevent inherent and forced illicit information leakage for User Data and TSF Data. The
security functional requirement FPT_EMSEC.1 addresses the inherent leakage. With respect to the
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 SFRs “Limited capabilities
(FMT_LIM.1)”, “Limited availability (FMT_LIM.2)” and “Resistance to physical attack (FPT_PHP.3)”
together with the SAR “Security architecture description” (ADV_ARC.1) prevent bypassing, deactivation
and manipulation of the security features or misuse of TOE functions.
The TOE shall meet the requirement “TOE Emanation (FPT_EMSEC.1)” as specified below (Common
Criteria Part 2 extended):
FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_EMSEC.1.1
FPT_EMSEC.1.2
The TOE shall not emit electromagnetic and current emissions in excess of
intelligible threshold enabling access to Personalization Agent Key(s),
Document PACE V2 Access Keys, EF.COM, EF.SOD, EF.DG1, EF.DG2,
and EF.DG6 to EF.DG16.
The TSF shall ensure any unauthorized users are unable to use the following
interface: smart card circuit contacts to gain access to Personalization Agent
Key(s) and Document PACE V2 Access Keys, EF.COM, EF.SOD, EF.DG1,
EF.DG2, and EF.DG6 to EF.DG16.
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).
FPT_FLS.1 Failure with preservation of secure state
Hierarchical to: No other components.
Dependencies: No dependencies.
FPT_FLS.1.1
The TSF shall preserve a secure state when the following types of failures occur:
1. Exposure to out-of-range operating conditions where therefore a malfunction
could occur,
2. failure detected by TSF according to FPT_TST.1.
Copyright Gemalto SA – 2012.
Page : 43/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
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.
Dependencies: No dependencies.
FPT_TST.1.1
FPT_TST.1.2
FPT_TST.1.3
The TSF shall run a suite of self tests at the conditions [conditions under which
self test should occur] to demonstrate the correct operation of the TSF.
The TSF shall provide authorized users with the capability to verify the integrity of TSF
data.
The TSF shall provide authorized users with the capability to verify the integrity of TSF.
Conditions under which self test should occur
During initial start-up
Periodically
After cryptographic computation
Before any use or update of TSF data
Description of the self test
RNG live test, sensor test, FA detection, Integrity
Check of NVM ES
RNG monitoring, sensor test, FA detection
FA detection
FA detection, Integrity Check of related TSF data
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.
Dependencies: No dependencies.
FPT_PHP.3.1
The TSF shall resist physical manipulation and physical probing to the TSF by
responding automatically such that the SFR are always enforced.
Copyright Gemalto SA – 2012.
Page : 44/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
6.2 SECURITY ASSURANCE REQUIREMENTS FOR THE TOE
The 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 taking the following
components: ALC_DVS.2 and AVA_VAN.5.
Copyright Gemalto SA – 2012.
Page : 45/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
7. TOE SUMMARY SPECIFICATION
7.1 TOE SECURITY FUNCTIONS
TOE Security Functions are provided by the MultiApp V2 PACE embedded software (including the
optional NVM ES) and by the chip.
7.1.1 TSFs provided by the MultiApp V2 PACE Software
SF
Description
SSF
SF.REL
Reliability
SF.AC
Access Control
SF.SYM_AUT
Symmetric Authentication
Mechanisms
SF.REL.RNG_TEST
SF.REL.SENSOR_TEST
SF.REL.INTEGRITY
SF.REL.CORR_EXEC
SF.REL.PROT_SENS_DATA
SF.REL.FAULT_REACTION
SF.AC.LIFE_CYCLE
SF.AC.STATE
SF.AC.FILE_AC
SF.SYM_AUT.RNG
SF.SYM_AUT.MANUF
SF.SYM_AUT.MANUF_PROT
SF.SYM_AUT.MANUF_KEY_CHANGE
SF.SYM_AUT.SAC
SF.SYM_AUT.SAC_RESTR
SF.SM
Secure Messaging
Table 4: Security Functions provided by the MultiApp V2 PACE Software.
7.1.1.1 SF.REL: Reliability
The SF.REL security function is divided to the following SSFs:
1. SF.REL.RNG_TEST
2. SF.REL.SENSOR_TEST
3. SF.REL.INTEGRITY
4. SF.REL.CORR_EXEC
5. SF.REL.PROT_SENS_DATA
6. SF.REL.FAULT_REACTION.
SSFs SF.REL.RNG_TEST and SF.REL.SENSOR_TEST executes tests to insure that the TOE is in
secure state. The SF.REL.RNG_TEST SSF tests random number generator and the
SF.REL.SENSOR_TEST SSF tests environment sensors.
The SF.REL.INTEGRITY SSF checks the integrity of following assets:
o Keys
o application files (EF.DG1 to EF.DG16, EF.SOD, EF.COM)
o access rights flags
o NVM ES
o anti-tearing area
Copyright Gemalto SA – 2012.
Page : 46/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
o life cycle status.
The SF.REL.CORR_EXEC consists of measures to detect Fault Attacks (FA), involving:

performing twice and checking the consistency of the certain security critical operations,

security tests near branching to protect a sensitive conditional branch against perturbation,

step control to ensure that critical functional steps of a command are really executed and not
skipped.
The SF.REL.PROT_SENS_DATA SSF provides several mechanisms ensuring the confidentiality of
sensitive data during their manipulation. These mechanisms counter the exploitation of electrical or
electromagnetic emissions which are generated during the treatment of data. They are mainly
based on clock de-synchronization and/or random order treatments. This security function involve:
random order processing mechanism, secured DES operation, secured RSA operation, secured
ECC operation and software de-synchronization mechanism.
The SF.REL.FAULT_REACTION consists of detecting faults either by hardware reaction or by
software detection based on the SF.REL.SENSOR_TEST, SF.REL.INTEGRITY and
SF.REL.CORR_EXEC. When a fault is detected, the card goes to mute state, either immediately or
after a delay.
This function has no strength.
7.1.1.2 SF.AC: Access Control
The SF.AC security function is divided to the following SSFs:
1. SF.AC.LIFE_CYCLE
2. SF.AC.STATE
3. SF.AC.FILE_AC
The TOE has four life cycle phases: development, manufacturing, personalization and operational.
The TOE ES has the following life cycle states:
VIRGIN: the state in which chip is received from chip manufacturer
RE_INITIALIZATION: the state in which initialization can be repeated and conditionally erased all
previously initialized or pre-personalized information
PRE_PERSONALIZATION: the state after (re-)initialization in which personalization commands are
available, but where file access conditions do not apply
PERSONALIZATION: the state after (re-)initialization or pre-personalization in which personalization
commands are available
OPERATIONAL: the state of normal usage after personalization in which the usage phase
commands are available
TERMINATED: the state in which no commands are available.
The following table shows correspondence between life cycle states of the ES and lice cycle
phases.
Life cycle state
Life cycle phase
VIRGIN
RE_INITIALIZATION
PRE_PERSONALIZATION
PERSONALIZATION
OPERATIONAL
TERMINATED
MANUFACTURING
MANUFACTURING
MANUFACTURING
PERSONALIZATION
OPERATIONAL
-
Table 5: Correspondence between TOE ES life cycle states and life cycle phases.
During initial startup life cycle status is read. Each life cycle state has own set of available
commands and particular command may have different behaviour depending on life cycle. The
SF.AC.LIFE_CYCLE function manages the lifecycle status and ensures that the status is set in an
Copyright Gemalto SA – 2012.
Page : 47/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
irreversible way from the phase 2 “Manufacturing” to the phase 3 “Personalization of the MRTD”
and from the phase 3 to the phase 4 “Operational Use”. The phases 2, 3 and 4 have dedicated
commands. Life cycle status can be changed through END PERSO command. This command is
used to finalize the pre-personalization or the personalization process. If the current life cycle status
is PRE_PERSONALIZATION, the next state will be PERSONALIZATION or OPERATIONAL after
execution of this command. If the current state is PERSONALIZATION, the next state will be
OPERATIONAL after execution of this command. The chip becomes mute after END_PERSO
command and initial startup is needed.
The SF.AC.LIFE_CYCLE function manages the high-level life cycle steps of the chip. The
SF.AC.STATE function manages the run-time volatile states. The SF.AC.STATE controls the set of
available commands through a state machine and the related state transitions. For each life cycle
state there exist a specific and finite set of volatile states. A volatile state is characterized by the set
of available commands and the available state transitions to other volatile states. The state
transitions are implemented by the relevant commands.
The SF.AC.FILE_AC function ensures that the assets (keys, Data Groups, TSF data) can only be
accessed under the control of the operating system and as defined by the access rights written
during the personalization process. This SF controls the reading and writing access in
personalization (Mutual Authenticate Access Control) and user phases (Basic Access Control and
Extended Access Control).
7.1.1.3 SF.SYM_AUT: Symmetric Authentication Mechanisms
The SF.AC security function is divided to the following SSFs:
1. SF.SYM_AUT.RNG
2. SF.SYM_AUT.MANUF
3. SF.SYM_AUT.MANUF_PROT
4. SF.SYM_AUT.MANUF_KEY_CHANGE
5. SF.SYM_AUT.SAC
6. SF.SYM_AUT.SAC_RESTR
The SF.SYM_AUT.RNG SSF provides pseudo-random numbers.
The SF.SYM_AUT.MANUF SSF enforces mutual authentication with Manufacturer Key during
manufacturing phase. The SF.SYM_AUT.MANUF_KEY_CHANGE manages the Manufacturer
Key changes between the terminal and the TOE. The key can be changed in previous phase for
next phase as shown in the following picture.
-
-
IC Manufacturer
Manufacturer Key loading
Manufacturer Key= Initialization key
Initialization
Manufacturer Key change
Manufacturer Key= Pre- personalization key
Pre- personalization
- Manufacturer Key change
- Manufacturer Key= Personalization key
Personalization
Figure 5: Manufacturer key
Copyright Gemalto SA – 2012.
Page : 48/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
The SF.SYM_AUT.MANUF detects each unsuccessful authentication attempt. In such a case it
warns the connected terminal. In case of successful termination of the protocol it stores
appropriate keys for the secure messaging.
The SF.SYM_AUT.MANUF_PROT protects Manufacturer Key. After three consecutive false
authentication attempts the key is locked.
SF.SYM_AUT.SAC enforces mutual authentication during PACE V2 Access Control
mechanism and manages the key exchanges between the terminal and the TOE. The SSF
detects each unsuccessful authentication attempt. In such a case it warns the connected
terminal. In case of successful termination of the protocol it stores appropriate keys for the
secure messaging.
SF.SYM_AUT.SAC_RESTR restricts false PACE V2 Access Control authentication attempts.
After unsuccessful PACE V2 authentication there is delay before next authentication attempt is
possible. Every consecutive false attempt increases the delay until maximum value is reached.
7.1.1.4 SF.SM: Secure Messaging
The SF.SM function provides the management of the secure channel for the sensitive data
exchange with the terminal. The integrity and authenticity of the communication is handled by using
encryption and Message Authentication Codes. The authentication procedures differ between life
cycles states, but once the session keys are generated, the SM processing is equal in all of them. If
a SM error occurs, the session keys are cleared and the SM is aborted. Defined authentication
status information is also cleared upon such event. A SM error may be due to not using SM, having
too few or wrong SM fields, incorrect order of SM fields or having MAC or padding errors in SM
fields.
Copyright Gemalto SA – 2012.
Page : 49/50
MULTIAPP V2 PACE - SAC PUBLIC SECURITY TARGET
7.1.2 TSFs provided by the Infineon chip
The evaluation is a composite evaluation and uses the results of the CC evaluation provided by] [CRIC-1440]. The IC and its primary embedded software have been evaluated at level EAL 5+.
SF
SEF.1
SEF.2
SEF.3
SEF.4
SEF.5
SEF.6
SEF.7
SEF.8
SEF.9
Description
Operating state checking
Phase management with test mode lock-out
Protection against snooping
Data encryption and data disguising
Random number generation
TSF self test
Notification of physical attack
Memory Management Unit (MMU)
Cryptographic support
Table 6: SF provided by the IFX chips
These SF are described in [ST-IC-1440].
Copyright Gemalto SA – 2012.
Page : 50/50
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertising