MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 1 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
REF: 2011-13-INF-1092 v1
Target: Expediente
Date: 17.12.2012
Created by: CERT8
Revised by: CALIDAD
Approved by: TECNICO
CERTIFICATION REPORT
File: 2011-13 POLYMNIE LDS BAP applet
Applicant: B340709534 OBERTHUR TECHNOLOGIES
References:
[EXT-1367] Certification request of LDS EAC Java Applet in BAP configuration with
AA v2.2
[EXT-1917] Evaluation Technical Report of LDS EAC Java Applet in BAP
configuration with AA v2.2, version M4.
The product documentation referenced in the above documents.
Certification report of the product LDS EAC Java Applet in BAP configuration with
AA v2.2, as requested in [EXT-1367] dated 10-06-2011, and evaluated by the
laboratory Applus LGAI Technological Center S.A., as detailed in the Evaluation
Technical Report [EXT-1917] received on 26/10/2012.
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 2 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
TABLE OF CONTENTS
EXECUTIVE SUMMARY ..................................................................................................................................3
TOE SUMMARY ..............................................................................................................................................3
SECURITY ASSURANCE REQUIREMENTS................................................................................................5
SECURITY FUNCTIONAL REQUIREMENTS ..............................................................................................5
IDENTIFICATION..............................................................................................................................................6
SECURITY POLICIES .......................................................................................................................................7
ASSUMPTIONS AND OPERATIONAL ENVIRONMENT............................................................................8
CLARIFICATIONS ON NON-COVERED THREATS....................................................................................9
OPERATIONAL ENVIRONMENT FUNCTIONALITY...............................................................................12
ARCHITECTURE..............................................................................................................................................14
DOCUMENTS ....................................................................................................................................................15
PRODUCT TESTING........................................................................................................................................15
PENETRATION TESTING.............................................................................................................................16
EVALUATED CONFIGURATION .................................................................................................................17
EVALUATION RESULTS................................................................................................................................17
COMMENTS & RECOMMENDATIONS FROM THE EVALUATION TEAM.......................................18
CERTIFIER RECOMMENDATIONS ............................................................................................................18
GLOSSARY........................................................................................................................................................18
BIBLIOGRAPHY...............................................................................................................................................19
SECURITY TARGET........................................................................................................................................20
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 3 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
EXECUTIVE SUMMARY
This document constitutes the Certification Report for the certification file of the
product LDS EAC Java Applet in BAP configuration with AA v2.2.
The TOE is composed of both an Integrated Circuit (IC), JavaCard platform and a
loaded applet providing secure data management following [ISO18013-1],
[ISO18013-2] and [ISO18013-3] BAP IDL specifications and Active Authentication.
The Target of Evaluation is therefore a composite TOE.
Developer/manufacturer: Oberthur Technologies.
Sponsor: Oberthur Technologies.
Certification Body: Centro Criptológico Nacional (CCN) del Centro Nacional de
Inteligencia (CNI).
ITSEF: Applus LGAI Technological Center S.A..
Protection Profile: No conformance to any Protection Profile is claimed
Evaluation Level: Common Criteria version 3.1 revision 3, EAL4 + ALC_DVS.2.
Evaluation end date: 09/10/2012.
All the assurance components required by the evaluation level EAL4 (augmented
with ALC_DVS.2) have been assigned a “PASS” verdict. Consequently, the
laboratory Applus LGAI Technological Center S.A. assigns the “PASS” VERDICT to
the whole evaluation due all the evaluator actions are satisfied for the EAL4 +
ALC_DVS.2, as defined by the Common Criteria version 3.1 revision 3 and the
Common Methodology for Information Technology Security Evaluation version 3.1
revision 3.
Considering the obtained evidences during the instruction of the certification request
of the product LDS EAC Java Applet in BAP configuration with AA v2.2, a positive
resolution is proposed.
TOE SUMMARY
The Target of Evaluation (TOE) is a smartcard composed of the following
components:
‐ An ID One Cosmo v7.0.1-n JavaCard platform including Global Platform
support and a cryptographic library,
‐ LDS EAC Java Applet in BAP configuration with AA v2.2
The Logical Data Structure (LDS) application is a generic filesystem that can be
configured to match especially ICAO specifications for ePassports BAC and EAC
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 4 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
and ISO specifications for IDL BAP and EAP. The configuration in the scope of this
certification report is the IDL BAP specification of this application.
The main features provided by the LDS EAC Java Applet in BAP configuration with
AA v2.2 and present in the evaluation scope are summarized in the following table:
Feature Embedded in the product In the Certificate scope
BAC Yes No
EAC Yes No
Active Authentication
(DES, AES, RSA CRT and ECC)
Yes Yes
Cryptosystem migration
(Algorithm change during
certificate verification
transaction)
Yes No
BAP Yes Yes
EAP Yes No
The TOE in the scope of this Certification Report provides Basic Access Protection
according to [ISO18013-1][ISO18013-2][ISO18013-3] and Active Authentication
mechanisms.
The Basic Access Protection (BAP) is especially used in the context of IDL as an
alternative to BAC. Indeed it is actually a generalization of BAC allowing usage of
extra algorithms and key length. It exists in 4 modes:
‐ BAP1 - 3DES with key length of 128 bits (equivalent to BAC),
‐ BAP2 - AES with key length of 128 bits,
‐ BAP3 - AES with key length of 192 bits,
‐ BAP4 - AES with key length of 256 bits.
Following Secure messaging is performed using the algorithm used in the selected
BAP mode.
Note that the term MRZ is specific to ICAO standard; [ISO18013-3] uses the term
“Keydoc” which refers to an equivalent unique identifier printed on the physical TOE
as a random number or barcode.
The Active Authentication of the TOE is an optional feature that may be
implemented. It ensures that the TOE has not been substituted, by means of a
challenge-response protocol between the inspection system and the TOE. For this
purpose the chip contains its own Active Authentication DES/AES key or RSA/ECC
Key pair. A hash representation of Data Group 15 Secret/Public key is stored in the
Document Security Object and therefore authenticated by the issuer’s digital
signature. If any, the corresponding Private Key is stored in the TOE’s secure
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 5 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
memory. Note that the access to DG15 is disabled if a secret key is stored. The TOE
supports the loading and generation of the Active Authentication DES/AES key or
RSA/ECC Key pair.
Some features of the product are put out of the evaluation scope and are therefore
not part of the TOE. Here is the complete list of those functionalities:
‐ Standard and biometric PIN management (therefore PIN associated
commands are out of scope).
SECURITY ASSURANCE REQUIREMENTS
The product was evaluated with all the evidence required to fulfil the evaluation level
EAL4 and the evidences required by the additional components ALC_DVS.2,
according to Common Criteria version 3.1 revision 3.
Assurance Class Assurance components
ADV_ARC.1 Security architecture description
ADV_FSP.4 Complete functional specification
ADV_IMP.1 Implementation representation of the TSF
ADV: Development
ADV_TDS.3 Basic modular design
AGD_OPE.1 Operational user guidance
AGD: Guidance documents
AGD_PRE.1 Preparative procedures
ALC_CMC.4 Production support, acceptance procedures and
automation
ALC_CMS.4 Problem tracking CM coverage
ALC_DEL.1 Delivery procedures
ALC_DVS.2 Sufficiency of security measures
ALC_LCD.1 Developer defined life-cycle model
ALC: Life-cycle support
ALC_TAT.1 Well-defined development tools
ASE_CCL.1 Conformance claims
ASE_ECD.1 Extended components definition
ASE_INT.1 ST introduction
ASE_OBJ.2 Security objectives
ASE_REQ.2 Derived security requirements
ASE_SPD.1 Security problem definition
ASE: Security Target
evaluation
ASE_TSS.1 TOE summary specification
ATE_COV.2 Analysis of coverage
ATE_DPT.1 Testing: basic design
ATE_FUN.1 Functional testing
ATE: Tests
ATE_IND.2 Independent testing - sample
AVA: Vulnerability assessment AVA_VAN.3 Focused vulnerability analysis
SECURITY FUNCTIONAL REQUIREMENTS
The product security functionality satisfies the following functional requirements,
according to the Common Criteria version 3.1 revision 3:
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 6 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
Class Components
FAU: Security Audit FAU_SAS.1 Audit storage
FCS_CKM.1/Cryptographic key generation
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1/SHA Cryptographic operation
FCS_COP.1/ENC Cryptographic operation
FCS_COP.1/MAC Cryptographic operation
FCS_COP.1/AUTH Cryptographic operation
FCS: Cryptographic Support
FCS_RND.1 Quality metric for random numbers
FIA_AFL.1 Authentication failure handling
FIA_UID.1 Timing of identification
FIA_UAU.1 Timing of authentication
FIA_UAU.4 Single-use authentication mechanisms
FIA_UAU.5 Multiple authentication mechanisms
FIA: Identification and
Authentication
FIA_UAU.6 Re-authenticating
FDP_ACC.1 Subset access control
FDP_ACF.1 Basic Security attribute based access control
FDP_UCT.1 Basic data exchange confidentiality
FDP: User Data Protection
FDP_UIT.1 Data exchange integrity
FMT_SMF.1 Specification of Management Functions
FMT_SMR.1 Security roles
FMT_LIM.1 Limited capabilities
FMT_LIM.2 Limited availability
FMT_MTD.1/INI_ENA Management of TSF data
FMT_MTD.1/INI_DIS Management of TSF data
FMT_MTD.1/KEY_WRITE Management of TSF data
FMT: Security Management
FMT_MTD.1/KEY_READ Management of TSF data
FPT_EMSEC.1 TOE Emanation
FPT_FLS.1 Failure with preservation of secure state
FPT_TST.1 TSF testing
FPT: Protection of the Security
Functions
FPT_PHP.3 Resistance to physical attack
Active Authentication
FCS_COP.1/SIG_MRTD Cryptographic Operation
FCS: Cryptographic Support
FCS_CKM.1/ASYM Cryptographic key generation
FDP_DAU.1/AA Basic Data Authentication
FDP: User Data Protection
FDP_ITC.1/AA Import of user data without security attributes
FMT: Security Management FMT_MOF.1/AA Management of security functions behaviour
Basic Access Protocol (BAP)
FCS_COP.1/BAP Cryptographic Operation
FCS_CKM.1/BAP Cryptographic key generation
FCS: Cryptographic Support
FCS_COP.1/BAP-SM Cryptographic Operation
IDENTIFICATION
Product: LDS EAC Java Applet in BAP configuration with AA v2.2
Security Target: Polymnie Security Target BAP issue:7.
Protection Profile: No conformance to any Protection Profile is claimed.
Evaluation Level: Common Criteria version 3.1 revision 3 EAL4 + ALC_DVS.2.
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 7 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
SECURITY POLICIES
The use of the product LDS EAC Java Applet in BAP configuration with AA v2.2 shall
implement a set of security policies assuring the fulfilment of different standards and
security demands.
The detail of these policies is documented in the Security Target. In short, it
establishes the need of implementing organisational policies related to the following
aspects.
Policy 01: P.Manufact
The Initialization Data are written by the IC Manufacturer to identify the IC uniquely.
The MRD Manufacturer writes the Pre-personalization Data which contains at least
the Personalization Agent Key.
Policy 02: P.Personalization
The issuing Organisation guarantees the correctness of the biographical data, the
printed portrait and the digitized portrait, the biometric reference data and other data
of the logical MRD with respect to the MRD holder. The personalization of the MRD
for the holder is performed by an agent authorized by the issuing Organisation only.
Policy 03: P.Personal_Data
The biographical data and their summary printed in the Keydoc and stored on the
MRD's chip, the printed portrait and the digitized portrait, the biometric reference
data of finger(s), the biometric reference data of iris image(s) and data according to
LDS stored on the MRD's chip are personal data of the MRD holder. These data
groups are intended to be used only with agreement of the MRD holder by inspection
systems to which the MRD is presented. The MRD's chip shall provide the possibility
for the Basic Access Protection to allow read access to these data only for terminals
successfully authenticated based on knowledge of the Document Basic Access Keys
as defined in [ICAO_P1].
Those data are stored in DGs as specified by in EF.COM.
Policy 04: P.Sensitive_Data_Protection
All the sensitive data are at least protected in integrity. The keys are protected in
both integrity and confidentiality.
Policy 05: P.Key_Function
All the cryptographic routines are designed in such a way that they are protected
against probing and do not cause any information leakage that may be used by an
attacker.
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 8 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
ASSUMPTIONS AND OPERATIONAL ENVIRONMENT
The following assumptions are constraints to the conditions used to assure the
security properties and functionalities compiled by the security target. These
assumptions have been applied during the evaluation in order to determine if the
identified vulnerabilities can be exploited.
In order to assure the secure use of the TOE, it is necessary to start from these
assumptions for its operational environment. If this is not possible and any of them
could not be assumed, it would not be possible to assure the secure operation of the
TOE.
Assumption 01: A.MRD_Manufact
It is assumed that appropriate functionality testing of the MRD is used. It is assumed
that security procedures are used during all manufacturing and test operations to
maintain confidentiality and integrity of the MRD and of its manufacturing and test
data (to prevent any possible copy, modification, retention, theft or unauthorized
use).
Assumption 02: A.MRD_Delivery
Procedures shall guarantee the control of the TOE delivery and storage process and
conformance to its objectives:
‐ Procedures shall ensure protection of TOE material/information under delivery
and storage.
‐ Procedures shall ensure that corrective actions are taken in case of improper
operation in the delivery process and storage.
‐ Procedures shall ensure that people dealing with the procedure for delivery
have got the required skill.
Assumption 03: A.Pers_Agent
The Personalization Agent ensures the correctness of(i) the logical MRD with
respect to the MRD holder, (ii) the Document Basic Access Keys, (iii) the Chip
Authentication Public Key if stored on the MRD's chip, and (iv) the Document Signer
Public Key Certificate (if stored on the MRD'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.
Assumption 04: A.Insp_Sys
The Inspection System is used by the officer of the receiving Organisation (i)
examining an MRD presented by the holder and verifying its authenticity and (ii)
verifying the holder as MRD holder. The Basic Inspection System for global
interoperability (i) includes the Organisation Signing Public Key and the Document
Signer Public Key of each issuing Organisation, and (ii) implements the terminal part
of the Basic Access Protection [ISO18013-3]. The Basic Inspection System reads
the logical MRD under Basic Access Protection and performs the Passive
Authentication to verify the logical MRD.
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 9 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
Assumption 05: A.BAP-Keys
The Document Basic Access Protection Keys being generated and imported by the
issuing Organisation have to provide sufficient cryptographic strength. As a
consequence of the "ICAO Doc 9303" [ICAO_P1] and "ISO 18013-3" [ISO18013-3],
the Document Basic Access Protection Keys are derived from a defined subset of
the individual printed Keydoc data. It has to be ensured that these data provide
sufficient entropy to withstand any attack based on the decision that the inspection
system has to derive Document Access Keys from the printed Keydoc data with
enhanced basic attack potential.
CLARIFICATIONS ON NON-COVERED THREATS
The following threats do not suppose a risk for the product LDS EAC Java Applet in
BAP configuration with AA v2.2, although the agents implementing attacks have a
enhanced-basic attack potential according to the assurance level of EAL4 +
ALC_DVS.2 and always fulfilling the usage assumptions and the proper security
policies satisfaction.
For any other threat not included in this list, the evaluation results of the product
security properties and the associated certificate, do not guarantee any resistance.
The threats covered by the security properties of the TOE are categorized below.
Threat 01: T.Chip_ID
Adverse action: An attacker trying to trace the movement of the MRD by identifying
remotely the MRD's chip by establishing or listening to
communications through the contactless communication interface.
Threat agent: having enhanced basic attack potential, not knowing the optically
readable Keydoc data printed on the MRD data page in advance
Asset: Anonymity of user
Threat 02: T.Skimming
Adverse action: An attacker imitates an inspection system trying to establish a
communication to read the logical MRD or parts of it via the
contactless communication channel of the TOE.
Threat agent: having enhanced basic attack potential, not knowing the optically
readable Keydoc data printed on the MRD data page in advance.
Asset: confidentiality of logical MRD data.
Threat 03: T.Eavesdropping
Adverse action: An attacker is listening to an existing communication between the
MRD's chip and an inspection system to gain the logical MRD or
parts of it. The inspection system uses the Keydoc data printed on
the MRD data page but the attacker does not know these data in
advance.
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 10 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
Threat agent: having enhanced basic attack potential, not knowing the optically
readable Keydoc data printed on the MRD data page in advance.
Asset: confidentiality of logical MRD data.
Threat 04: T.Forgery
Adverse action: An attacker alters fraudulently the complete stored logical MRD or
any part of it including its security related data in order to deceive on
an inspection system by means of the changed MRD holder"s
identity or biometric reference data. This threat comprises several
attack scenarios of MRD forgery. The attacker may alter the
biographical data on the biographical data page of the passport
book, in the printed Keydoc and in the digital Keydoc to claim
another identity of the holder. 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 MRDs to create a new forged MRD,
e.g. the attacker writes the digitized portrait and optional biometric
reference finger data read from the logical MRD of a holder into
another MRD's chip leaving their digital Keydoc unchanged to claim
the identity of the holder this MRD. The attacker may also copy the
complete unchanged logical MRD to another contactless chip.
Threat agent: having enhanced basic attack potential, being in possession of one
or more legitimate MRDs.
Asset: authenticity of logical MRD data.
Threat 05: T.Abuse-Func
Adverse action: 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 Organisation after delivery
to MRD holder.
Threat agent: having enhanced basic attack potential, being in possession of a
legitimate MRD.
Asset: confidentiality and authenticity of logical MRD and TSF data,
correctness of TSF.
Threat 06: T.Information_Leakage
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 11 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
Adverse action: An attacker may exploit information which is leaked from the TOE
during its usage in order to disclose confidential TSF data. The
information leakage may be inherent in the normal operation or
caused by the attacker. Leakage may occur through emanations,
variations in power consumption, I/O characteristics, clock
frequency, or by changes in processing time requirements. This
leakage may be interpreted as a covert channel transmission but is
more closely related to measurement of operating parameters,
which may be derived either from measurements of the contactless
interface (emanation) or direct measurements (by contact to the chip
still available even for a contactless chip) and can then be related to
the specific operation being performed. Examples are the Differential
Electromagnetic Analysis (DEMA) and the Differential Power
Analysis (DPA). Moreover the attacker may try actively to enforce
information leakage by fault injection (e.g. Differential Fault
Analysis).
Threat agent: having enhanced basic attack potential, being in possession of a
legitimate MRD.
Asset: confidentiality of logical MRD and TSF data.
Threat 07: T.Phys-Tamper
Adverse action: An attacker may perform physical probing of the MRD's chip in order
(i) to disclose TSF Data or (ii) to disclose/reconstruct the MRD's chip
Embedded Software. An attacker may physically modify the MRD's
chip in order to (i) modify security features or functions of the MRD's
chip, (ii) modify security functions of the MRD'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
MRD'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 MRD's chip internals. Techniques
commonly employed in IC failure analysis and IC reverse
engineering efforts may be used. Before that, the hardware security
mechanisms and layout characteristics need to be identified.
Determination of software design including treatment of User Data
and TSF Data may also be a pre-requisite. The modification may
result in the deactivation of a security function. Changes of circuitry
or data can be permanent or temporary.
Threat agent: having enhanced basic attack potential, being in possession of a
legitimate MRD.
Asset: confidentiality and authenticity of logical MRD and TSF data,
correctness of TSF.
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 12 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
Threat 08: T.Malfunction
Adverse action: An attacker may cause a malfunction of TSF or of the MRD'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 MRD's chip
Embedded Software.
This may be achieved e.g. by operating the MRD's chip outside the
normal operating conditions, exploiting errors in the MRD's chip
Embedded Software or misusing administration function. To exploit
these vulnerabilities an attacker needs information about the
functional operation.
Threat agent: having enhanced basic attack potential, being in possession of a
legitimate MRD.
Asset: confidentiality and authenticity of logical MRD and TSF data,
correctness of TSF.
Threat 09: T.Counterfeit
Adverse action: An attacker with enhanced basic attack potential produces an
unauthorized copy or reproduction of a genuine MRD's chip to be
used as part of a counterfeit MRD. This violates the authenticity of
the MRD's chip used for authentication of a traveller by possession
of a MRD. The attacker may generate a new data set or extract
completely or partially the data from a genuine MRD's chip and copy
them on another appropriate chip to imitate this genuine MRD's chip.
Threat agent: having enhanced basic attack potential, being in possession of one
or more legitimate MRDs.
Asset: authenticity of logical MRTD data.
OPERATIONAL ENVIRONMENT FUNCTIONALITY
The product requires the cooperation from its operational environment to fulfil some
of the objectives of the defined security problem.
The security objectives declared for the TOE operational environment are
categorized below.
Environment objective 01: OE.MRD_Manufact
Appropriate functionality testing of the TOE shall be used in step 4 to 6.
During all manufacturing and test operations, security procedures shall be used through
phases 4, 5 and 6 to maintain confidentiality and integrity of the TOE and its
manufacturing and test data.
Environment objective 02: OE.MRD_ Delivery
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 13 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
Procedures shall ensure protection of TOE material/information under delivery including the
following objectives:
‐ non-disclosure of any security relevant information, o identification of the element
under delivery,
‐ meet confidentiality rules (confidentiality level, transmittal form, reception
acknowledgment),
‐ physical protection to prevent external damage,
‐ secure storage and handling procedures (including rejected TOE"s),
‐ traceability of TOE during delivery including the following parameters:
o origin and shipment details,
o reception, reception acknowledgement,
o location material/information.
Procedures shall ensure that corrective actions are taken in case of improper operation in
the delivery process (including if applicable any non-conformance to the confidentiality
convention) and highlight all non-conformance to this process.
Procedures shall ensure that people (shipping department, carrier, reception department)
dealing with the procedure for delivery have got the required skill, training and knowledge to
meet the procedure requirements and be able to act fully in accordance with the above
expectations.
Environment objective 03: OE.Personalization
The issuing Organisation must ensure that the Personalization Agents acting on behalf of
the issuing Organisation (i) establish the correct identity of the holder and create
biographical data for the MRD, (ii) enroll the biometric reference data of the MRD holder i.e.
the portrait, the encoded finger image(s) and/or the encoded iris image(s) and (iii)
personalize the MRD for the holder together with the defined physical and logical security
measures to protect the confidentiality and integrity of these data.
Environment objective 04: OE.Pass_Auth_Sign
The issuing Organisation must (i) generate a cryptographic secure Organisation Signing CA
Key Pair, (ii) ensure the secrecy of the Organisation Signing CA Private Key and sign
Document Signer Certificates in a secure operational environment, and (iii) distribute the
Certificate of the Organisation Signing CA Public Key to receiving Organisations and
Organizations maintaining its authenticity and integrity. The issuing Organisation 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 MRD in a
secure operational environment only and (iii) distribute the Certificate of the Document
Signer Public Key to receiving Organisations and Organizations. The digital signature in the
Document Security Object relates all data in the data in EF.DG1 to EF.DG24 if stored in the
LDS according to [ICAO_P1,[ISO18013-2] ].
Environment objective 05: OE.BAP-Keys
The Document Basic Access Protection Keys being generated and imported by the issuing
Organisation have to provide sufficient cryptographic strength. As a consequence of the
"ICAO Doc 9303" [ICAO_P1] and "ISO 18013-3" [ISO18013-3] , the Document Basic Access
Protection Keys are derived from a defined subset of the individual printed Keydoc data. It
has to be ensured that these data provide sufficient entropy to withstand any attack based
on the decision that the inspection system has to derive Document Basic Access Keys from
the printed Keydoc data with enhanced basic attack potential.
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 14 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
Receiving State or Organization
The receiving State or Organization will implement the following security objectives of the
TOE environment.
Environment objective 06: OE.Exam_MRD
The inspection system of the receiving Organisation must examine the MRD
presented by the holder to verify its authenticity by means of the physical security
measures and to detect any manipulation of the physical MRD. The Basic Inspection
System for global interoperability (i) includes the Organisation Signing Public Key
and the Document Signer Public Key of each issuing Organisation, and (ii)
implements the terminal part of the Basic Access Protection [ISO18013-3] .
Environment objective 07: OE.Passive_Auth_Verif
The officer of the receiving Organisation uses the inspection system to verify the
holder as MRD holder. The inspection systems must have successfully verified the
signature of Document Security Objects and the integrity data elements of the logical
MRD before they are used. The receiving Organisations and Organizations must
manage the Organisation Signing Public Key and the Document Signer Public Key
maintaining their authenticity and availability in all inspection systems.
Environment objective 08: OE.Prot_Logical_MRD
The inspection system of the receiving Organisation ensures the confidentiality and
integrity of the data read from the logical MRD. The receiving Organisation
examining the logical MRD being under Basic Access Protection will use inspection
systems which implement the terminal part of the Basic Access Protection and use
the secure messaging with fresh generated keys for the protection of the transmitted
data (i.e. Basic Inspection Systems).
The details of the product operational environment (assumptions, threats and
organisational security policies) and the TOE security requirements are detailed in
the associated security target.
ARCHITECTURE
The Target of Evaluation (TOE) is a smartcard composed of the following
components:
‐ An ID One Cosmo v7.0.1-n JavaCard platform including Global Platform
support and a cryptographic library,
‐ An LDS applet providing the BAP features loaded on the platform.
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 15 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
DOCUMENTS
The product includes the following documents that shall be distributed and made
available together to the users of the evaluated version.
‐ Polymnie AGD_OPE ed.2
o Code: FQR 220 0437 Edition: 2 Date: 14/12/2011
o The current document aims at ensuring Common Criteria requirements
for the POLYMNIE project by fully describing the AGD_OPE.
‐ Polymnie AGD_PRE ed.3
o Code: FQR 220 0406 Edition: 3 Date: 27/01/2012
o The current document aims at ensuring Common Criteria requirements
for the POLYMNIE project by fully describing the AGD_PRE.
‐ LDS EAC V2.2 Java Applet SOFTWARE REQUIREMENTS
SPECIFICATIONS SRS v edAB.
o Code: 067007 00 Edition: 7-AB Date: 26/01/2011
o This document defines the functional characteristics of the Oberthur
Technologies LDS EAC applet. It contains the full description of the
supported file structure elements, as well as the APDU commands
available during the personalization phase and the use phase.
PRODUCT TESTING
The evaluation has been performed according to the composite evaluation
methodology defined in the guides [COMP_JIL] and [COMP_CCRA] in order to
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 16 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
assess that the combination of the TOE with the underlying platform did not lead to
any exploitable vulnerability. The Java Card Platform and the microcontroller have
already been certified.
This evaluation has then taken into account the evaluation results and security
recommendations for the following platforms which are part of the evaluated
composite TOE:
 ANSSI-CC-2011/64
 ANSSI-CC-2010/40
 BSI-DSZ-CC-0645-2010
 BSI-DSZ-CC-0555-2009
The developer has executed test for all the declared security functions. All the tests
have been performed by the developer in its premises, with a satisfactory result.
During the evaluation process it has been verified each unit test checking that the
security functionality that covers is been identified and also that the kind of test is
appropriate to the function that is intended to test.
All the tests have been developed using the testing scenario appropriate to the
established architecture in the security target. It has also been checked that the
obtained results during the tests fit or correspond to the previously estimated results.
To verify the results of the developer tests, the evaluation team has applied a
sampling strategy and concluded that the given information is complete and coherent
to reproduce tests and identify the functionality tested. Moreover, additional tests
where proposed independently of the developer. These tests covered ePassport
BAP functionalities and tested the underlying RNG.
It has been checked that the obtained results conform to the expected results and in
the cases where a deviation in respect to the expected results was present, the
evaluator has confirmed that this variation neither represents any security problem
nor a decrease in the functional capacity of the product.
PENETRATION TESTING
Based on the list of potential vulnerabilities applicable to the TOE in its operational
environment, the evaluation team has devised attack scenarios for penetration tests
according to JIL supporting documents such as [JILAAPS]. Within these activities all
aspects of the security architecture which were not covered by functional testing
have been considered.
The implementation of the requirements of the provided platform’s ETR for
Composition and guidance, as well as of the security mechanisms of the applet in
general has been verified by the evaluation team. An appropriate test set was
devised to cover these potential vulnerabilities.
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 17 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
The overall test result is that no deviations were found between the expected and the
actual test results. No attack scenario with the attack potential Enhanced-Basic has
been successful in the TOE’s operational environment as defined in the security
target when all measures required by the developer are applied.
EVALUATED CONFIGURATION
The TOE is defined by its name and version number LDS EAC Java Applet in BAP
configuration with AA v2.2.
The composite TOE includes:
‐ the integrated circuit, IC NXP Secure Smart Card Controllers P5CD081V1A or
P5CD145V0A
‐ the Java Card Platform ID One Cosmo v7.0.1-n masked in one of the above
ICs including Global Platform support and a cryptographic library,
‐ the LDS EAC Java Applet in BAP configuration with AA v2.2
‐ the associated guidance documentation.
The commercial version and internal version of the applet may be retrieved by
following the procedure below (see AGD_OPE ed.2):
1. Select the applet
2. Perform BAC or BAP if BAC/BAP is supported
3. Send GET DATA command with the tag "DF66" to retrieve the commercial
version of the applet (see GET DATA in AGD_OPE). The applet shall return:
"DF66 0A 067007 02020100 000000"
4. Send GET DATA command with the tag "DF67" to retrieve the internal version
of the applet (see GET DATA).
a. The applet shall return: "DF67 0E 30 0C 04040A00060D
04040F0F0F0E” if stub EAC package is loaded (BAP configuration).
5. Send GET DATA command with the tag "DF63" to retrieve the EAC
configuration of the applet (see GET DATA).
a. The applet is configured in BAC if the BAC/BAP configuration byte
indicates 001xxxxxb for BAP-1, 010xxxxxb for BAP-2, 011xxxxxb for
BAP-3, and 100xxxxxb for BAP-4.
EVALUATION RESULTS
The product LDS EAC Java Applet in BAP configuration with AA v2.2 has been
evaluated against the Security Target Polymnie Security Target BAP issue: 7.
All the assurance components required by the evaluation level EAL4 + ALC_DVS.2
have been assigned a “PASS” verdict. Consequently, the laboratory Applus LGAI
Technological Center S.A. assigns the “PASS” VERDICT to the whole evaluation
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 18 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
due all the evaluator actions are satisfied for the evaluation level EAL4 +
ALC_DVS.2, as defined by the Common Criteria version 3.1 revision 3 and the
Common Methodology for Information Technology Security Evaluation version 3.1
revision 3.
COMMENTS & RECOMMENDATIONS FROM THE
EVALUATION TEAM
Next, recommendations regarding the secure usage of the TOE are provided. These
have been collected along the evaluation process and are detailed to be considered
when using the product.
‐ The developer follows all the underlying platform security recommendations
and contributes with additional countermeasures to enforce the security of the
whole product. Therefore the LDS EAC Java Applet in BAP configuration with
AA, Version 2.2 fulfils the requirements of CC version 3.1 with an evaluation
assurance level EAL4 + ALC_DVS.2.
CERTIFIER RECOMMENDATIONS
Considering the obtained evidences during the instruction of the certification request
of the product LDS EAC Java Applet in BAP configuration with AA v2.2, a positive
resolution is proposed.
Additionally, the Certification Body wants to remark to the TOE’s consuming
organizations the following:
‐ Oberthur’s Project Leader at Manilla’s facilities plays a key role in the security
procedures followed to generate the TOE. Project Leader at this facility
assures by following the security procedures that the generated TOE reflects
its implementation representation managed in the Configuration Management
System.
GLOSSARY
AA Active Authentication
BAC Basic Access Control
CC Common Criteria
CCN Centro Criptológico Nacional
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 19 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
CNI Centro Nacional de Inteligencia
DG Data Group
EAL Evaluation Assurance Level
ETR Evaluation Technical Report
ICAO International Civil Aviation Organization
IDL ISO compliant Driving Licence
LDS Logical Data structure
MRTD Machine readable Travel Document
MRZ Machine readable Zone
OC Organismo de Certificación
ST Security Target
TOE Target Of Evaluation
BIBLIOGRAPHY
The following standards and documents have been used for the evaluation of the
product:
[CC_P1] Common Criteria for Information Technology Security Evaluation Part 1:
Introduction and general model, Version 3.1, R3 Final, July 2009.
[CC_P2] Common Criteria for Information Technology Security Evaluation Part 2:
Security functional components, Version 3.1, R3 Final, July 2009.
[CC_P3] Common Criteria for Information Technology Security Evaluation Part 3:
Security assurance components, Version 3.1, R3 Final, July 2009.
[CEM] Common Methodology for Information Technology Security Evaluation:
Version 3.1, R3 Final, July 2009.
[JILCOMP] Composite product evaluation for Smart Cards and similar devices
version 1.2. Jan. 2012.
[CCCOMP] Composite product evaluation for Smartcards and similar devices
Version 1.0. Sept. 2007.
[JILAAPS] Application of Attack Potential to Smartcards, Version 2.7. March 2009.
[PP-EAC] Common Criteria Protection Profile Machine Readable Travel Document
with ICAO Application, Extended Access Control, version 1.10. BSI-CC-PP-0056.
Version 1.10. March 2009.
[PP-BAC] Common Criteria Protection Profile Machine Readable Travel Document
with “ICAO Application", Basic Access Control, BSI-PP-0055, Version 1.10, March
2009
MINISTERIO DE LA PRESIDENCIA
CENTRO NACIONAL DE INTELIGENCIA
CENTRO CRIPTOLÓGICO NACIONAL
ORGANISMO DE CERTIFICACIÓN
Página 20 de 20
Avenida del Padre Huidobro s/n
Fax: + 34 91 372 58 08
Email: organismo.certificacion@cni.es
[ICAO_P1] ICAO Doc 9303, Machine Readable Travel Documents, part 1 –
Machine Readable Passports, Sixth Edition, 2006, International Civil Aviation
Organization
[ISO18013-1] Information Technology - Personal Identification – ISO Compliant
Driving Licence – Part 1:Physical characteristics and basic data set, ISO/IEC FDIS
18013-1:2005(E)
[ISO18013-2] Information Technology - Personal Identification — ISO Compliant
Driving Licence — Part 2: Machine-readable technologies, ISO/IEC FDIS 18013-
2:2007(E)
[ISO18013-3] Personal Identification — ISO Compliant Driving Licence — Part 3:
Access control, authentication and integrity validation, ISO/IEC FDIS 18013-
3:2008(E)
SECURITY TARGET
Along with the certification report, the complete security target for the evaluation is
stored and protected in the Certification Body premises. This document is identified
as:
‐ Polymnie Security Target BAP issue:7 – Document id: FQR:110 5694
The public version of this document constitutes the ST Lite. The ST Lite has also
been evaluated for the needs of publication according to [CCDB-2006-04-004], and it
is published along with this certification report in the Certification Body and CCRA
websites. The ST Lite identifier is:
‐ Polymnie Security Target BAP Ed. 2 – Document id: FQR 110 6343 Ed.2