the security technology
provider
Gep S.p.A.
Corso Salvatore D’Amato, 90
80022 Arzano (NA)
ITALY
http://www.gepitalia.it
This document may not be modified or partially reused without prior written consent of Gep S.p.A
Security Target Lite
SOMA801NXP Electronic Passport
Basic Access Control
Common Criteria version 3.1 revision 3 – ISO/IEC 15408
Assurance Level EAL 4+
Version 1.0
Date 2012-05-16
Reference TCLE120006
Classification PUBLIC
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 2 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Version control
Version Date Author Revision Description
1.0 2012-05-16 Marco EVANGELISTA First version
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 3 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table of Contents
1. Introduction ...............................................................................................................6
1.1 ST Overview..........................................................................................................6
1.2 ST reference..........................................................................................................6
1.3 TOE reference.......................................................................................................7
1.4 TOE overview........................................................................................................8
1.4.1 TOE Definition................................................................................................8
1.4.2 TOE Usage and security features for operational use....................................8
1.4.3 TOE Life-cycle..............................................................................................10
1.4.4 Non-TOE hardware/software/firmware required by the TOE........................15
1.5 TOE Description ..................................................................................................15
1.5.1 Physical scope of the TOE ...........................................................................15
1.5.2 Other non-TOE physical components ..........................................................16
1.5.3 Logical scope of the TOE .............................................................................16
2. Conformance claims ...............................................................................................18
2.1 Common Criteria Conformance...........................................................................18
2.2 Protection Profile Conformance...........................................................................18
2.3 Package Conformance........................................................................................18
2.4 Conformance Rationale.......................................................................................18
3. Security Problem Definition.....................................................................................20
3.1 Introduction..........................................................................................................20
3.1.1 Assets...........................................................................................................20
3.1.2 Subjects........................................................................................................20
3.2 Assumptions........................................................................................................22
3.3 Threats ................................................................................................................24
3.4 Organizational Security Policies ..........................................................................27
4. Security Objectives .................................................................................................29
4.1 Security Objectives for the TOE ..........................................................................29
4.2 Security Objectives for the Operational Environment ..........................................32
4.3 Security Objective Rationale ...............................................................................34
5. Extended Components Definition............................................................................38
5.1 Definition of the family FAU_SAS........................................................................38
5.2 Definition of the family FCS_RND .......................................................................38
5.3 Definition of the family FMT_LIM.........................................................................39
5.4 Definition of the family FPT_EMSEC...................................................................41
6. Security Requirements............................................................................................43
6.1 Security Functional Requirements for the TOE ...................................................43
6.1.1 Class FAU Security Audit .............................................................................43
6.1.2 Class Cryptographic Support (FCS).............................................................44
6.1.3 Class FIA Identification and Authentication ..................................................48
6.1.4 Class FDP User Data Protection..................................................................54
6.1.5 Class FMT Security Management ................................................................57
6.1.6 Class FPT Protection of the Security Functions ...........................................62
6.2 Security Assurance Requirements for the TOE...................................................65
6.3 Security Requirements Rationale ........................................................................65
6.3.1 Security functional requirements rationale....................................................65
6.3.2 Dependency Rationale .................................................................................69
6.3.3 Security Assurance Requirements Rationale ...............................................72
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 4 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
6.3.4 Security Requirements – Mutual Support and Internal Consistency.............72
7. TOE Summary Specification ...................................................................................73
7.1 Coverage of SFRs...............................................................................................73
7.1.1 SS.AG_ID_AUTH Agents Identification & Authentication.............................73
7.1.2 SS.SEC_MSG Data exchange with Secure Messaging ..............................74
7.1.3 SS.ACC_CNTRL Access Control of stored Data Objects.............................74
7.1.4 SS.LFC_MNG Life cycle management.........................................................75
7.1.5 SS.SW_INT_CHECK Software integrity check of TOE’s assets ..................75
7.1.6 SS.SF_HW Security features provided by the hardware..............................75
7.2 Assurance Measures...........................................................................................77
8. References..............................................................................................................80
8.1 Acronyms ............................................................................................................80
8.2 Glossary ..............................................................................................................81
8.3 Technical References..........................................................................................88
List of Tables
Table 1-1 ST Identification.................................................................................................6
Table 1-2 TOE Identification ..............................................................................................7
Table 1-3 Roles Identification ..........................................................................................13
Table 2-1 Modified security objectives.............................................................................19
Table 2-2 SFRs assignment changes, refinements, iterations and additions...................19
Table 4-1 Security Objective Rationale............................................................................35
Table 5-1 Family FAU_SAS.............................................................................................38
Table 5-2 Family FCS_RND ............................................................................................39
Table 5-3 Family FMT_LIM..............................................................................................40
Table 5-4 Family FPT_EMSEC........................................................................................42
Table 6-1 – Overview on authentication SFR ....................................................................49
Table 6-2 FIA_AFL.1 Refinement ....................................................................................54
Table 6-3 Assurance requirements at EAL4+ ..................................................................65
Table 6-4 Coverage of Security Objectives for the TOE by SFR .....................................65
Table 6-5 Dependencies between the SFR for the TOE..................................................70
Table 7-1 Summary of authentication mechanisms .........................................................73
Table 7-2 Mapping between SFRs and TOE security services........................................77
Table 7-3 Assurance Requirements documentation ........................................................79
List of Figures
Figure 1-1 TOE life-cycle .................................................................................................12
Figure 1-2 Inlay components ...........................................................................................16
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 5 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Abbreviations and Notations
Numerical values
Numbers are printed in decimal, hexadecimal or binary notation.
Hexadecimal values are indicated with a ‘h’ suffix as in XXh, where X is a hexadecimal
digit from 0 to F.
Decimal values have no suffix.
Example: the decimal value 179 may be noted as the hexadecimal value B3h.
Denoted text
The text added to provide details on how the TOE implementation fulfils some security
requirements is written in italics and is preceded by the numbered tag “Application Note”.
Refinements to the security requirements are denoted by the tag “Refinement” and are
written in bold text.
Selections and assignments made by the Protection Profile authors are written in
underlined text.
Selections and assignments made by the authors of this ST are written in underlined bold
text.
Iterations are denoted by showing a slash “/”, and the iteration indicator after the
component indicator.
The original text of the selection and assignment components, as defined by the Common
Criteria, is given by a footnote.
Key words
The words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” are to be interpreted as
described in RFC2119 [R16].
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 6 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
1. Introduction
1.1 ST Overview
This Security Target (ST) document defines the security requirements and the scope of
the Common Criteria evaluation of the SOMA801NXP electronic passport. The Target Of
Evaluation (TOE) is the contactless integrated circuit chip NXP Semiconductors P5CD081,
programmed with the operating system and with the ICAO passport application. The TOE
adds security features to a passport booklet, providing machine-assisted identity
confirmation and machine-assisted verification of document security.
This ST covers the Basic Access Control (BAC) mechanism only, as defined by the ICAO
Doc 9303 [R14][R15]. The Extended Access Control (EAC) is covered by an other ST
[R13].
The SOMA801NXP passport was developed in full accordance with specifications for a
Machine Readable Travel Document (MRTD) defined by the International Civil Aviation
Organization (ICAO). ICAO Doc 9303 [R14] [R15] details technical properties and security
features of such a travel document, as well as recommendations for the security
environment in which it operates.
The TOE is meant for “global interoperability”. According to ICAO the term is understood
as “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”.
The TOE is supplied with a file system, that contains all the data that is used in the context
of the ICAO application as described in the Protection Profiles [R5][R6].
1.2 ST reference
Table 1-1 ST Identification
Title
Security Target Lite SOMA801NXP Electronic Passport
Basic Access Control
Version 1.0
Author Marco EVANGELISTA
Reference TCLE120006
Keywords Security target, protection profile, common criteria
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 7 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
1.3 TOE reference
Table 1-2 TOE Identification
Product Name SOMA801NXP
Product Version 1.0
TOE Identification Data
53h 4Fh 4Dh 41h 38h 30h 31h 4Eh 58h 50h 5Fh 31h
5Fh 30h
Evaluation Criteria Common Criteria version 3.1 revision 3
Protection Profile BSI-CC-PP-0055
Evaluation Assurance Level EAL 4 augmented with ALC_DVS.2
Developer Gep S.p.A.
Evaluation Sponsor Gep S.p.A.
Evaluation Facility SERMA Technologies’ ITSEF
Certification Body
ANSSI – Agence Nationale de la Sécurité des Systèmes
d’Information
Certification ID SOMA-NXP
Keywords
electronic passport, e-Passport, ICAO, machine
readable travel document, basic access control, BAC
The TOE identification data is located in the non-volatile memory of the chip. Instructions
for reading identification data are provided by the pre-personalization guidance, the
personalization guidance and the user guidance.
The TOE is identified by the following string, representing the Global Reference:
SOMA801NXP_1_0
(ASCII codes 53h 4Fh 4Dh 41h 38h 30h 31h 4Eh 58h 50h 5Fh 31h 5Fh 30h)
The first four bytes of the identification data identify the operating system. Bytes from 5 to
10 contain the IC identifier. Last three bytes encode ROM code and patch version (also
known as OS version). Bytes 11 and 13 are field separators.
The parts of the Global Reference data have the following meaning:
• OS identifier: SOMA (ASCII codes 53h 4Fh 4Dh 41h)
• IC identifier: 801NXP (ASCII codes 38h 30h 31h 4Eh 58h 50h)
• ROM code version: 1 (ASCII code 31h)
• Patch version: 0 (ASCII code 30h)
Application Note 1: The OS version is composed of a major version number, indicating
the ROM code version, and of a minor version number, indicating the patch version. The
major version number and the minor version number are separated by the character “_”
(underscore, ASCII code 5Fh). A minor version number 0 (ASCII code 30h) indicates that
no patch is loaded.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 8 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
1.4 TOE overview
1.4.1 TOE Definition
The TOE is the contactless integrated circuit of MRTD programmed according to the
Logical Data Structure (LDS) [R14] and providing Basic Access Control, according to Doc
9303 [R14], and Extended Access Control as defined in the technical guideline BSI TR-
03110 [R7].
On account of its composite nature, the TOE evaluation builds on the evaluation of the
integrated circuit.
The chip is equipped with an operating system and with a software application providing
the passport features. The TOE adds security features to an ordinary passport booklet.
Cryptographic techniques are applied to confirm the identity of the holder and to verify the
authenticity of the passport.
The TOE is connected to an antenna for wireless communication. Both the TOE and the
antenna are embedded in a paper or plastic substrate, that provides mechanical support
and protection. The resulting device (TOE, antenna and substrate), is called “inlay” as it is
intended to be inserted in a passport booklet (see section 1.4.3.2).
Once personalized with the data of the legitimate holder and with security data, the e-
Passport can be inspected by authorized agents.
The product provides a number of security features to prevent forgery, tampering and data
leakage. Such features include:
• User authentication based on 112 bit symmetric key cryptography to protect the
overall content of the passport
• Additional user authentication based on up to 2048 bit asymmetric key cryptography
to protect sensitive biometric data such as fingerprints and iris image.
• Sophisticated on-chip sensors to detect physical attacks
• Memory management unit to prevent improper usage of memory and unauthorized
code execution.
• Encrypted communications between the passport and the Inspection System
In the operational use, the integrated circuit, along with its OS and application, provides
the following authentication mechanisms:
• Basic Access Control, according to the ICAO Doc 9303 [R14]
• Extended Access Control, implemented combining the Chip Authentication protocol
with the Terminal Authentication protocol, as defined in the BSI TR-03110 technical
guideline [R7]
The TOE is comprised of:
• the circuitry of the MRTD’s chip NXP P5CD081,
• the IC Dedicated Software with the parts IC Dedicated Test Software and IC
Dedicated Support Software,
• the IC Embedded Software (SOMA801NXP Operating System),
• the MRTD application and
• the associated guidance documentation.
1.4.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 a MRTD to the inspection system to prove his or her identity.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 9 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
The MRTD in context of this protection profile contains
i. visual (eye readable) biographical data and portrait of the holder,
ii. a separate data summary (MRZ data) for visual and machine reading using
OCR methods in the Machine readable zone (MRZ) and
iii. data elements on the MRTD’s chip according to LDS for contactless machine
reading.
The authentication of the traveler is based on:
• the possession of a valid MRTD personalized for the traveler with the claimed
identity as given on the biographical data page and
• biometrics using the reference data stored in the MRTD chip.
The Issuing State or Organization ensures the authenticity of the data of genuine MRTDs.
The receiving state trusts a genuine MRTD of an Issuing State or Organization.
For this security target the MRTD is viewed as the unit of:
• the physical MRTD as travel document in the form of paper, plastic and chip. It
presents visual readable data including (but not limited to) personal data of the
MRTD holder:
i. the biographical data on the biographical data page of the passport
booklet,
ii. the printed data in the Machine-Readable Zone (MRZ),
iii. the printed portrait
• the logical MRTD as data of the MRTD holder stored according to the Logical Data
Structure [R12] 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:
i. the digital Machine Readable Zone Data (digital MRZ data, EF.DG1),
ii. the digitized portraits (EF.DG2),
iii. the biometric reference data of finger(s) (EF.DG3) or iris image(s)
(EF.DG4) or both1
;
iv. the other data according to LDS (EF.DG5 to EF.DG14, EF.DG16)
v. the Document security object (SOD),
vi. security data objects required for product management.
The Issuing State or Organization implements security features of the MRTD to maintain
the authenticity and integrity of the MRTD and its data. The MRTD as the passport book
and the MRTD’s chip are 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) [R14]. These
security measures include the binding of the MRTD’s chip to the passport book.
The logical MRTD delivered by the IC Manufacturer is protected by a mutual
authentication mechanism based on symmetric cryptography until completion of the
1
These biometric reference data are optional according to [R8]. This ST assumes that the issuing State or
Organization uses this option and protects these data by means of extended access control.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 10 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
initialization and pre-personalization processes. After completion the authentication keys
are disabled.
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 required security methods Passive Authentication and the
following optional advanced security methods:
• Basic Access Control to the logical MRTD,
• Active Authentication of the MRTD’s chip,
• Extended Access Control to and
• the Data Encryption of sensitive biometrics as an optional security measure in the
ICAO Doc 9303 [R14].
The Passive Authentication and the Data Encryption are performed completely and
independently of the TOE by the TOE environment.
This security target does not address the Active Authentication and the Extended Access
Control as optional security mechanisms.
This security target addresses the protection of the logical MRTD:
i. in integrity by write-only-once access control and by physical means and
ii. in confidentiality by the Basic Access Control Mechanism.
The Basic Access Control is a security feature which is mandatory supported by the TOE.
The inspection system:
i. reads optically the MRTD,
ii. authenticates itself as inspection system by means of Document Basic Access
Keys.
After successful authentication of the inspection system, the MRTD chip provides read
access to the logical MRTD by means of private communication (secure messaging) with
this inspection system [R14], normative appendix 5.
1.4.3 TOE Life-cycle
The TOE life cycle is described in terms of four life cycle phases:
1. Development, composed of (i) the development of the operating system software by
the Embedded Software Developer and (ii) the development of the integrated circuit
by the IC Manufacturer
2. Manufacturing, composed of (i) the fabrication of the integrated circuit by the IC
Manufacturer, (ii) the embedding of the chip in an inlay with an antenna, (iii) the
completion of the operating system, (iv) the initialization and pre-personalization of
the MRTD
3. Personalization
4. Operational Use
Application Note 2: The entire Development phase, as well as step (i) “fabrication of
the integrated circuit” of the Manufacturing phase are the only phases covered by the
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 11 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
assurance class ALC, as during these phases the TOE is under construction in a protected
environment. All other phases are covered by assurance class AGD and in these phases
the TOE is self-protected.
In Figure 1-1 activities (represented as rounded rectangles) and deliveries (represented as
arrows) printed orange are secured by the environment and are covered by assurance
class ALC. The activities and deliveries printed white refer to phases covered by
assurance class AGD, in which the TOE is self-protected.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 12 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Figure 1-1 TOE life-cycle
Phase 3 - Personalization
Phase 2 - Manufacturing
Phase 4 – Operational Use
Phase 1 – Development
Embedded software development
IC design and dedicated software development
Integration
Mask fabrication
Operational use
End of life
TOE Delivery
Assembling of the book
Inlay Manufacturing
Pre-personalization
Personalization
IC manufacturing
NXP
Gep
MRTD
Manufacturer
Personalization
Agent
MRTD
Holder
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 13 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 1-3 identifies the roles in each phase of the TOE life cycle.
Table 1-3 Roles Identification
Phase Role Identification
1 IC Developer NXP Semiconductors
1 Embedded Software Developer Gep S.p.A.
2 IC Manufacturer NXP Semiconductors
2 MRTD Manufacturer the agent who is acting on the behalf of the
Issuing State or Organization to assemble the
passport book embedding the TOE, and to pre-
personalize the MRTD
3 Personalization Agent the agent who is acting on the behalf of the
Issuing State or Organization to personalize the
MRTD for the holder
4 MRTD Holder The rightful owner of the MRTD
1.4.3.1 Phase 1 “Development”
Step1 “IC Development”
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 “Embedded Software Development”
The software developer uses the guidance documentation for the integrated circuit and the
guidance documentation for relevant parts of the IC Dedicated Software and develops the
IC Embedded Software (operating system), the MRTD application and the guidance
documentation associated with these TOE components.
The manufacturing documentation of the IC, including the IC Dedicated Software and the
Embedded Software in the non-volatile non-programmable memories (ROM), is securely
delivered to the IC manufacturer. The IC Embedded Software in the non-volatile
programmable memories, the MRTD application and the guidance documentation is
securely delivered to the MRTD Manufacturer.
1.4.3.2 Phase 2 “Manufacturing”
Step3 “IC Manufacturing”
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 in the non-volatile non-
programmable memories (ROM). The IC Manufacturer:
(i) 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.
(ii) Creates the MRTD application
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 14 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Application Note 3: Creation of the application implies the creation of MF and
ICAO.DF
The IC is securely delivered from the IC Manufacturer to the MRTD Manufacturer.
If necessary the IC manufacturer adds the parts of the IC Embedded Software in the non-
volatile programmable memories (for instance EEPROM). Patches, if any, are loaded in
this step.
Step4 “MRTD Manufacturing – Assembling of the book”
The MRTD Manufacturer combines the IC with hardware for the contactless interface, and
embeds the inlay in the passport book.
Step5 “MRTD Manufacturing – Pre-Personalization”
The MRTD Manufacturer equips MRTD’s chips with pre-personalization Data.
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.
1.4.3.3 Phase 3 “Personalization of the MRTD”
Step6 “Personalization”
The personalization of the MRTD includes:
(i) the survey of the MRTD holder’s biographical data,
(ii) the enrolment of the MRTD holder biometric reference data (i.e. the digitized
portraits and the optional biometric reference data),
(iii) the printing of the visual readable data onto the physical MRTD,
(iv) 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.
The signing of the Document security object by the Document signer[R14] 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 4: The TSF data (data created by and for the TOE, that might affect
the operation of the TOE; cf. [R8], section 92) comprise (but are not limited to) the
Personalization Agent Key(s) and the Basic Access Control Key.
Application Note 5: This ST distinguishes between the Personalization Agent as an
entity known to the TOE and the Document Signer as an entity in the TOE IT environment
signing the Document security object as described in [R14]. This approach allows, but
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 15 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
does not enforce, the separation of these roles. The selection of the authentication keys
should consider the organization, the productivity and the security of the personalization
process. Asymmetric authentication keys provide comfortable security for distributed
personalization, but their use may be more time consuming than authentication using
symmetric cryptographic primitives. Authentication using symmetric cryptographic
primitives allows for fast authentication protocols appropriate for centralized
personalization schemes but relies on stronger security protection in the personalization
environment.
1.4.3.4 Phase 4 “Operational Use”
The TOE is used as MRTD’s chip by the traveler and the inspection systems in the
“Operational Use” phase. The user data can be read according to the security policy of the
issuing State or Organization and can be used according to the security policy of the
issuing State, but they can never be modified.
Application Note 6: The authorized Personalization Agents might be allowed to add
(not to modify) data in the other data groups of the MRTD application (e.g. person(s) to
notify EF.DG16) in the Phase 4 “Operational Use”. This will imply an update of the
Document Security Object including the re-signing by the Document Signer.
Application Note 7: This ST considers the phases 1 and parts of phase 2 (i.e. Step1 to
Step3) as part of the evaluation and therefore defines the TOE delivery according to CC
after this phase. Since specific production steps of phase 2 are of minor security relevance
(e. g. booklet manufacturing and antenna integration) these are not part of the CC
evaluation under ALC. The national body of the issuing State or Organization is
responsible for these specific production steps. Note that the personalization process and
its environment may depend on specific security needs of an issuing State or
Organization. All production, generation and installation procedures after TOE delivery up
to the “Operational Use” (phase 4) have to be considered in the product evaluation
process under AGD assurance class.
1.4.4 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.5 TOE Description
1.5.1 Physical scope of the TOE
The physical TOE is comprised of the following:
• the integrated circuit chip NXP P5CD081 (microcontroller) programmed with the
operating system and with the ICAO passport application.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 16 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
The chip received a Common Criteria certification at the assurance level EAL5 augmented
with ALC_DVS.2, AVA_VAN.5 and ASE_TSS.2 [R1][R2] [R25], with certification ID:
BSI-DSZ-CC-0555-2009
The certified version of the IC is the revision V1A.
The platform’s certificate is valid and up-to-date.
1.5.2 Other non-TOE physical components
Figure 1-2 shows a picture of the inlay components, distinguishing between TOE
components and non-TOE components.
The antenna and the substrate of the inlay are not part of the TOE.
Figure 1-2 Inlay components
1.5.3 Logical scope of the TOE
The logical part of the TOE comprises the following software components stored in the
non-volatile memory units of the microcontroller:
• operating system
• file system
• MRTD application
• security data objects
The SOMA801NXP operating system manages all the resources of the integrated circuit
that equips the passport, providing secure access to data and functions. Major tasks
performed by the operating system are:
• Communication between internal objects
• Communication with external devices
• Data storage in the file system
• Execution of commands
Microcontroller module
(TOE component)
Antenna
(non-TOE component)
Substrate material
(non-TOE component)
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 17 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
• Cryptographic operations
• Management of the security policies
The operating system has a flexible modular structure and a layered architecture
providing:
• full support of the ICAO MRTD application
• Basic Access Control
• Extended Access Control
• secure support of various types of applications
• secure management of functions and data
The file system contains security data objects and the MRTD application.
Before the initialization, access to IC’s resources is protected by a symmetric
cryptographic mechanism requiring a mutual authentication between the Initialization
System and the e-Passport.
The IC Manufacturer stores identification data and the MRTD Manufacturer keys.
In the pre-personalization phase, the MRTD Manufacturer stores the Personalization
Agent keys, as well as keys and data required by the authentication mechanisms used in
the subsequent phases.
In the personalization phase, the Personalization Agent stores the ICAO application data,
the BAC keys and other data required by the authentication mechanisms used in the
operational use phase.
Once the passport is in the Operational state, no data can be deleted or modified, except
for the current date, the trustpoint and the EF.CVCA file, which can also be modified.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 18 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
2. Conformance claims
2.1 Common Criteria Conformance
This Security Target claims conformance to:
• Common Criteria version 3.1 revision 3, International English Version
[R8][R9][R10], as follows:
o Part 2 (security functional requirements) extended
o Part 3 (security assurance requirements) conformant
The software part of the TOE runs on the chip NXP Semiconductors P5CD081.
This integrated circuit is certified against Common Criteria at the assurance level EAL5+
[R1][R2][R25].
2.2 Protection Profile Conformance
This ST claims strict conformance to:
• BSI-CC-PP-0055 Common Criteria Protection Profile Machine Readable Travel
Document with “ICAO Application” Basic Access Control version 1.10 25th
March,
2009 [R6].
2.3 Package Conformance
This Security Target claims conformance to:
• EAL4 assurance package augmented with ALC_DVS.2 defined in CC part 3 [R10]
2.4 Conformance Rationale
The parts of the TOE listed in the Protection Profile [R6] correspond to the ones listed in
section 1.4 of this ST.
In this ST, the TOE will be delivered from the IC Manufacturer to the MRTD Manufacturer
after Step3 “IC Manufacturing” of Phase 2, as a chip, in accordance with Application Note
5 of the PP [R5]. At TOE delivery, there is no user data or machine readable data
available. The EF.DG14 file, containing part of the user data, is written by the MRTD
Manufacturer in Step5 “MRTD Manufacturing – Pre-Personalization” of Phase 2. The
remaining user data as well as applicative files are written by the Personalization Agent,
during Phase 3 “Personalization of the MRTD”.
The security problem definition of this ST is taken from the one in the PP with the following
modifications:
• New subjects “Initialization and Pre-personalization Terminal” and “Personalization
Terminal” have been added as a specialization of the “Terminal” subject from the
PP. The introduction of these subjects does not lower security as a 112 bit Triple-
DES mutual authentication mechanism is required.
• Some security objectives for the TOE have been modified in a more restrictive way
with respect to the PP, as showed in Table 2-1.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 19 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 2-1 Modified security objectives
Security Objective Definition Operation
OT.AC_Pers Access Control for Personalization
of logical MRTD.
Modified in a more restrictive way
as data addition is not allowed at
all after personalization
OT.Identification Identification and Authentication of
the TOE
Modified in a more restrictive way
as access to TOE identification
data in Phase 4 is restricted to a
BAC authenticated Inspection
System only (the Personalization
Agent cannot access
identification data after
personalization).
The functional requirements described in section 6 of this ST correspond to the ones in
section 5 of the PP [R6].
Table 2-2 shows assignment changes or refinements/iterations/additions with respect to
the PP security functional requirements for the TOE. These changes do not lower the TOE
security and, in some cases, changed requirements are more restrictive than the ones
from the PP.
Table 2-2 SFRs assignment changes, refinements, iterations and additions
Security Functional Requirement Operation
Addition:
FCS_CKM.1/CPS Cryptographic key generation –
Generation of Personalization Keys by the TOE
Iteration that specifies the generation of the
session keys for the MRTD Manufacturer and
for the Personalization Agent.
Change:
FCS_CKM.1/BAC Cryptographic key generation –
Generation of Document Basic Access Keys by the TOE
Due to the addition of FCS_CKM.1/CPS, an
iteration label “BAC” has been added to this
SFR to distinguish the generation of the
Document BAC keys.
Addition:
FMT_MTD.1/ADDTSF_WRITE Management of TSF data –
additional TSF data write
Iteration that specifies additional TSF data
written in personalization
Change:
FIA_UAU.4 single use authentication mechanisms – single
use authentication of the Terminal by the TOE
This SFR now also relates to the MRTD
Manufacturer Authentication (cf. Application
Note 34:).
Change:
FIA_UAU.5 multiple authentication mechanisms
the MRTD Manufacturer has been added as a
user allowed to authenticate to the passport.
Change:
FMT_MTD.1/INI_DIS
This SFR has been modified in a more
restrictive way with respect to the PP since
access conditions to initialization and pre-
personalization data cannot be modified after
Phase 2 “Manufacturing”.
Change:
FMT_SMR.1.1
This SFR has been modified to distinguish the
roles IC Manufactuer and MRTD Manufacturer.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 20 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
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 sensitive User 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 [R14].
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.
Due to interoperability reasons, as the ICAO Doc 9303 [R14] requires that Basic
Inspection Systems must have access to logical MRTD data DG1, DG2, DG5 to DG16, the
TOE described in this security target specifies only the BAC mechanism with resistance
against enhanced basic attack potential granting access to
• Logical MRTD standard User Data (i.e. Personal Data) of the MRTD holder
(EF.DG1, EF.DG2, EF.DG5 to EF.DG13, EF.DG16),
• Chip Authentication Public Key in EF.DG14,
• Document Security Object (SOD) in EF.SOD,
• Common Data in EF:COM.
Application Note 8: EF.DG15 is not present in the list of the assets because the
SOMA801NXP operating system does not support Active Authentication which, therefore,
is not addressed by this security target. As an alternative to Active Authentication the
SOMA801NXP operating system provides the Chip Authentication mechanism (cf. [R13]).
The TOE prevents read access to sensitive USER Data
• Sensitive biometric reference data (EF.DG3, EF.DG4).
A sensitive asset is the following more general one.
Authenticity of the MRTD’s chip
The authenticity of the MRTD’s chip personalized by the issuing State or Organization for
the MRTD’s 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.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 21 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
• Personalization Agent: The agent who is acting on behalf of the issuing State or
Organization to personalize the MRTD for the holder by some or all 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 TSF data and
v. signing the Document Security Object (SOD) as defined in the ICAO Doc
9303 [R14].
• 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) in examining an MRTD presented by the traveler and
verifying its authenticity and (ii) verifying the traveler as MRTD holder.
The Basic Inspection System (BIS):
i. contains a terminal for the contactless communication with the MRTD’s chip,
ii. implements the terminals part of the BAC Mechanism and
iii. gets the authorization to read the logical MRTD under the BAC by optically
reading the printed data in the MRZ 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 by the Inspection System Certificates.
Application Note 9: This security target does not distinguish between the BIS, GIS and
EIS because the Chip Authentication and the Extended Access Control is outside the
scope.
• MRTD Holder: The rightful holder of the MRTD for whom the issuing State or
Organization personalized the MRTD.
• Traveler: A person presenting the MRTD to the inspection system and claiming the
identity of the MRTD holder.
• Attacker: A threat agent trying:
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 22 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
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),
ii. To read or manipulate the logical MRTD without authorization, or
iii. To forge a genuine MRTD
Application Note 10: 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.
• Pre-personalization Terminal (PPT): A system used by the MRTD Manufacturer
to perform TOE pre-personalization in phase 2; it allows to write user and TSF data
in the logical MRTD, by implementing the terminals part of a pre-personalization
process (described in the guidance documentation), using a secure messaging
mechanism with diversified keys.
• Personalization Terminal (PT): A terminal used by the Personalization Agent to
perform TOE personalization and configuration in phase 3; it allows to write user
and TSF data in the logical MRTD, by implementing the terminals part of a
personalization process (described in the guidance documentation), using a secure
messaging mechanism with diversified keys.
Application Note 11: The new subjects “Initialization and Pre-personalization Terminal”
and “Personalization Terminal” are a specialization of the “Terminal” subject from the PP.
The introduction of these subjects does not impact on the security of the TOE, since they
are required to establish a mutual authentication based on 112 bit Triple-DES
cryptography and the respective authentication keys are destroyed at the completion of
phase 2 (Initialization and Pre-personalization Terminal) and phase 3 (Personalization
Terminal).
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 of 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.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 23 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Procedures shall ensure that people dealing with the procedure for delivery have
got the required skill.
• A.Pers_Agent Personalization of the MRTD’s chip
The Personalization Agent ensures the correctness of:
i. the logical MRTD with respect to the MRTD holder,
ii. the Document BAC Keys,
iii. the Chip Authentication Public Key Info (EF.DG14) if stored on the MRTD’s chip
and
iv. the Document Signer Public Key Certificate (is dtored 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
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 Basic Inspection System for global interoperability
i. includes the Country Signing CA Public Key and the Document Signer Public
Key of each issuing State or Organization, and
ii. implements the terminal part of the Basic Access Control [R14].
The Basic Inspection System reads the logical MRTD being under Basic Access
Control and performs the Passive Authentication to verify the logical MRTD.
Application Note 12: According to [R14] the support of Passive Authentication
mechanism is mandatory whereas the Basic Access Control is optional. This ST does not
address Primary Inspection Systems therefore the BAC is mandatory within this ST.
• A.BAC-Keys Cryptographic quality of Basic Access Control Keys
The Document Basic Access Control Keys being generated and imported by the issuing
State or Organization have to provide sufficient cryptographic strength. As a consequence
of the ‘ICAO Doc 9303’ [R14], the Document Basic Access Control Keys are derived from
a defined subset of the individual printed MRZ data. It has to be ensured that these data
provide sufficient entropy to withstand any attack based on the decision that the inspection
system has to derive Document Access Keys from the printed MRZ data with enhanced
basic attack potential.
Application Note 13: When assessing the MRZ data resp. the BAC keys entropy
potential dependencies between these data (especially single items of the MRZ) have to
be considered and taken into account. E.g. there might be a direct dependency between
the Document Number when chosen consecutively and the issuing date.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 24 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
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
Adverse action: An attacker trying to trace the movement of the MRTD by identifying
remotely the MRTD’s chip by establishing or listening to
communications through the contactless communication interface.
Threat agent: having enhanced basic attack potential, not knowing the optically
readable MRZ data printed on the MRTD data page in advance.
Asset: Anonimity of user
• T.Skimming Skimming the logical MRTD
Adverse action: An attacker imitates an inspection system trying to establish a
communication to read the logical MRTD or parts of it via the
contactless communication channel of the TOE.
Threat agent: having enhanced basic attack potential, not knowing the optically
readable MRZ data printed on the MRTD data page in advance.
Asset: confidentiality of logical MRTD data
• T.Eavesdropping Eavesdropping to the communication between TOE
and inspection system
Adverse action: An attacker is listening communication between the MRTD’s chip and
an inspection system to gain the logical MRTD or parts of it. The
inspection system uses the MRZ data printed on the MRTD data page
but the attacker does not know these data in advance.
Threat agent: having enhanced basic attack potential, not knowing the optically
readable MRZ data printed on the MRTD data page in advance.
Asset: confidentiality of logical MRTD data
• T.Forgery Forgery of data on MRTD’s chip
Adverse action: An attacker alters fraudulently the complete stored logical MRTD or
any part of it including its security related data in order to deceive on
an inspection system by means of the changed MRTD holder’s
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 25 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
identity or biometric reference data. This threat comprises several
attack scenarios of MRTD forgery. The attacker may alter the
biographical data on the biographical data page of the passport book,
in the printed MRZ and in the digital MRZ to claim another identity of
the traveler. The attacker may alter the printed portrait and the
digitized portrait to overcome the visual inspection of the inspection
officer and the automated biometric authentication mechanism by face
recognition. The attacker may alter the biometric reference data to
defeat automated biometric authentication 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 write
the digitized portrait and optional biometric reference finger data read
from the logical MRTD of a traveler into an other MTRD’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.
Threat agent: having enhanced basic attack potential, being in possession of one or
more legitimate MRTDs
Asset: authenticity of logical MRTD data
The TOE shall avert the threat as specified below.
• T.Abuse-Func Abuse of Functionality
Adverse action: An attacker may use functions of the TOE which shall not be used in
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.
Threat agent: having enhanced basic attack potential, being in possession of a
legitimate MRTD
Asset: confidentiality and authenticity of logical MRTD and TSF data,
correctness of TSF
• T.Information_Leakage Information Leakage from MRTD’s chip
Adverse action: An attacker may exploit information which is leaked from the TOE
during its usage in order to disclose confidential TSF data. The
information leakage may be inherent in the normal operation or
caused by the attacker. Leakage may occur through emanations,
variations in power consumption, I/O characteristics, clock frequency,
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 26 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
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 MRTD
Asset: confidentiality logical MRTD and TSF data
• T.Phys_Tamper Physical Tampering
Adverse action: An attacker may perform physical probing of the MRTD’s chip in
order:
i. to disclose TSF Data, or
ii. to disclose/reconstruct the MRTD’s chip Embedded Software.
An attacker may physically modify the MRTD’s chip in order to:
i. modify security features or functions of the MRTD’s chip,
ii. modify security functions of the MRTD’s chip Embedded
Software,
iii. modify User Data or
iv. modify TSF data.
The physical tampering may be focused directly on the disclosure or
manipulation of TOE User Data (e.g. the biometric reference data for
the inspection system) or TSF Data (e.g. authentication key of the
MRTD’s chip) or indirectly by preparation of the TOE to following
attack methods by modification of security features (e.g. to enable
information leakage through power analysis). Physical tampering
requires direct interaction with the MRTD’s chip internals. Techniques
commonly employed in IC failure analysis and IC reverse engineering
efforts may be used. Before that, the hardware security mechanisms
and layout characteristics need to be identified. Determination of
software design including treatment of User Data and TSF Data may
also be a pre-requisite. The modification may result in the deactivation
of a security function. Changes of circuitry or data can be permanent
or temporary.
Threat agent: having enhanced basic attack potential, being in possession of a
legitimate MRTD
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 27 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Asset: confidentiality and authenticity of logical MRTD and TSF data,
correctness of TSF
• T.Malfunction Malfunction due to Environmental Stress
Adverse action: An attacker may cause a malfunction of TSF or of the MRTD’s chip
Embedded Software by applying environmental stress in order to:
i. deactivate or modify security features or functions of the TOE or
ii. circumvent or deactivate or modify security functions of the
MRTD’s chip Embedded Software.
This may be achieved e.g. by operating the MRTD’s chip outside the
normal operating conditions, exploiting errors in the MRTD’s chip
Embedded Software or misusing administration function. To exploit
these vulnerabilities an attacker needs information about the
functional operation.
Threat agent: having enhanced basic attack potential, being in possession of a
legitimate MRTD
Asset: confidentiality and authenticity of logical MRTD and TSF data,
correctness of TSF
3.4 Organizational Security Policies
The TOE shall comply to the following organization security policies (OSP) as security
rules, procedures, practices, or guidelines imposed by an organization upon its operations
(see CC part 1, sec. 3.2 [R8]).
• P.Manufact Manufacturing of the MRTD’s chip
The Initialization Data are written by the IC Manufacturer to identify the IC uniquely, to
set the initial configuration and to create the MRTD application.
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
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 28 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
The biographical data and their summary printed in the MRZ and stored on the MRTD’s
chip (EF.DG1), the printed portrait and the digitized portrait (EF.DG2), the biometric
reference data of finger(s) (EF.DG3), the biometric reference data of iris image(s)
(EF.DG4)3 and data according to LDS (EF.DG5 to EF.DG13, EF.DG16) stored on the
MRTD’s chip are personal data of the MRTD holder. These data groups are intended to be
used only with agreement of the MRTD holder by inspection systems to which the MRTD
is presented. The MRTD’s chip shall provide the possibility for the Basic Access Control to
allow read access to these data only for terminals successfully authenticated based on
knowledge of the Document Basic Access Keys as defined in [R14].
Application Note 14: The organizational security policy P.Personal_Data is drawn from
the ICAO ‘ICAO Doc 9303’ [R14]. Note that the Document Basic Access Key is defined by
the TOE environment and loaded to the TOE by the Personalization Agent.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 29 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
4. Security Objectives
This chapter describes the security objectives for the TOE and the security objectives for
the TOE environment. The security objectives for the TOE environment are separated into
security objectives for the development and production environment and security
objectives for the operational environment.
4.1 Security Objectives for the TOE
This section describes the security objectives for the TOE addressing the aspects of
identified threats to be countered by the TOE and organizational security policies to be met
by the TOE.
• OT.AC_Pers Access Control for Personalization of logical MRTD
The TOE must ensure that the logical MRTD data in EF.DG1 to EF.DG16, the
Document security object according to LDS [R12] 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 can not be changed after its
personalization. The Document security object can be updated by authorized
Personalization Agents if data in the data groups EF.DG3 to EF.DG16 are added.
Application Note 15: The OT.AC_Pers implies that
(1) The data of the LDS groups written during personalization for the MRTD
holder (at least EF.DG1 and EF.DG2) cannot be changed by write access
after personalization,
(2) The Personalization Agents may (i) add (fill) data into the LDS data groups
not written yet, and (ii) update and sign the Document Security Object
accordingly. The support for adding data in the “Operational Use” phase is
not provided.
• OT.Data_Int Integrity of personal data
The TOE must ensure the integrity of the logical MRTD stored on the MRTD’s chip
against physical manipulation and unauthorized writing. The TOE must ensure that the
inspection system is able to detect any modification of the transmitted logical MRTD
data.
• OT.Data_Conf Confidentiality of personal data
The TOE must ensure the confidentiality of the logical MRTD data groups EF.DG1 to
EF.DG16. Read access to EF.DG1 to EF.DG16 is granted to terminals successfully
authenticated as Personalization Agent. Read access to EF.DG1, EF.DG2 and
EF.DG5 to EF.DG16 is granted to terminals successfully authenticated as Basic
Inspection System. The Basic Inspection System shall authenticate itself by means of
the Basic Access Control based on knowledge of the Document Basic Access Key.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 30 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
The TOE must ensure the confidentiality of the logical MRTD data during their
transmission to the Basic Inspection System.
Application Note 16: The traveler grants the authorization for reading the personal data
in EF.DG1, EF.DG2 and EF.DG5 to EF.DG16 to the inspection system by presenting the
MRTD. The MRTD’s chip shall provide read access to these data for terminals
successfully authenticated by means of the Basic Access Control based on knowledge of
the Document Basic Access Keys. The security objective OT.Data_Conf requires the TOE
to ensure the strength of the security function Basic Access Control Authentication. The
Document Basic Access Keys are derived from the MRZ data defined by the TOE
environment and are loaded into the TOE by the Personalization Agent. Therefore the
sufficient quality of these keys has to result from the MRZ data’s entropy. Any attack
based on decision of the ‘ICAO Doc 9303’ [R14] that the inspection system derives
Document Basic Access is ensured by OE.BAC-Keys. Note that the authorization for
reading the biometric data in EF.DG3 and EF.DG4 is only granted after successful
Enhanced Access Control not covered by this protection profile. Thus the read access
must be prevented even in case of a successful BAC Authentication.
• OT.Identification Identification and Authentication of the TOE
The TOE must provide means to store IC Identification and Pre-Personalization Data in
its non-volatile memory. The IC Identification Data must provide a unique identification
of the IC during Phase 2 “Manufacturing” and Phase 3 “Personalization of the MRTD”.
The storage of the Pre-Personalization data includes writing the Personalization Agent
Key(s). In phase 4 “Operational Use” the TOE shall identifiy itself only to a successful
authenticated Basic Inspection System.
Application Note 17: The TOE security objective OT.Identification addresses security
features of the TOE to support the life cycle security in the manufacturing and
personalization phases. The IC Identification Data are used for TOE identification in Phase
2 “Manufacturing” and for traceability and/or to secure shipment of the TOE from Phase 2
“Manufacturing” into the Phase 3 “Personalization of the MRTD”. The OT.Identification
addresses security features of the TOE to be used by the TOE manufacturing. In the
Phase 4 “Operational Use” the TOE is identified by the Document Number as part of the
printed and digital MRZ. The OT.Identification forbids the output of any other IC (e.g.
integrated circuit card serial number ICCSN) or MRTD identifier through the contactless
interface before successful authentication as Basic Inspection System or as
Personalization Agent.
The following TOE security objectives address the protection provided by the MRTD’s chip
independent on 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 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
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 31 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
iv. bypass, deactivate, change or explore security features or functions of the
TOE.
Details of the relevant attack scenarios depend, for instance, on the capabilities of the
Test Features provided by the IC Dedicated Test Software which are not specified
here.
• OT.Prot_Inf_Leak Protection against Information Leakage
The TOE must provide protection against disclosure of confidential TSF data stored
and/or processed in the MRTD’s chip
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 18: 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 high attack potential by means of
measuring through galvanic contacts which is direct physical probing on the
chips surface except on pads being bonded (using standard tools for measuring
voltage and current) or
measuring not using galvanic contacts but other types of physical interaction
between charges (using tools used in solid-state physics research and IC failure
analysis),
manipulation of the hardware and its security features, as well as,
controlled manipulation of memory contents (User Data, TSF, Data)
with a prior
reverse-engineering to understand the design and its properties and functions.
• OT.Prot_Malfunction Protection against Malfunctions
The TOE must ensure its correct operation. The TOE must prevent its operation
outside the normal operating conditions where reliability and secure operation has not
been proven or tested. This is to prevent errors. The environmental conditions may
include external energy (esp. electromagnetic) fields, voltage (on any contacts), clock
frequency, or temperature.
Application Note 19: A malfunction of the TOE may also be caused using a direct
interaction with elements on the chip surface. This is considered as being a manipulation
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 32 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
(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’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.
• 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,
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 33 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
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 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 Signing Key Pair and ensure the
secrecy of the Document Signer Private Keys,
ii. sign Document Security Objects of genuine MRTD in a secure operational
environment only, and
iii. distribute the Certificate of the Document Signer Public Key to receiving
States and Organizations.
The digital signature in the Document Security Object relates to all data in the data
groups EF.DG1 to EF.DG16 if stored in the LDS according to [R14].
• OE.BAC-Keys Cryptographic quality of Basic Access Control
Keys
The Document Basic Access Control Keys being generated and imported by the issuing
State or Organization have to provide sufficient cryptographic strength. As a consequence
of the ‘ICAO Doc 9303’ [6] the Document Basic Access Control Keys are derived from a
defined subset of the individual printed MRZ data. It has to be ensured that these data
provide sufficient entropy to withstand any attack based on the decision that the inspection
system has to derive Document Basic Access Keys from the printed MRZ data with
enhanced basic attack potential.
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 Basic Inspection
System for global interoperability
i. includes the Country Signing Public Key and the Document Signer Public
Key of each issuing State or Organization, and
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 34 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
ii. implements the terminal part of the Basic Access Control [R14].
• 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 the 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 ensures the confidentiality and integrity
of the data read from the logical MRTD. The receiving State examining the logical
MRTD being under Basic Access Control will use inspection systems which implement
the terminal part of the Basci Access Control and use the secure messaging with fresh
generated keys for the protection of the transmitted data (i.e. Basic Inspection
Systems).
4.3 Security Objective Rationale
Table 4-1 provides an overview for security objectives coverage.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 35 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 4-1 Security Objective Rationale
OT.AC_Pers
OT.Data_Int
OT.Data_Conf
OT.Identification
OT.Prot_Abuse-Func
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfunction
OE.MRTD_Manufact
OE.MRTD_Delivery
OE.Personalization
OE.Pass_Auth_Sign
OE.BAC-Keys
OE.Exam_MRTD
OE.Passive_Auth_Verif
OE.Prot_Logical_MRTD
T.Chip-ID x x
T.Skimming x x
T.Eavesdropping x
T.Forgery x x x x x x
T.Abuse-Func x x
T.Information_Leakage x
T.Phys-Tamper x
T.Malfunction x
P.Manufact x
P.Personalization x x x
P.Personal_Data x x
A.MRTD_Manufact x
A.MRTD_Delivery x
A.Pers_Agent x
A.Insp_Sys x x
A.BAC_Keys x
The OSP P.Manufact “Manufacturing of the MRTD’s chip” requires a unique identification
of the IC by means of the Initialization Data and the writing of the Pre-personalization Data
as being fulfilled by OT.Identification.
The OSP P.Personalization “Personalization of the MRTD by issuing State or
Organization only” addresses the
i. the enrolment of the logical MRTD by the Personalization Agent as described in
the security objective for the TOE environment OE.Personalization
“Personalization of logical MRTD”, and
ii. the access control for the user data and TSF data as described by the security
objective OT.AC_Pers “Access Control for Personalization of logical MRTD”.
Note the manufacturer equips the TOE with the Personalization Agent Key(s) according to
OT.Identification “Identification and Authentication of the TOE”. The security objective
OT.AC_Pers limits the management of TSF data and the management of TSF to the
Personalization Agent.
The OSP P.Personal_Data “Personal data protection policy” requires the TOE
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 36 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
(i) to support the protection of the confidentiality of the logical MRTD by means
of the Basic Access Control and
(ii) enforce the access control for reading as decided by the issuing State or
Organization.
This policy is implemented by the security objectives OT.Data_Int “Integrity of personal
data” describing the unconditional protection of the integrity of the stored data and during
transmission. The security objective OT.Data_Conf “Confidentiality of personal data”
describes the protection of the confidentiality.
The threat T.Chip_ID “Identification of MRTD’s chip” addresses the trace of the MRTD
movement by identifying remotely the MRTD’s chip through the contactless
communication interface. This threat is countered as described by the security objective
OT.Identification by Basic Access Control using sufficiently strong derived keys as
required by the security objective for the environment OE.BAC-Keys.
The threat T.Skimming “Skimming digital MRZ data or the digital portrait” and
T.Eavesdropping “Eavesdropping to the communication between TOE and inspection
system” address the reading of the logical MRTD trough the contactless interface or
listening the communication between the MRTD’s chip and a terminal. This threat is
countered by the security objective OT.Data_Conf “Confidentiality of personal data”
through Basic Access Control using sufficiently strong derived keys as required by the
security objective for the environment OE.BAC-Keys.
The threat T.Forgery “Forgery of data on MRTD’s chip” addresses the fraudulent
alteration of the complete stored logical MRTD or any part of it. The security objective
OT.AC_Pers “Access Control for Personalization of logical MRTD“ requires the TOE to
limit the write access for the logical MRTD to the trustworthy Personalization Agent (cf.
OE.Personalization). The TOE will protect the integrity of the stored logical MRTD
according the security objective OT.Data_Int “Integrity of personal data” and
OT.Prot_Phys-Tamper “Protection against Physical Tampering”. The examination of the
presented MRTD passport book according to OE.Exam_MRTD “Examination of the MRTD
passport book” shall ensure that passport book does not contain a sensitive contactless
chip which may present the complete unchanged logical MRTD. The TOE environment will
detect partly forged logical MRTD data by means of digital signature which will be created
according to OE.Pass_Auth_Sign “Authentication of logical MRTD by Signature” and
verified by the inspection system according to OE.Passive_Auth_Verif “Verification by
Passive Authentication”.
The threat T.Abuse-Func “Abuse of Functionality” addresses attacks using the MRTD’s
chip as production material for the MRTD and misuse of the functions for personalization
in the operational state after delivery to MRTD holder to disclose or to manipulate the
logical MRTD. This threat is countered by OT.Prot_Abuse-Func “Protection against
Abuse of Functionality”. Additionally this objective is supported by the security objective for
the TOE environment: OE.Personalization “Personalization of logical MRTD” ensuring
that the TOE security functions for the initialization and the personalization are disabled
and the security functions for the operational state after delivery to MRTD holder are
enabled according to the intended use of the TOE.
The threats T.Information_Leakage “Information Leakage from MRTD’s chip”, T.Phys-
Tamper “Physical Tampering” and T.Malfunction “Malfunction due to Environmental
Stress” are typical for integrated circuits like smart cards under direct attack with high
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 37 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
attack potential. The protection of the TOE against these threats is addressed by the
directly related security objectives OT.Prot_Inf_Leak “Protection against Information
Leakage”, OT.Prot_Phys-Tamper “Protection against Physical Tampering” and
OT.Prot_Malfunction “Protection against Malfunctions”.
The assumption A.MRTD_Manufact “MRTD manufacturing on step 4 to 6” is covered by
the security objective for the TOE environment OE.MRTD_Manufact “Protection of the
MRTD Manufacturing” that requires to use security procedures during all manufacturing
steps.
The assumption A.MRTD_Delivery “MRTD delivery during step 4 to 6” is covered by the
security objective for the TOE environment OE.MRTD_ Delivery “Protection of the MRTD
delivery” that requires to use security procedures during delivery steps of the MRTD.
The assumption A.Pers_Agent “Personalization of the MRTD’s chip” is covered by the
security objective for the TOE environment OE.Personalization “Personalization of logical
MRTD” including the enrolment, the protection with digital signature and the storage of the
MRTD holder personal data.
The examination of the MRTD passport book addressed by the assumption A.Insp_Sys
“Inspection Systems for global interoperability” is covered by the security objectives for the
TOE environment OE.Exam_MRTD “Examination of the MRTD passport book”. The
security objectives for the TOE environment OE.Prot_Logical_MRTD “Protection of data
from the logical MRTD” will require the Basic Inspection System to implement the Basic
Access Control and to protect the logical MRTD data during the transmission and the
internal handling.
The assumption A.BAC-Keys “Cryptographic quality of Basic Access Control Keys” is
directly covered by the security objective for the TOE environment OE.BAC-Keys
“Cryptographic quality of Basic Access Control Keys” ensuring the sufficient key quality to
be provided by the issuing State or Organization.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 38 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
5. Extended Components Definition
This ST uses components defined as extensions to CC part 2 [R9]. Some of these
components are defined in [R4], other components are defined in the protection profile
[R5].
5.1 Definition of the family FAU_SAS
To define the security functional requirements of the TOE an additional family (FAU_SAS)
of the Class FAU (Security Audit) is defined in the PP [R5]. 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 in the following table.
Table 5-1 Family FAU_SAS
FAU_SAS Audit data storage
Family behavior: This family defines functional requirements for the storage of
audit data.
Component leveling:
FAU_SAS.1 Requires the TOE to provide the possibility to store audit data.
Management There are no management activities foreseen.
Audit There are no actions defined to be auditable.
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.2 Definition of the family FCS_RND
To define the IT security functional requirements of the TOE an additional family
(FCS_RND) of the Class FCS (cryptographic support) is defined in the PP [R6]. 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.
FAU_SAS Audit data storage 1
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 39 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
The family “Generation of random numbers (FCS_RND)” is specified in the following table.
Table 5-2 Family FCS_RND
FCS_RND Generation of random numbers
Family behavior: This family defines quality requirements for the generation of
random numbers which are intended to be used for
cryptographic purposes.
Component leveling:
FCS_RND.1 Generation of random numbers requires that random numbers
meet a defined quality metric.
Management: There are no management activities foreseen.
Audit: There are no actions defined to be auditable.
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 [assignment: a defined quality metric].
5.3 Definition of the family FMT_LIM
The family FMT_LIM describes the functional requirements for the Test Features of the
TOE. The new functional requirements were defined in the class FMT because this class
addresses the management of functions of the TSF. The examples of the technical
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.
FCS_RND Generation of random numbers 1
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 40 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 5-3 Family FMT_LIM
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:
FMT_LIM.1 Limited capabilities requires that the TSF is built to provide
only the capabilities (perform action, gather information)
necessary for its genuine purpose.
Management: There are no management activities foreseen.
Audit: There are no actions defined to be auditable.
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: There are no management activities foreseen.
Audit: There are no actions defined to be auditable.
To define the IT security functional requirements of the TOE a sensitive family (FMT_LIM)
of the Class FMT (Security Management) is defined here. This family describes the
functional requirements for the Test Features of the TOE. The new functional requirements
were defined in the class FMT because this class addresses the management of functions
of the TSF. The examples of the technical mechanism used in the TOE show that no other
class is appropriate to address the specific issues of preventing the abuse of functions by
limiting the capabilities of the functions and by limiting their availability.
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 Limited capabilities and availability
1
2
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 41 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
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 20: the functional requirements FMT_LIM.1 and FMT_LIM.2 assume
that there are two types of mechanisms (limited capabilities and limited availability) which
together shall provide protection in order to enforce the policy. This also allows that
• the TSF is provided without restrictions in the product in its user environment but
its capabilities are so limited that the policy is enforced
or conversely
• the TSF is designed with test and support functionality that is removed from, or
disabled in, the product prior to the Operational Use Phase.
The combination of both requirements shall enforce the policy.
5.4 Definition of the family FPT_EMSEC
The additional family FPT_EMSEC (TOE Emanation) of the Class FPT (Protection of the
TSF) is defined in the PP [R6] to describe the IT security functional requirements of the
TOE. The TOE shall prevent attacks against the SCD and other secret data where the
attack is based on external observable physical phenomena of the TOE. Examples of such
attacks are evaluation of TOE’s electromagnetic radiation, simple power analysis (SPA),
differential power analysis (DPA), timing attacks, etc. This family describes the functional
requirements for the limitation of intelligible emanations which are not directly addressed
by any other component of CC part 2 [R9].
The family “TOE Emanation (FPT_EMSEC)” is specified as follows.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 42 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 5-4 Family FPT_EMSEC
FPT_EMSEC
Family behavior: This family defines requirements to mitigate intelligible
emanations.
Component leveling:
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: There are no management activities foreseen.
Audit: There are no actions defined to be auditable.
FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components
Dependencies: No dependencies.
FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in
excess of [assignment: specified limits] enabling access to
[assignment: list of types of TSF data] and [assignment: list of
types of user data].
FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable
to use the following interface [assignment: type of connection]
to gain access to [assignment: list of types of TSF data] and
[assignment: list of types of user data].
FPT_EMSEC TOE emanation 1
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 43 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
6. Security Requirements
The CC allows several operations to be performed on functional requirements; refinement,
selection, assignment, and iteration are defined in paragraph C.4 of Part 1 [R8] of the CC.
Each of these operations is used in this PP.
The refinement operation is used to add detail to a requirement, and thus further restricts
a requirement. Refinement of security requirements is denoted by the word “refinement” in
bold text and the added/changed words are in bold text. In cases where words from a CC
requirement were deleted, a separate attachment indicates the words that were removed.
The selection operation is used to select one or more options provided by the CC in
stating a requirement. Selections that have been made by the PP authors are denoted as
underlined text and the original text of the component is given by a footnote. Selections to
be filled in by the ST author appear in square brackets with an indication that a selection is
to be made, [selection:], and are italicized.
The assignment operation is used to assign a specific value to an unspecified parameter,
such as the length of a password. Assignments that have been made by the PP authors
are denoted by showing as underlined text and the original text of the component is given
by a footnote. Assignments to be filled in by the ST author appear in square brackets with
an indication that an assignment is to be made [assignment:], and are italicized. In some
cases the assignment made by the PP authors defines a selection to be performed by the
ST author. Thus this text is underlined and italicized like this.
The iteration operation is used when a component is repeated with varying operations.
Iteration is denoted by showing a slash “/”, and the iteration indicator after the component
identifier.
The definition of the subjects “Manufacturer”, “Personalization Agent”, “Basic Inspection
System” and “Terminal” used in the following chapter is given in section 3.1. Note, that all
these subjects are acting for homonymous external entities. All used objects are defined
either in section 7 or in the following table. The operations “write”, “modify”, “read” and
“disable read access” are used in accordance with the general linguistic usage. The
operations “transmit”, “receive” and “authenticate” are originally taken from [R9].
6.1 Security Functional Requirements for the TOE
This section on security functional requirements for the TOE is divided into sub-section
following the main security functionality.
6.1.1 Class FAU Security Audit
6.1.1.1 FAU_SAS.1 Audit storage
The TOE shall meet the requirement “Audit storage (FAU_SAS.1)” as specified below (CC
part 2).
FAU_SAS.1 Audit storage
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 44 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Hierarchical to: No other components.
Dependencies: No dependencies.
FAU_SAS.1.1 The TSF shall provide the Manufacturer2
with the capability to store
the IC Identification Data3
in the audit records.
Application Note 21: The Manufacturer role is the default user identity assumed by the
TOE in the Phase 2 Manufacturing. The IC manufacturer and the MRTD Manufacturer in
the Manufacturer role write the Initialization Data and/or Pre-personalization Data as TSF
Data of the TOE. The audit records are write-only-once data of the MRTD’s chip (see
FMT_MTD.1/INI_DIS).
6.1.2 Class Cryptographic Support (FCS)
6.1.2.1 FCS_CKM.1 Cryptographic key generation
The TOE shall meet the requirement “Cryptographic key generation (FCS_CKM.1)” as
specified below (CC part 2). The iterations are caused by different cryptographic key
generation algorithms to be implemented and key to be generated by the TOE.
6.1.2.2 FCS_CKM.1/BAC Cryptographic key generation – Generation of
Document Basic Access Key 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/BAC The TSF shall generate cryptographic keys in accordance with
a specified cryptographic key generation algorithm: Document
Basic Access Key Derivation Algorithm4
and specified
cryptographic key sizes 112 bit5
, that meet the following: [R14],
normative appendix 56
.
Application Note 22: The TOE is equipped with the Document Basic Access Key
generated and downloaded by the Personalization Agent. The Basic Access Control
2
[assignment: authorised user]
3
[assignment: list of audit information]
4
[assignment: cryptographic key generation algorithm]
5
[assignment: cryptographic key sizes]
6
[assignment: list of standards]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 45 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Authentication Protocol described in [R14], normative appendix 5, A5.2, produces agreed
parameters to generate the Triple-DES key and the Retail-MAC message authentication
keys for secure messaging by the algorithm in [R14], Normative appendix A5.1. The
algorithm uses the random number RND.ICC generated by TSF as required by
FCS_RND.1.
6.1.2.3 FCS_CKM.1/CPS Cryptographic key generation – Generation of CPS
session Keys for Pre-personalization and Personalization 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/
CPS
The TSF shall generate cryptographic keys in accordance with a
specified cryptographic key generation algorithm CPS Keys
Generation Algorithm7
and specified cryptographic key sizes 112
bit8
that meet following:, [R12], section 5.29
6.1.2.4 FCS_CKM.4 Cryptographic key destruction
The TOE shall meet the requirement “Cryptographic key destruction (FCS_CKM.4)” as
specified below (CC 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: physical deletion
by overwriting the memory data with zeros10
that meets the
following: none11
.
Application Note 23: The TOE shall destroy the Triple-DES encryption key and the
Retail-MAC message authentication keys for secure messaging.
7
[assignment: cryptographic key generation algorithm]
8
[assignment: cryptographic key sizes
9
[assignment: list of standards]
10
[assignment: cryptographic key destruction method]
11
[assignment: list of standards]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 46 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
6.1.2.5 FCS_COP.1 Cryptographic operation
The TOE shall meet the requirement “Cryptographic operation (FCS_COP.1)” as specified
below (CC part 2). The iterations are caused by different cryptographic algorithms to be
implemented by the TOE.
FCS_COP.1/SHA Cryptographic operation – Hash for Key Derivation
Hierarchical to: No other components.
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 hashing12
in accordance with a specified
cryptographic algorithm SHA-1, SHA-25613
and cryptographic
key sizes none14
that meet the following: FIPS 180-2 [R24]15
.
Application Note 24: This SFR requires the TOE to implement the hash function SHA-1
for the cryptographic primitive basic Access Control Authentication Mechanism (see also
FIA_UAU.4) according to [R14]
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 The TSF shall perform secure messaging – encryption and
decryption16
in accordance with a specified cryptographic
algorithm Triple-DES in CBC mode17
and cryptographic key sizes
112 bit18
that meet the following: FIPS 46-3 [R23] and [R14];
normative appendix 5, A5.319
.
12
[assignment: list of cryptographic operations]
13
[selection: SHA-1, SHA-224, SHA-256 or other approved algorithms]
14
[assignment: cryptographic key sizes]
15
[selection: FISP 180-2 or other approved standards]
16
[assignment: list of cryptographic operations]
17
[assignment: cryptographic algorithm]
18
[assignment: cryptographic key sizes]
19
[assignment: list of standards]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 47 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Application Note 25: This SFR requires the TOE to implement the cryptographic
primitive Triple-DES for secure messaging with encryption of the transmitted data. The
keys are agreed between the TOE and the terminal as part of the Basic Access Control
Mechanism according to the FCS_CKM.1 and FIA_UAU.4.
FCS_COP.1/AUTH Cryptographic operation – Authentication
Hierarchical to: No other components.
Dependencies: [FDP_ITC.1 Import of user data without security attributes, or
FDP_ITC.2 Import of user data with security attributes, or
FCS_CKM.1 Cryptographic key generation]
FCS_CKM.4 Cryptographic key destruction
FCS_COP.1.1/AUTH The TSF shall perform symmetric authentication – encryption
and decryption20
in accordance with a specified cryptographic
algorithm Triple-DES21
and cryptographic key sizes: 112 bit 22
that meet the following: FIPS 46-323
Application Note 26: This SFR requires the TOE to implement the cryptographic
primitive for authentication attempt of a terminal as Personalization Agent by means of the
symmetric authentication mechanism (cf. FIA_UAU.4).
FCS_COP.1/MAC Cryptographic operation – Retail MAC
Hierarchical to: No other components.
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 code24
in accordance with a specified cryptographic
algorithm Retail MAC25
and cryptographic key sizes 112 bit26
that
meet the following: ISO 9797 (MAC algorithm 3, block cipher DES,
Sequence Message Counter, padding mode 2) [R18]27
.
20
[assignment: list of cryptographic operations]
21
[selection: Triple-DES, AES]
22
[selection: 112, 128, 168, 19, 256]
23
[selection: FIPS 46-3, FIPS 197]
24
[assignment: list of cryptographic operations]
25
[assignment: cryptographic algorithm]
26
[assignment: cryptographic key sizes]
27
[assignment: listo f standards]03
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 48 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Application Note 27: This SFR requires the TOE to implement the cryptographic
primitive for secure messaging with encryption and message authentication code over the
transmitted data. The key is agreed between the TSF by the Basic Access Control
Authentication Mechanism according to the FCS_CKM.1 and FIA_UAU.4.
6.1.2.6 FCS_RND.1 Quality metrics for random numbers
The TOE shall meet the requirement “Quality metric for random numbers (FCS_RND.1)”
as specified below (CC 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 BSI AIS-31 functionality class P2 [R3] (see
Application Note 29:) 28
.
Application Note 28: This SFR requires the TOE to generate random numbers used for
the authentication protocols as required by FIA_UAU.4.
Application Note 29: The TOE makes use of the true random number generator of the
IC P5CD081, which has already been evaluated as conformant to AIS31.
6.1.3 Class FIA Identification and Authentication
Application Note 30: Table 6-1 provides an overview on the authentication mechanisms
used.
28
[assignment: a defined quality metric]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 49 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 6-1 – Overview on authentication SFR
Mechanism SFR for the TOE Algorithms and key sizes according
to [R14], normative appendix 5,
and [R7]
Basic Access Control Authentication
Mechanism
FIA_UAU.4 and
FIA_UAU.6
Triple-DES, 112 bit keys (cf.
FCS_COP.1/ENC) and Retail-MAC,
112 bit keys (cf. FCS_COP.1/MAC)
Symmetric Authentication
Mechanism for
Personalization Agents and for
MRTD Manufacturers
FIA_UAU.4 Triple-DES with 112 bit keys (cf.
FCS_COP.1/AUTH)
6.1.3.1 FIA_UID.1 Timing of identification
The TOE shall meet the requirement “Timing of identification (FIA_UID.1)” as specified
below (CC 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 in Phase 3 “Personalization of the
MRTD”
3. to read the random identifier in Phase 4 “Operational Use”29
on behalf of the user to be performed before the user is identified.
FIA_UID.1.2 The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
Application Note 31: The IC manufacturer and the MRTD Manufacturer write the
Initialization Data and/or Pre-personalization Data in the audit records of the IC during the
Phase 2 “Manufacturing”. The audit records can be written only in the Phase 2
Manufacturing of the TOE. At this time the Manufacturer is the only user role available for
the TOE. The MRTD Manufacturer may create the user role Personalization Agent for
transition from Phase 2 to Phase 3 “Personalization of the MRTD”. The users in role
Personalization Agent identify by themselves by means of selecting the authentication key.
After personalization in the Phase 3 (i.e. writing the digital MRZ and the Document Basic
Access Keys) the user role Basic Inspection System is created by writing the Document
Basic Access Keys. The Basic Inspection System is identified as default user after power
29
[assignment: list of TSF-mediated actions]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 50 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
up or reset of the TOE i.e. the TOE will use the Document Basic Access Key to
authenticate the user as Basic Inspection System.
Application Note 32: In the “Operational Use” phase the MRTD must not allow anybody
to read the ICCSN, the MRTD identifier or any other unique identification before the user is
authenticated as Basic Inspection System (cf. T.Chip_ID). Note that the terminal and the
MRTD’s chip use a randomly chosen identifier for the communication channel to allow the
terminal to communicate with more then one RFID.
6.1.3.2 FIA_UAU.1 Timing of authentication
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 The TSF shall allow
1. to read the Initialization Data in Phase 2 “Manufacturing”,
2. to read the random identifier in Phase 3 “Personalization of the
MRTD”
3. to read the random identifier in Phase 4 “Operational Use”30
.
on behalf of the user to be performed before the user is
authenticated.
FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated
before allowing any other TSF-mediated actions on behalf of that
user.
Application Note 33: The Basic Inspection System and the Personalization Agent
authenticate themselves.
6.1.3.3 FIA_UAU.4 Single-use authentication mechanisms
The TOE shall meet the requirements of “Single-use authentication mechanisms
(FIA_UAU.4)” as specified below (CC part 2).
FIA_UAU.4 Single-use authentication mechanisms - Single-use authentication of the
Terminal by the TOE
Hierarchical to: No other components.
30
[assignment: list of TSF-mediated actions]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 51 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Dependencies: No dependencies.
FIA_UAU.4.1 The TSF shall prevent reuse of authentication data
related to
1. Basic Access Control Authentication
Mechanism,
2. Authentication Mechanism based on Triple-
DES31
.
Application Note 34: The authentication mechanisms may use either a challenge
freshly and randomly generated by the TOE to prevent reuse of a response generated by
a terminal in a successful authentication attempt. However, the authentication of
Personalization Agent and of MRTD Manufacturer may rely on other mechanisms ensuring
protection against replay attacks, such as the use of an internal counter as a diversifier.
Application Note 35: The Basic Access Control Mechanism is a mutual device
authentication mechanism defined in [6]. In the first step the terminal authenticates itself to
the MRTD’s chip and the MRTD’s chip authenticates to the terminal in the second step. In
this second step the MRTD’s chip provides the terminal with a challenge-response-pair
which allows a unique identification of the MRTD’s chip with some probability depending
on the entropy of the Document Basic Access Keys. Therefore the TOE shall stop further
communications if the terminal is not successfully authenticated in the first step of the
protocol to fulfill the security objective OT.Identification and to prevent T.Chip_ID.
6.1.3.4 FIA_UAU.5 Multiple authentication mechanisms
The TOE shall meet the requirement “Multiple authentication mechanisms (FIA_UAU.5)”
as specified below (CC part 2).
FIA_UAU.5 Multiple authentication mechanisms
Hierarchical to: No other components.
Dependencies: No dependencies.
FIA_UAU.5.1 The TSF shall provide
1. Basic Access Control Authentication Mechanism,
2. Symmetric Authentication Mechanism based on Triple-DES32
to support user authentication.
FIA_UAU.5.2 The TSF shall authenticate any user’s claimed identity according to
the following rules:
1. the TOE accepts the authentication attempt as MRTD
Manufacturer by one of the following mechanisms: the
Symmetric Authentication Mechanism with MRTD
31
[selecion: Triple-DES, AES or aother approved algorithms]
32
[selection: Triple-DES, AES]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 52 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Manufacturer Keys,
2. the TOE accepts the authentication attempt as Personalization
Agent by one of the following mechanisms: the Symmetric
Authentication Mechanism with Personalization Agent Key,
3. The TOE accepts the authentication attempt as Basic
Inspection System only by means of the Basic Access Control
Authentication Mechanism with the Document Basic Access
Keys33
Application Note 36: The MRTD Manufacturer authentication uses a key diversification
algorithm based on data randomly chosen by the card.
Application Note 37: The Basic Access Control Mechanism includes the secure
messaging for all commands exchanged after successful authentication of the inspection
system. The Personalization Agent may use Symmetric Authentication Mechanism without
secure messaging mechanism as well if the personalization environment prevents
eavesdropping to the communication between TOE and personalization terminal. The
Basic Inspection System may use the Basic Access Control Authentication Mechanism
with the Document Basic Access Keys.
6.1.3.5 FIA_UAU.6 Re-authenticating – Re-authenticating of Terminal by the TOE
The TOE shall meet the requirement “Re-authenticating (FIA_UAU.6)” as specified below
(CC 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 each
command sent to the TOE during a BAC mechanism based
communication after successful authentication of the terminal with
Basic Access Control Authentication Mechanism34
.
Application Note 38: The Basic Access Control Mechanism specified in [R14] includes
the secure messaging for all commands exchanged after successful authentication of the
Inspection System. The TOE checks by secure messaging in MAC_ENC mode each
command based on Retail-MAC whether it was sent by the successfully authenticated
terminal (see FCS_COP.1/MAC for further details). The TOE does not execute any
command with incorrect message authentication code. Therefore the TOE re-
33
[assignment: rules describing how the multiple authentication mechanisms provide authentication]
34
[assignment: list of conditions under which re-authentication is required]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 53 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
authenticates the user for each received command and accepts only those commands
received from the previously authenticated BAC user.
Application Note 39: Note that in case the TOE should also fulfill [R6] the BAC
communication might be followed by a Chip Authentication mechanism establishing a new
secure messaging that is distinct from the BAC based communication. In this case the
condition in FIA_UAU.6 above should not contradict to the option that commands are sent
to the TOE that are no longer meeting the BAC communication but are protected by a
more secure communication channel established after a more advanced authentication
process.
6.1.3.6 FIA_AFL.1 Authentication failure handling
The TOE shall meet the requirement “Authentication failure handling (FIA_AFL.1)” as
specified below (CC part 2).
FIA_AFL.1 Authentication failure handling
Hierarchical to: No other components.
Dependencies: FIA_UAU.1 Timing of authentication
FIA_AFL.1.1 The TSF shall detect when a defined number of consecutive35
unsuccessful authentication attempts occur related to the
authentication events specified in column 1 of Table 6-236
. 37
FIA_AFL.1.2 When the defined number of consecutive unsuccessful authentication
attempts has been met38
, the TSF shall perform the actions
specified in column 2 of Table 6-239
.
Refinement: refer to Table 6-2.
35
[assignement: positive integer number]
36
[assignment: list of authentication events]
37
[selection: [assignment: positive integer number], an administrator configurable positive integer within
[assignment: range of acceptable values]]
38
[selection: met, surpassed]
39
[assignment: list of actions]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 54 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 6-2 FIA_AFL.1 Refinement
Column 1
Assignment:
Authentication Events
Column 2
Assignment:
Actions
Unsuccessful BAC authentication The outcome of the authentication is
issued with a delay, in order to
prevent brute-force attacks.
Unsuccessful MAC verification after BAC
authentication
Session closed
Unsuccessful mutual authentication with
MRTD Manufacturer keys
MRTD Manufacturer keys blocked
Unsuccessful mutual authentication with
Personalization Agent keys
Personalization Agent keys blocked
6.1.4 Class FDP User Data Protection
6.1.4.1 FDP_ACC.1 Subset access control
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
Hierarchical to: No other components.
Dependencies: FDP_ACF.1 Security attribute based access control
FDP_ACC.1.1 The TSF shall enforce the Basic Access Control SFP40
on
terminals gaining write, read and modification access to data
in the EF.COM, EF.SOD, EF.DG1 to EF.DG14, EF.DG16 of
the logical MRTD41
.
Application Note 40: Access to EF.DG15 is not listed in FDP_ACC.1.1 because this ST
does not address Active Authentication.
6.1.4.2 FDP_ACF.1 Basic Security attribute based access control
The TOE shall meet the requirement “Security attribute based access control
(FDP_ACF.1)” as specified below (CC part 2).
FDP_ACF.1 Basic Security attribute based access control
Hierarchical to: No other components.
40
[assignment: access control SFP]
41
[assignment: list of subjects, objects, and operations among subjects and objects covered by the SFP]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 55 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Dependencies: FDP_ACC.1 Subset access control
FMT_MSA.3 Static attribute initialization
FDP_ACF.1.1 The TSF shall enforce the Basic Access Control SFP42
to
objects based on the following:
1. Subjects:
a. Personalization Agent,
b. Basic Inspection System,
c. Terminal.
2. Objects:
a. data EF.DG1 to EF.DG14, EF.DG16 of the logical
MRTD,
b. data in EF.COM,
c. data in EF.SOD.
3. Security attributes:
a. authentication status of terminals43
.
-
FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is
allowed:
1. the successfully authenticated Personalization Agent is
allowed to write and to read the data of the EF.COM,
EF.SOD, EF.DG1 to EF.DG14, EF.DG16 of the logical
MRTD,
2. the successfully authenticated Basic Inspection System
is allowed to read the data in EF.COM, EF.SOD,
EF.DG1, EF.DG2 and EF.DG5 to EF.DG14, EF.DG16
of the logical MRTD44
.
FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects
based on the following additional rules: none45
.
FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects
based on the rule:
1. Any Terminal is not allowed to modify any of the
42
[assignment: access control SFP]
43
[assignment: list of subjects and objects controlled under the indicated SFP, and, for each, the SFP-
relevant security attributes, or named groups of SFP-relevant security attributes]
44
[assignment: rules governing access among controlled subjects and controlled objects using controlled
operations or controlled objects]
45
[assignment: rules, based on security attributes, that explicitly authorise access of subjects to objects]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 56 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
EF.DG1 to EF.DG14, EF.DG16 of the logical MRTD
2. Any Terminal is not allowed to read any of the EF.DG1
to EF.DG14, EF.DG16 of the logical MRTD
3. The Basic Inspection System is not allowed to read the
data in EF.DG3 and EF.DG446
Application Note 41: The inspection system needs special authentication and
authorization for read access to DG3 and DG4 not defined in this security target (cf. [R13]
for details).
Application Note 42: Access to EF.DG.15 is not listed in FDP_ACF.1 because this ST
does not address Active Authentication.
Inter-TSF-Transfer
Application Note 43: FDP_UCT.1 and FDP_UIT.1 require the protection of the User
Data transmitted from the TOE to the terminal by secure messaging with encryption and
message authentication codes after successful authentication of the terminal. The
authentication mechanisms as part of Basic Access Control Mechanism include the key
agreement for the encryption and the message authentication key to be used for secure
messaging.
6.1.4.3 FDP_UCT.1 Basic data exchange confidentiality
The TOE shall meet the requirement “Basic data exchange confidentiality (FDP_UCT.1)”
as specified below (CC 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 Basic Access Control SFP47
to be
able to transmit and receive48
user data in a manner protected
from unauthorized disclosure.
46
[assignment: rules, based on security attributes, that explicitly deny access of subjects to objects]
47
[assignment: access control SFP(s) and/or information flow control SFP(s)]
48
[selection: transmit, receive]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 57 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
6.1.4.4 FDP_UIT.1 Data exchange integrity
The TOE shall meet the requirement “Basic data exchange integrity (FDP_UIT.1)” as
specified below (CC part 2).
FDP_UIT.1 Data exchange integrity - MRTD
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 The TSF shall enforce the Basic Access Control SFP49
to be able to
transmit and receive50
user data in a manner protected from
modification, deletion, insertion and replay51
errors.
FDP_UIT.1.2 The TSF shall be able to determine on receipt of user data, whether
modification, deletion, insertion and replay52
has occurred.
6.1.5 Class FMT Security Management
Application Note 44: The SFR FMT_SMF.1 and FMT_SMR.1 provide basic
requirements to the management of the TSF data.
6.1.5.1 FMT_SMF.1 Specification of Management Functions
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
49
[assignment: access control SFP(s) and/or information flow control SFP(s)]
50
[selection: transmit, receive]
51
[selection: modification, deletion, insertion, replay]
52
[selection: modification, deletion, insertion, replay]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 58 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
FMT_SMF.1.1 The TSF shall be capable of performing the following security
management functions:
1. Initialization,
2. Pre-Personalization,
3. Personalization53
.
Application Note 45: The ability to initialize, personalize and configure the TOE is
restricted to a successfully authenticated MRTD Manufacturer or Personalization Agent by
means of symmetric keys. MRTD Manufacturer Keys are only active in uninitialized
products. Personalization Agent Keys are only active in initialized but not personalized
products. The MRTD locks out after a programmable number of consecutive unsuccessful
authentication attempts. The MRTD Manufacturer Keys are disabled once initialization is
complete.
6.1.5.2 FMT_SMR.1 Security roles
The TOE shall meet the requirement “Security roles (FMT_SMR.1)” as specified below
(CC part 2).
FMT_SMR.1 Security roles
Hierarchical to: No other components.
Dependencies: FIA_UID.1 Timing of identification.
FMT_SMR.1.1 The TSF shall maintain the roles:
1. IC Manufacturer
2. MRTD Manufacturer
3. Personalization Agent
4. Basic Inspection System 54
.
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Application Note 46: The SFR FMT_LIM.1 and FMT_LIM.2 address the management of
the TSF and TSF data to prevent misuse of test features of the TOE over the life cycle
phases.
6.1.5.3 FMT_LIM.1 Limited capabilities
The TOE shall meet the requirement “Limited capabilities (FMT_LIM.1)” as specified below
(CC part 2 extended).
53
[assignment: list of security management functions to be provided by the TSF]
54
[assignment: the authorised identified roles]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 59 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
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,
3. software to be reconstructed and
4. substantial information about construction of TSF to be gathered
which may enable other attacks55
.
6.1.5.4 FMT_LIM.2 Limited availability
The TOE shall meet the requirement “Limited availability (FMT_LIM.2)” as specified below
(CC 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 attacks56
.
Application Note 47: The formulation of “Deploying Test Features …” in FMT_LIM.2.1
might be a little bit misleading since the addressed features are no longer available (e.g.
by disabling or removing the respective functionality). Nevertheless the combination of
FMT_LIM.1 and FMT_LIM.2 is introduced to provide an optional approach to enforce the
same policy.
Note that the term “software” in item 3 of FMT_LIM.1.1 and FMT_LIM.2.1 refers to both IC
Dedicated and IC Embedded Software.
55
[assignment: limited capability and availability policy]
56
[assignment: Limited capability and availability policy]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 60 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
6.1.5.5 FMT_MTD.1 Management of TSF data
Application Note 48: the following SFR are iterations of the component Management of
TSF data (FMT_MTD.1). The TSF data include but are not limited to those identified
below.
The TOE shall meet the requirement “Management of TSF data (FMT_MTD.1)” as
specified below (CC part 2). The iterations address different management functions and
different TSF data.
FMT_MTD.1/INI_ENA Management of TSF data – Writing of Initialization Data and
Pre-personalization Data
Hierarchical to: No other components.
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 write57
the Initialization Data
and Pre-personalization Data58
to the Manufacturer59
.
Application Note 49: the pre-personalization Data includes but is not limited to the
authentication reference data for the Personalization Agent, which is the symmetric
cryptographic Personalization Agent Authentication Key.
Application Note 50: Initialization Data are written by the IC Manufacturer and Pre-
personalization Data are written by the MRTD Manufacturer, according to the description
given in section 1.5.3.
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
FMT_MTD.1.1/
INI_DIS
The TSF shall restrict the ability to disable read access for users to60
the Initialization Data61
to the IC Manufacturer and to the IC
Manufacturer62
.
57
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
58
[assignment: list of TSF data]
59
[assignment: the authorised identified roles]
60
[selection: change_default, query, modify, dolete, clear, [assignment: other operations]]
61
[assignment: list of TSF data]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 61 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Application Note 51: After Phase 2 “Manufacturing” the read access conditions to
Initialization Data and Pre-personalization Data cannot be modified by anyone. This is a
more restrictive requirement than the one defined in the PP.
Application Note 52: According to P.Manufact the IC Manufacturer and the MRTD
Manufacturer are the default users assumed by the TOE in the role Manufacturer during
the Phase 2 “Manufacturing”. The TOE may restrict the ability to write the Initialization
Data and the Pre-personalization Data by:
i. allowing to write these data only once and
ii. blocking the role Manufacturer at the end of the Phase 2.
The IC Manufacturer may write the Initialization Data which includes but are not limited to
the IC Identifier as required by FAU_SAS.1. The Initialization Data provides an unique
identification of the IC which is used to trace the IC in the Phase 2 and 3 “personalization”
but is not needed and may be misused in the Phase 4 “Operational Use”. Therefore the
external read access shall be blocked. The MRTD Manufacturer will write the Pre-
personalization Data.
FMT_MTD.1/KEY_WRITE Management of TSF data – 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 write63
the Document Basic
Access Keys64
to the Personalization Agent65
.
FMT_MTD.1/ADDTSF_WRITE Management of TSF data – Additional TSF data Write
Hierarchical to: No other components.
Dependencies: FMT_SMF.1 Specification of management functions
FMT_SMR.1 Security roles
FMT_MTD.1.1/
ADDTSF_WRITE
The TSF shall restrict the ability to write66
the Security
Environment object and the Document Number to the
Personalization Agent67
.
62
[assignment: the authorised identified roles]
63
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
64
[assignment: list of TSF data]
65
[assignment: the authorised identified roles]
66
[selection: change_default, query, modify, dolete, clear, [assignment: other operations]]
67
[assignment: the authorised identified roles]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 62 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Application Note 53: The Security environment object stores links to internal data
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
FMT_MTD.1.1/
KEY_READ
The TSF shall restrict the ability to read68
the Document Basic
Access Keys and the Personalization Agent Keys 69
to none70
.
Application Note 54: The Personalization Agent generates, stores and ensures the
correctness of the Document Basic Access Keys.
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.
6.1.6.1 FPT_EMSEC.1 TOE emanation
The TOE shall meet the requirement “TOE emanation (FPT_EMSEC.1)” as specified
below (CC part 2 extended):
FPT_EMSEC.1 TOE Emanation
Hierarchical to: No other components.
Dependencies: No dependencies.
68
[selection: change_default, query, modify, delete, clear, [assignment: other operations]]
69
[assignment: list of TSF data]
70
[assignment: the authorised identified roles]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 63 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
FPT_EMSEC.1.1 The TOE shall not emit electromagnetic and current emissions71
in excess of intelligible threshold72
enabling access to
Personalization Agent Key73
and EF.DG1 to EF.DG14, EF.DG16,
EF.SOD, EF.COM74
FPT_EMSEC.1.2 The TSF shall ensure any users75
are unable to use the following
interface smart card circuits contacts76
to gain access to
Personalization Agent Keys77
and EF.DG1 to EF.DG14, EF.DG16,
EF.SOD, EF.COM78
Application Note 55: The TOE shall prevent attacks against the listed secret data where
the attack is based on external observable physical phenomena of the TOE. Such attacks
may be observable at the interfaces of the TOE or may origin from internal operation of the
TOE or may origin by an attacker that varies the physical environment under which the
TOE operates. The set of measurable physical phenomena is influenced by the technology
employed to implement the smart card. The MRTD’s chip has to provide a smart card
contactless interface but may have also (not used by the terminal but maybe by an
attacker) additional contacts according to ISO/IEC 7816-2 as well. This TOE does not
support any contact based communication protocol like ISO/IEC 7816-3. Examples of
measurable phenomena include, but are not limited to variations in the power
consumption, the timing of signals and the electromagnetic radiation due to internal
operations or data transmissions.
6.1.6.2 FPT_FLS Failure with preservation of secure state
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
71
[assignment: type of emissions]
72
[assignment: specified limits]
73
[assignment: list of types of TSF data]
74
[assignment: list of types of user data]
75
[assignment: type of users]
76
[assignment: type of connection]
77
[assignment: list of types of TSF data]
78
[assignment: list of types of user data]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 64 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of
failures occur:
1. exposure to operating conditions where therefore a malfunction could
occur,
2. failure detected by TSF according to FPT_TST.179
6.1.6.3 FPT_TST.1 TSF testing
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 The TSF shall run a suite of self tests during initial start-up, and
before any use of TSF data80
to demonstrate the correct operation
of the TSF.
FPT_TST.1.2 The TSF shall provide authorized users with the capability to verify
the integrity of TSF data.
FPT_TST.1.3 The TSF shall provide authorized users with the capability to verify
the integrity of stored TSF executable code.
6.1.6.4 FPT_PHP.3 Resistance to physical attack
The TOE shall meet the requirement “Resistance to physical attack (FPT_PHP.3)” as
specified below (CC 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 probing81
to
the TSF82
by responding automatically such that the SFRs are
always enforced.
Application Note 56: The TOE will use appropriate countermeasures implemented by
the IC manufacturer to continuously counter physical manipulation and physical probing.
Due to the nature of these attacks (especially manipulation) the TOE can by no means
79
[assignment: list of types of failures in the TSF]
80
[selection: during initial start-up, periodically during normal operation, at the request of the authorised user,
at the conditions [assignment: conditions under which sel test should occur]]
81
[assignment: physical tampering scenarios]
82
[assignment: list of TSF devices/elements]
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 65 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
detect attacks on all of its elements. Therefore, permanent protection against these attacks
is required ensuring that the TSP could not be violated at any time. Hence, “automatic
response” means here:
• assuming that there might be an attack at any time and
• countermeasures are provided at any time.
6.2 Security Assurance Requirements for the TOE
The components 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 component ALC_DVS.2.
Table 6-3 summarizes the assurance components that define the security assurance
requirements for the TOE.
Table 6-3 Assurance requirements at EAL4+
Assurance Class Assurance Components
ADV ADV_ARC.1, ADV_FSP.4, ADV_IMP.1, ADV_TDS.3
AGD AGD_OPE.1, AGD_PRE.1
ALC ALC_CMC.4, ALC_CMS.4, ALC_DEL.1, ALC_DVS.2,
ALC_LCD.1, ALC_TAT.1
ASE ASE_CCL.1, ASE_ECD.1, ASE_INT.1, ASE_OBJ.2,
ASE_REQ.2, ASE_SPD.1, ASE_TSS.1
ATE ATE_COV.2, ATE_DPT.1, ATE_FUN.1, ATE_IND.2
AVA AVA_VAN.3
6.3 Security Requirements Rationale
6.3.1 Security functional requirements rationale
Table 6-4 provides an overview for security functional requirements coverage of security
objectives.
Table 6-4 Coverage of Security Objectives for the TOE by SFR
OT.AC_Pers
OT.Data_Int
OT.Data_Conf
OT.Identification
OT.Prot_Inf_Leak
OT.Prot_Phys-Tamper
OT.Prot_Malfunction
OT.Prot_Abuse-Func
FAU_SAS.1 x
FCS_CKM.1/BAC x x x
FCS_CKM.1/CPS x x
FCS_CKM.4 x x
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 66 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
FCS_COP.1/SHA x x x
FCS_COP.1/ENC x x x
FCS_COP.1/AUTH x x
FCS_COP.1/MAC x x x
FCS_RND.1 x x x
FIA_UID.1 x x
FIA_AFL.1 x x
FIA_UAU.1 x x
FIA_UAU.4 x x x
FIA_UAU.5 x x x
FIA_UAU.6 x x x
FDP_ACC.1 x x x
FDP_ACF.1 x x x
FDP_UCT.1 x x x
FDP_UIT.1 x x x
FMT_SMF.1 x x x
FMT_SMR.1 x x x
FMT_LIM.1 x
FMT_LIM.2 x
FMT_MTD.1/INI_ENA x
FMT_MTD.1/INI_DIS x
FMT_MTD.1/KEY_WRITE x x x
FMT_MTD.1/ADDTSF_WRITE x x
FMT_MTD.1/KEY_READ x x x
FPT_EMSEC.1 x x
FPT_TST.1 x x
FPT_FLS.1 x x x
FPT_PHP.3 x x x
The security objective OT.AC_Pers “Access Control for Personalization of logical MRTD”
addresses the access control of the writing the logical MRTD. The write access to the
logical MRTD data are defined by the SFR FDP_ACC.1 and FDP_ACF.1 as follows: only
the successfully authenticated Personalization Agent is allowed to write the data of the
groups EF.DG1 to EF.DG16 of the logical MRTD only once.
The authentication of the terminal as Personalization Agent shall be performed by TSF
according to SRF FIA_UAU.4 and FIA_UAU.5. The Personalization Agent can be
authenticated either by using the BAC mechanism (FCS_CKM.1/BAC, FCS_COP.1/SHA,
FCS_RND.1 (for key generation), and FCS_COP.1/ENC as well as FCS_COP.1/MAC)
with the personalization key or for reasons of interoperability with the [R6] by using the
symmetric authentication mechanism (FCS_COP.1/AUTH).
In case of using the BAC mechanism the SFR FIA_UAU.6 describes the re-authentication
and FDP_UCT.1 and FDP_UIT.1 the protection of the transmitted data by means of
secure messaging implemented by the cryptographic functions according to FCS_CKM.1,
FCS_COP.1/SHA, FCS_RND.1 (for key generation), and FCS_COP.1/ENC as well as
FCS_COP.1/MAC for the ENC_MAC_Mode.
The SFR FMT_SMR.1 lists the roles (including Personalization Agent) and the SFR
FMT_SMF.1 lists the TSF management functions (including Personalization) setting the
Document Basic Access Keys according to the SFR FMT_MTD.1/KEY_WRITE as
authentication reference data. The SFR FMT_MTD.1/KEY_READ prevents read access to
the secret key of the Personalization Agent Keys and ensure together with the SFR
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 67 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
FCS_CKM.4, FPT_EMSEC.1, FPT_FLS.1 and FPT_PHP.3 the confidentially of these
keys. The Personalization Agent handles the security environment object and the
document number according to the SFR FMT_MTD.1/ADDTSF_WRITE. The SFR
FCS_CKM.1/CPS allows to protect the transmitted data by means secure messaging
during the initialization and personalization processes.
The security objective OT.Data_Int “Integrity of personal data” requires the TOE to protect
the integrity of the logical MRTD stored on the MRTD’s chip against physical manipulation
and unauthorized writing. The write access to the logical MRTD data is defined by the SFR
FDP_ACC.1 and FDP_ACF.1 in the same way: only the Personalization Agent is allowed
to write the data of the groups EF.DG1 to EF.DG16 of the logical MRTD (FDP_ACF.1.2,
rule 1) and terminals are not allowed to modify any of the data groups EF.DG1 to
EF.DG16 of the logical MRTD (cf. FDP_ACF.1.4). The SFR FMT_SMR.1 lists the roles
(including Personalization Agent) and the SFR FMT_SMF.1 lists the TSF management
functions (including Personalization). The authentication of the terminal as Personalization
Agent shall be performed by TSF according to SRF FIA_UAU.4, FIA_UAU.5 and
FIA_UAU.6 using either FCS_COP.1/ENC and FCS_COP.1/MAC or FCS_COP.1/AUTH.
The security objective OT.Data_Int “Integrity of personal data” requires the TOE to ensure
that the inspection system is able to detect any modification of the transmitted logical
MRTD data by means of the BAC mechanism. The SFR FIA_UAU.6, FDP_UCT.1 and
FDP_UIT.1 requires the protection of the transmitted data by means of secure messaging
implemented by the cryptographic functions according to FCS_CKM.1, FCS_COP.1/SHA,
FCS_RND.1 (for key generation), FCS_CKM.1/CPS (for the generation of the initialization
and personalization keys) and FCS_COP.1/ENC and FCS_COP.1/MAC for the
ENC_MAC_Mode. The SFR FMT_MTD.1/KEY_WRITE requires the Personalization Agent
to establish the Document Basic Access Keys in a way that they cannot be read by
anyone in accordance to FMT_MTD.1/KEY_READ.
The security objective OT.Data_Conf “Confidentiality of personal data” requires the TOE
to ensure the confidentiality of the logical MRTD data groups EF.DG1 to EF.DG16. The
SFR FIA_UID.1 and FIA_UAU.1 allow only those actions before identification respective
authentication which do not violate OT.Data_Conf. In case of failed authentication
attempts FIA_AFL.1 enforces additional waiting time prolonging the necessary amount of
time for facilitating a brute force attack. The read access to the logical MRTD data is
defined by the FDP_ACC.1 and FDP_ACF.1.2: the successful authenticated
Personalization Agent is allowed to read the data of the logical MRTD (EF.DG1 to
EF.DG16). The successful authenticated Basic Inspection System is allowed to read the
data of the logical MRTD (EF.DG1, EF.DG2 and EF.DG5 to EF.DG16). The SFR
FMT_SMR.1 lists the roles (including Personalization Agent and Basic Inspection System)
and the SFR FMT_SMF.1 lists the TSF management functions (including Personalization
for the key management for the Document Basic Access Keys).
The SFR FIA_UAU.4 prevents reuse of authentication data to strengthen the
authentication of the user. The SFR FIA_UAU.5 enforces the TOE to accept the
authentication attempt as Basic Inspection System only by means of the Basic Access
Control Authentication Mechanism with the Document Basic Access Keys. Moreover, the
SFR FIA_UAU.6 requests secure messaging after successful authentication of the
terminal with Basic Access Control Authentication Mechanism which includes the
protection of the transmitted data in ENC_MAC_Mode by means of the cryptographic
functions according to FCS_COP.1/ENC and FCS_COP.1/MAC (cf. the SFR FDP_UCT.1
and FDP_UIT.1). (for key generation), and FCS_COP.1/ENC and FCS_COP.1/MAC for
the ENC_MAC_Mode. The SFR FCS_CKM.1, FCS_CKM.4, FCS_COP.1/SHA and
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 68 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
FCS_RND.1 establish the key management for the secure messaging keys. The SFR
FMT_MTD.1/KEY_WRITE and FMT_MTD.1/ADDTSF_DATA addresses the key
management and FMT_MTD.1/KEY_READ prevents reading of the Document Basic
Access Keys.
Note, neither the security objective OT.Data_Conf nor the SFR FIA_UAU.5 requires the
Personalization Agent to use the Basic Access Control Authentication Mechanism or
secure messaging.
The security objective OT.Identification “Identification and Authentication of the TOE”
address the storage of the IC Identification Data uniquely identifying the MRTD’s chip in its
non-volatile memory. This will be ensured by TSF according to SFR FAU_SAS.1.
Furthermore, the TOE shall identify itself only to a successful authenticated Basic
Inspection System in Phase 4 “Operational Use”. The SFR FMT_MTD.1/INI_ENA allows
only the Manufacturer to write Initialization Data and Pre-personalization Data (including
the Personalization Agent key). The SFR FMT_MTD.1/INI_DIS allows the Personalization
Agent to disable Initialization Data if their usage in the phase 4 “Operational Use” violates
the security objective OT.Identification. The SFR FIA_UID.1 and FIA_UAU.1 do not allow
reading of any data uniquely identifying the MRTD’s chip before successful authentication
of the Basic Inspection Terminal and will stop communication after unsuccessful
authentication attempt (cf. Application Note 35:). In case of failed authentication attempts
FIA_AFL.1 enforces additional waiting time prolonging the necessary amount of time for
facilitating a brute force attack.
The security objective OT.Prot_Abuse-Func “Protection against Abuse of Functionality” is
ensured by the SFR FMT_LIM.1 and FMT_LIM.2 which prevent misuse of test functionality
of the TOE or other features which may not be used after TOE Delivery.
The security objective OT.Prot_Inf_Leak “Protection against Information Leakage”
requires the TOE to protect confidential TSF data stored and/or processed in the MRTD’s
chip against disclosure:
• by measurement and analysis of the shape and amplitude of signals or the time
between events found by measuring signals on the electromagnetic field, power
consumption, clock, or I/O lines, which is addressed by the SFR FPT_EMSEC.1,
• by forcing a malfunction of the TOE, which is addressed by the SFR FPT_FLS.1
and FPT_TST.1, and/or
• by a physical manipulation of the TOE, which is addressed by the SFR FPT_PHP.3.
The security objective OT.Prot_Phys-Tamper “Protection against Physical Tampering” is
covered by the SFR FPT_PHP.3.
The security objective OT.Prot_Malfunction “Protection against Malfunctions” is covered
by:
i. the SFR FPT_TST.1 which requires self tests to demonstrate the correct
operation and tests of authorized users to verify the integrity of TSF data and
TSF code,
ii. the SFR FPT_FLS.1 which requires a secure state in case of detected failure
or operating conditions possibly causing a malfunction.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 69 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
6.3.2 Dependency Rationale
The dependency analysis for the security functional requirements shows that the basis for
mutual support and internal consistency between all defined functional requirements is
satisfied. All dependencies between the chosen functional components are analyzed, and
non-dissolved dependencies are appropriately explained.
Table 6-5 shows the dependencies between the SFR of the TOE.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 70 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 6-5 Dependencies between the SFR for the TOE
SFR Dependencies Support of the Dependencies
FAU_SAS.1 No dependencies n.a.
FCS_CKM.1/BAC [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 cryptographic operation],
FCS_CKM.4 Cryptographic key destruction
Fulfilled by FCS_COP.1/ENC and
FCS_COP.1/MAC
Fulfilled by FCS_CKM.4,
FCS_CKM.1/CPS [FCS_CKM.2 Cryptographic key distribution or
FCS_COP.1 cryptographic operation],
FCS_CKM.4 Cryptographic key destruction
Fulfilled by FCS_COP.1/ENC,
FCS_COP.1/MAC
Fulfilled by FCS_CKM.4,
FCS_CKM.4 [FDP_ITC.1 Import of user data without security
attributes,
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation]
Fulfilled by FCS_CKM.1
FCS_COP.1/SHA [FDP_ITC.1 Import of user data without security
attributes,
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1Cryptographic key generation],
FCS_CKM.4 Cryptographic key destruction
Justification 1 for non-satisfied
dependencies
Fulfilled by FCS_CMK.4
FCS_COP.1/ENC [FDP_ITC.1 Import of user data without security
attributes,
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1Cryptographic key generation],
FCS_CKM.4 Cryptographic key destruction
Fulfilled by FCS_CKM.1,
Fulfilled by FCS_CKM.4
FCS_COP.1/AUTH [FDP_ITC.1 Import of user data without security
attributes,
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation],
FCS_CKM.4 Cryptographic key destruction
Justification 2 for non-satisfied
dependencies
Justification 2 for non-satisfied
dependencies
FCS_COP.1/MAC [FDP_ITC.1 Import of user data without security
attributes,
FDP_ITC.2 Import of user data with security
attributes, or
FCS_CKM.1 Cryptographic key generation],
FCS_CKM.4 Cryptographic key destruction
Fulfilled by FCS_CKM.1,
Fulfilled by FCS_CKM.4
FCS_RND.1 No dependencies n.a.
FCS_AFL.1 FIA_UAU.1 Timing of authentication Fulfilled by FIA_UAU.1
FIA_UID.1 No dependencies n.a.
FIA_UAU.1 FIA_UID.1 Timing of identification Fulfilled by FIA_UID.1
FIA_UAU.4 No dependencies n.a.
FIA_UAU.5 No dependencies n.a.
FIA_UAU.6 No dependencies n.a.
FIA_AFL.1 No dependencies n.a.
FDP_ACC.1 FDP_ACF.1 Security attribute based access
control
Fulfilled by FDP_ACF.1
FDP_ACF.1 FDP_ACC.1 Subset access control,
FMT_MSA.3 Static attribute initialization
Fulfilled by FDP_ACC.1
Justification 3 for non-satisfied
dependencies
FDP_UCT.1 [FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path],
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
Justification 4 for non-satisfied
dependencies
FDP_ACC.1
FDP_UIT.1 [FTP_ITC.1 Inter-TSF trusted channel, or
FTP_TRP.1 Trusted path],
Justification 4 for non-satisfied
dependencies
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 71 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
SFR Dependencies Support of the Dependencies
[FDP_ACC.1 Subset access control, or
FDP_IFC.1 Subset information flow control]
Fulfilled by FDP_ACC.1
FMT_SMF.1 No dependencies n.a.
FMT_SMR.1 FIA_UID.1 Timing of identification Fulfilled by FIA_UID.1
FMT_LIM.1 FMT_LIM.2 Fulfilled by FMT_LIM.2
FMT_LIM.2 FMT_LIM.1 Fulfilled by FMT_LIM.1
FMT_MTD.1/INI_ENA FMT_SMF.1 Specification of management
functions,
FMT_SMR.1 Security roles
Fulfilled by FMT_SMF.1
Fulfilled by FMT_SMR.1
FMT_MTD.1/INI_DIS FMT_SMF.1 Specification of management
functions,
FMT_SMR.1 Security roles
Fulfilled by FMT_SMF.1
Fulfilled by FMT_SMR.1
FMT_MTD.1/KEY_READ FMT_SMF.1 Specification of management
functions,
FMT_SMR.1 Security roles
Fulfilled by FMT_SMF.1
Fulfilled by FMT_SMR.1
FMT_MTD.1/KEY_WRITE FMT_SMF.1 Specification of management
functions,
FMT_SMR.1 Security roles
Fulfilled by FMT_SMF.1
Fulfilled by FMT_SMR.1
FMT_MTD.1/ADDTSF_WRI
TE
FMT_SMF.1 Specification of management
functions,
FMT_SMR.1 Security roles
Fulfilled by FMT_SMF.1
Fulfilled by FMT_SMR.1
FPT_EMSEC.1 No dependencies n.a.
FPT_FLS.1 No dependencies n.a.
FPT_PHP.3 No dependencies n.a.
FPT_TST.1 No dependencies n.a.
Justifications for non-satisfied dependencies between the SFR for TOE:
Justification 1: The hash algorithm required by the SFR FCS_COP.1/SHA does not need
any key material. Therefore neither a key generation (FCS_CKM.1) nor an import
(FDP_ITC.1/2) is necessary.
Justification 2: The SFR FCS_COP.1/AUTH uses the symmetric Personalization Key
permanently stored during the Pre-Personalization process (cf. FMT_MTD.1/INI_ENA) by
the manufacturer. Thus there is neither the necessity to generate or import a key during
the addressed TOE lifecycle by the means of FCS_CKM.1 or FDP_ITC. Since the key is
permanently stored within the TOE there is no need for FCS_CKM.4, too.
Justification 3: The access control TSF according to FDP_ACF.1 uses security attributes
which are defined during the personalization and are fixed over the whole life time of the
TOE. No management of these security attribute (i.e. SFR FMT_MSA.1 and FMT_MSA.3)
is necessary here.
Justification 4: The SFR FDP_UCT.1 and FDP_UIT.1 require the use secure messaging
between the MRTD and the BIS. There is no need for the SFR FTP_ITC.1, e.g. to require
this communication channel to be logically distinct from other communication channels
since there is only one channel. Since the TOE does not provide a direct human interface
a trusted path as required by FTP_TRP.1 is not applicable here.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 72 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
6.3.3 Security Assurance Requirements Rationale
The EAL4 was chosen to permit a developer to gain maximum assurance from positive
security engineering based on good commercial development practices which, though
rigorous, do not require substantial specialist knowledge, skills, and other resources. EAL4
is the highest level at which it is likely to be economically feasible to retrofit to an existing
product line. EAL4 is applicable in those circumstances where developers or users require
a moderate to high level of independently assured security in conventional commodity
TOEs and are prepared to incur sensitive security specific engineering costs.
The TOE assurance level is augmented with respect to the EAL4 package for what refers
to development security (ALC_DVS.2 instead of ALC_DVS.1).
The selection of the component ALC_DVS.2 provides a higher assurance of the security of
the MRTD’s development and manufacturing, especially for the secure handling of the
MRTD’s material.
The component ALC_DVS.2 augmented to EAL4 has no dependencies to other security
requirements.
6.3.4 Security Requirements – Mutual Support and Internal Consistency
The following part of the security requirements rationale shows that the set of security
requirements for the TOE consisting of the security functional requirements (SFRs) and
the security assurance requirements (SARs) together form a mutually supportive and
internally consistent whole.
The analysis of the TOE´s security requirements with regard to their mutual support and
internal consistency demonstrates:
• The dependency analysis in section 6.3.2 Dependency Rationale for the security
functional requirements shows that the basis for mutual support and internal
consistency between all defined functional requirements is satisfied. All
dependencies between the chosen functional components are analyzed, and non-
satisfied dependencies are appropriately explained.
• The assurance class EAL4 is an established set of mutually supportive and
internally consistent assurance requirements. The dependency analysis for the
sensitive assurance components in section 6.3.3 Security Assurance Requirements
Rationale shows that the assurance requirements are mutually supportive and
internally consistent as all (sensitive) dependencies are satisfied and no
inconsistency appears.
Inconsistency between functional and assurance requirements could only arise if there are
functional assurance dependencies which are not met, a possibility which has been shown
not to arise in section 6.3.2 “Dependency Rationale” and 6.3.3 Security Assurance
Requirements Rationale. Furthermore, as also discussed in section 6.3.3 Security
Assurance Requirements Rationale, the chosen assurance components are adequate for
the functionality of the TOE. So the assurance requirements and security functional
requirements support each other and there are no inconsistencies between the goals of
these two groups of security requirements.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 73 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
7. TOE Summary Specification
The following sections provide a general understanding of how the TOE is implemented.
To facilitate reading, the description of the security features of the TOE is organized in
security services. Table 7-2. provides a mapping between SFRs and security services.
7.1 Coverage of SFRs
7.1.1 SS.AG_ID_AUTH Agents Identification & Authentication
This security service meets the following SFRs:
FCS_CKM.4, FCS_COP.1/SHA, FCS_COP.1/ENC, FCS_COP.1/MAC,
FCS_COP.1/AUTH, FIA_UID.1, FIA_UAU.1, FIA_UAU.4, FIA_UAU.5, FIA_AFL.1.
Access to functions and data of the TOE is only allowed to authenticated users. The
authentication mechanism applied depends on the system used for operations. Table 7-1
summarizes the authentication mechanisms for the various systems, later detailed in this
section.
Table 7-1 Summary of authentication mechanisms
System type MRTD Life-Cycle
status
Authentication Mechanism
Initialization and Pre-
personalization
system
Non-Initialized Symmetric authentication with MRTD
Manufacturer Keys
Personalization
System
Initialized Symmetric authentication with
Personalization Agent Keys
Basic Inspection
System
Operational BAC with Triple-DES algorithm and 112
byte Document Basic Access Keys
The MRTD Manufacturer and the Personalization Agent authenticate themselves to the e-
Passport by means of a mutual authentication mechanism (FIA_UID.1, FIA_UAU.1,
FIA_UAU.5). The algorithm used for encryption/decryption is a Triple-DES in CBC mode
with key sizes 112 bits (FIPS 46-3 and ICAO Doc 9303, normative appendix 5)
(FCS_COP.1/ENC) and the message authentication code computation accords to Retail
MAC algorithm and cryptographic key sizes 112 bit (ISO 9797 - MAC algorithm 3, block
cipher DES, Sequence Message Counter, padding mode 2) (FCS_COP.1/MAC).
This function detects each unsuccessful authentication attempt. The MRTD Manufacturer
and the Personalization Agent have only a limited number of authentication attempts after
which the related keys are blocked.
In case of regular termination of the protocol, both parties possess authentic keying
materials only known to them. The user may establish a secure messaging session
(FCS_CKM.1/CPS) and at the end of the session, the session keys are securely erased
(FCS_CKM.4).
The Basic Access System and the MRTD mutually authenticate by means of a Basic
Access Control mechanism based on a three pass challenge-response protocol
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 74 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
(FIA_UID.1, FIA_UAU.1, FIA_UAU.5). The challenge is the random number sent from one
party to the other. This random number will be enciphered with the secret symmetric key
by the receiver and then will be verified by the sender. This security service manages the
session keys exchanged between the terminal and the TOE and provides the means to
identify and authenticate the users in a secure way. The algorithm used for
encryption/decryption is a Triple-DES in CBC mode with key sizes 112 bits (FIPS 46-3 and
normative appendix 5 of the ICAO Doc 9303 [R14]) (FCS_COP.1/ENC), while the
message authentication code is computed according to Retail MAC algorithm and
cryptographic key sizes 112 bit (ISO 9797 - MAC algorithm 3, block cipher DES, Sequence
Message Counter, padding mode 2) (FCS_COP.1/MAC). These authentication keys are
derived by the SHA-1 algorithm (FIPS 180-2) like described in the ICAO Doc 9303,
normative appendix 5 [R14] [R15(FCS_COP.1/SHA).
After a successful BAC authentication, the Basic Access System is able to read less
sensitive data, such as the MRZ, the facial image and other data easily available from
other sources.
In the operational use phase, the TOE identification data can be obtained by an
authenticated BIS only. A BAC-like mechanism is used for this authentication
(FIA_UAU.5).
7.1.2 SS.SEC_MSG Data exchange with Secure Messaging
This security service meets the following SFRs:
FCS_CKM.1/BAC, FCS_CKM.1/CPS, FCS_COP.1/SHA, FCS_CKM.1/ENC, FCS_CKM.4,
FCS_COP.1/MAC, FCS_COP.1/AUTH, FIA_UAU.6, FIA_AFL.1.
This security service concerns the creation and the management of a secure
communication channel for the sensitive data exchange between the TOE and the
Inspection System. On this channel the data will be encrypted and authenticated with
session keys (data Triple-DES-encryption and MAC computation) such that the TOE is
able to verify the integrity and authenticity of received data. The algorithm used for
encryption/decryption is a Triple-DES in CBC mode with key sizes 112 bits (FIPS 46-3 and
ICAO Doc 9303, normative appendix 5), while the message authentication code is
according to Retail MAC algorithm and cryptographic key sizes 112 bit (ISO 9797 - MAC
algorithm 3, block cipher DES, Sequence Message Counter, padding mode 2). The
session keys are calculated during the authentication phase. The secure messaging
channel will be closed in case of a received message with:
• inconsistent or missing MAC,
• wrong sequence counter,
• plain access.
Session keys are overwritten after usage (FCS_CKM.4).
7.1.3 SS.ACC_CNTRL Access Control of stored Data Objects
This security service meets the following SFRs:
FAU_SAS.1, FDP_ACC.1, FDP_ACF.1, FDP_UCT.1, FDP_UIT.1, FMT_SMF.1,
FMT_SMR.1, FMT_LIM.1, FMT_LIM.2, FMT_MTD.1/INI_ENA, FMT_MTD.1/INI_DIS,
FMT_MTD.1/KEY_WRITE, FMT_MTD.1/ADDTSF_WRITE, FM, FMT_MTD.1/KEY_READ
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 75 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
As required in FDP_ACF.1, read and write access to stored data must be controlled in
different phases of the production and during operational use.
This security service ensures that the assets (user data and TSF data) can only be
accessed as defined by the access right written during the personalization process and
allows the access to the TOE identification data in the Personalization phase.
Furthermore, the access conditions allow to differentiate the roles based on the knowledge
of secret keys. Any access not explicitly allowed is denied.
The Document Basic Access Keys, the Document Number and the Security Environment
object will be written during the personalization phase by the Personalization Agent.
After keys have been written any type of direct access to any key is not allowed
(FMT_MTD.1/KEY_WRITE, FMT_MTD.1/ADDTSF_WRITE and
FMT_MTD.1/KEY_READ).
7.1.4 SS.LFC_MNG Life cycle management
This security service meets the following SFRs:
FMT_SMF.1, FMT_SMR.1
It ensures that the TOE life cycle status is set in an irreversible way to mark the following
phases in the given order: manufacturing, personalization and operational use. The only
role allowed to set the life cycle status is the Manufacturer.
The transition between the manufacturing phase and personalization phase is performed
disabling the MRTD Manufacturer Keys.
7.1.5 SS.SW_INT_CHECK Software integrity check of TOE’s assets
This security service meets the following SFRs:
FMT_LIM.1, FMT_LIM.2, FPT_TST.1
The TOE doesn’t allow to analyze, debug or modify TOE’s software during the operational
use. In phase 3 and 4 no commands are allowed to load executable code. Self tests will be
executed at initial start-up on ROM area (this functionality is implemented by the
underlying hardware).
This security service also checks the integrity of the following assets:
• application files,
• security data objects.
Integrity checks will be executed before any use of TSF data.
This SF warns the entity connected upon detection of an integrity error of the sensitive
data stored within the TOE Scope of Control and preserves a secure state when failure is
detected by TSF.
7.1.6 SS.SF_HW Security features provided by the hardware
This security service meets the following SFRs: FCS_RND.1, FMT_LIM.1, FMT_LIM.2,
FPT_EMSEC.1, FPT_TST.1, FPT_FLS.1, FPT_PHP.3.
The TOE benefits of a set of features provided by the integrated circuit to enforce security.
These security functions have already been evaluated and certified being the chips
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 76 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
already certified; a more detailed formulation of the security functions provided by the chip
can be found in the related security target [R25].
Table 7-2 shows a mapping between SFRs and the above security services.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 77 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 7-2 Mapping between SFRs and TOE security services
SS.AG_ID_AUTH
Agents
Identification
&
Authentication
SS.SEC_MSG
Data
exchange
with
Secure
Messaging
SS.ACC_CNTRL
Access
Control
of
Stored
Data
Object
SS.LFC_MNG
Life
Cycle
Management
SS.SW_INT_CHECK
SW
Integrity
check
of
TOE’s
Assets
SS.SF_HW
Security
features
provided
by
the
hardware
FAU_SAS.1 X
FCS_CKM.1/BAC X
FCS_CKM.1/CPS X
FCS_CKM.4 X X
FCS_COP.1/SHA X
FCS_CKM.1/ENC X
FCS_COP.1/AUTH X X
FCS_COP.1/MAC X
FCS_RND.1 X
FIA_UID.1 X
FIA_UAU.1 X
FIA_UAU.4 X
FIA_UAU.5 X
FIA_UAU.6 X
FIA_AFL.1 X X
FDP_ACC.1 X
FDP_ACF.1 X
FDP_UCT.1 X
FDP_UIT.1 X
FMT_SMF.1 X X
FMT_SMR.1 X X
FMT_LIM.1 X X X
FMT_LIM.2 X X X
FMT_MTD.1/INI_ENA X
FMT_MTD.1/INI_DIS X
FMT_MTD.1/KEY_WRITE X
FMT_MTD.1/ADDTSF_WRITE X
FMT_MTD.1/KEY_READ X
FPT_EMSEC.1 X
FPT_TST.1 X X
FPT_FLS.1 X
FPT_PHP.3 X
7.2 Assurance Measures
Assurance measures applied to the TOE are fully compliant to those described in part 3 of
the Common Criteria v3.1 [R10].
The implementation is based on a description of the security architecture of the TOE and
on an informal high-level and low-level design of the components of the TOE. The
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 78 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
description is sufficient to generate the TOE without other design requirements. These
documents, together with the source code of the software, address the ADV_ARC,
ADV_FSP, ADV_TDS and ADV_IMP assurance families.
The configuration management plan addresses the ALC_CMC and ALC_CMS assurance
families, and enforces good practices to securely manage configuration items including,
but not limiting to, design documentation, user documentation, source code, test
documentation and test data.
The configuration management process guarantees the separation of the development
configuration libraries from the configuration library containing the releases and also
supports the generation of the TOE.
All the configuration items are managed with the help of automated tools. In particular
configuration items regarding security flaws are managed with the support of an issue
tracking system, while all the other configuration items are managed with the help of a
version control system.
The software test process, addressing the class ATE, is machine-assisted to guarantee a
repeatable error-free execution of the same test chains in both the system test pahase and
in the validation phase.
A secure delivery of the TOE is guaranteed by the application of dedicated procedures.
The prevention measures, the checks and all the actions to be performed at the
developer’s site are described in the secure delivery procedure addressing the ALC_DEL
assurance family, while the security measures related to delivery to be applied at the
user’s site are defined in the pre-personalization guidance. The latter document also
addresses the assurance family AGD_PRE.
The necessary information for the passport personalization is provided by a dedicated
guidance and the information for its usage after delivery to the legitimate holder is provided
by the guidance for the operational user. These documents address the AGD_OPE
assurance family.
To protect the confidentiality and integrity of the TOE design and implementation, the
development and production environment and tools conform to the security policies
defined in the documentation dedicated to the development security, which addresses the
assurance family ALC_DVS.
The life-cycle model adopted in the manufacturing phases and the tools supporting the
development and production of the TOE are described in dedicated documents
addressing the assurance families ALC_LCD and ALC_TAT.
An independent vulnerability analysis, meeting requirements of the assurance family
AVA_VAN, is conducted by a third party.
Due to the composite nature of the evaluation, which is based on the CC evaluation of the
hardware, the assurance measures related to the platform (IC) will be covered in
documents from the IC Manufacturer. Security procedures described in such documents
have been taken into consideration.
Table 7-3 shows the documentation that provides the necessary information related to the
assurance requirements defined in this security target.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 79 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Table 7-3 Assurance Requirements documentation
Security Assurance Requirements Documents
ADV_ARC.1 Description of the Security Architecture of the
SOMA801NXP embedded software
ADV_FSP.4 Functional Specification for the SOMA801NXP embedded
software
ADV_IMP.1 Source code of the SOMA801NXP embedded software
ADV_TDS.3 Description of the Design of the SOMA801NXP embedded
software
ADV_COMP.1 Rationale for Embedded Software Design Compliance
concerning the composite evaluation of the SOMA801NXP
electronic passport.
AGD_OPE.1 Personalization Guidance for the SOMA801NXP electronic
passport
User Guidance for the SOMA801NXP electronic passport
AGD_PRE.1 Pre-personalization guidance for the SOMA801NXP
electronic passport.
ALC_CMC.4, ALC_CMS.4 Configuration Management Plan,
configuration list
evidences of configuration management
ALC_DEL.1 Secure Delivery procedure
Delivery documentation
ALC_DVS.2 Development security description
Development security documentation
ALC_LCD.1 Life-cycle definition
ALC_TAT.1 Description of tools and techniques
ATE_COV.2 Test coverage analysis for the SOMA801NXP Electronic
Passport
ATE_DPT.1 Test depth analysis for the SOMA801NXP Electronic
Passport
ATE_FUN.1 Functional Test Specification for the SOMA801NXP
Electronic Passport
Evidences of tests
ATE_IND.2 Documentation related to an independent test.
AVA_VAN.3 Documentation related to an independent vulnerability
analysis.
Assurance measures described in this section cover the assurance requirements in
section 6.3.3.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 80 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
8. References
8.1 Acronyms
BAC Basic Access Control
BIS Basic Inspection System
CDS DS Public Key Certificate
CBC Cipher-block Chaining (block cipher mode of operation)
CC Common Criteria
COM Common data group of the LDS (ICAO Doc 9303)
CPS Common Personalization Standard
CPU Central Processing Unit
CSCA Country Signing Certification Authority
CVCA Country Verifying Certification Authority
DF Dedicated File (ISO 7816)
DG Data Group (ICAO Doc 9303)
DPA Differential Power Analysis
DS Document Signer
DV Document Verifier
EAC Extended Access Control
ECB Electronic Codebook (block cipher mode of operation)
EEPROM Electrically Erasable Read Only Memory
EF Elementary File (ISO 7816)
EIS Extended Inspection System
ESW Embedded Software
GIS General Inspection System
IC Integrated Circuit
IS Inspection System
LDS Logical Data Security
LCS Life Cycle Status
MAC Message Authentication Code
MF Master File (ISO 7816)
MMU Memory Management Unit
MRTD Machine Readable Travel Document
MRZ Machine Readable Zone
N/A Not Applicable
n.a. Not Applicable
OCR Optical Character Recognition
OS Operating System
OSP Organization Security Policy
PP Protection Profile
RAM Random Access Memory
RNG Random Number Generator
ROM Read Only Memory
SAR Security Assurance Requirement
SFP Security Function Policy
SFR Security Functional Requirement
SOD Document Security Object
SOF Strength of Function
SPA Simple Power Analysis
ST Security Target
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 81 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Triple-DES Triple DES
TOE Target of Evaluation
TSC TOE Scope of Control
TSF TOE Security Functions
TR Technical Report
VIZ Visual Inspection Zone
8.2 Glossary
Active Authentication Security mechanism defined in ICAO Doc 9303 [R14]
option by which means the MTRD’s chip proves and the
inspection system verifies the identity and authenticity of
the MTRD’s chip as part of a genuine MRTD issued by a
known state or organization.
application note Additional information that is considered relevant or
useful for the construction, evaluation, or use of the TOE.
audit records Write-only-once non-volatile memory area of the MRTDs
chip to store the Initialization Data and Pre-
personalization Data.
authenticity Ability to confirm the MRTD and its data elements on the
MRTD’s chip were created by the Issuing State or
Organization.
Basic Access Control Security mechanism defined by ICAO [R14] by which
means the MTRD’s chip proves and the inspection
system protect their communication by means of secure
messaging with the Document BAC Keys.
Basic Inspection System An inspection system which implements the terminals
part of the BAC Mechanism and authenticates
themselves to the MRTD’s chip using the Document BAC
Keys derived from the printed MRZ data for reading the
logical MRTD.
biographical data The personalized details of the bearer of the document
appearing as text in the Visual Inspection Zone (VIZ) and
Machine Readble Zone (MRZ) on the biographical data
page of a passport book or on a travel card or visa [R14].
biometric reference data Data stored for biometric authentication of the MRTD
holder in the MRTD’s chip as (i) digital portrait and (ii)
optional biometric reference data.
Certificate chain Hierarchical sequence of Inspection System Certificate
(lowest level), Document Verifier Certificate and Country
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 82 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Verifying Certification Authority Certificates (highest
level), where the certificate of a lower level is signed with
the private key corresponding to the public key in the
certificate of the next higher level . The Country Verifying
Certification Authority Certificate is signed with the
private key corresponding to the public key it contains
(self-signed certificate).
Chip Authentication Authentication protocol used to verify the genuinity of the
MRTD chip.
counterfeit An unauthorized copy or reproduction of a genuine
security document made by whatever means [R14].
Country Signing Certification
Authority (CSCA)
Certification Authority of the Issuing State or Organization
which attests the validity of certificates and digital
signatures issued by the Document Signer.
Country Signing Certification
Authority Certificate (CCSCA)
Certificate of the Country Signing Certification Authority
Public Key (PKCSCA) issued by Country Signing
Certification Authority stored in the inspection system.
Country Verifying Certification
Authority (CVCA)
The country specific root of the PKI of Inspection
Systems and creates the Document Verifier Certificates
within this PKI. It enforces the Privacy policy of the
issuing Country or Organization in respect to the
protection of sensitive biometric reference data stored in
the MRTD.
Current Date The maximum of the effective dates of valid CVCA, DV
and domestic Inspection System certificates known to the
TOE. It is used the validate card verifiable certificates.
CVCA link Certificate Certificate of the new public key of the Country Verifying
Certification Authority signed with the old public key of
the Country Verifying Certification Authority where the
certificate effective date for the new keys is before the
certificate expiration date of the certificate for the old key.
Document Basic Access Keys Pair of symmetric Triple-DES keys used for secure
messaging with encryption and message authentication
of data transmitted between the MRTD’s chip and the
inspection system [R14]. It is derived from the printed
MRZ of the passport book to authenticate an entity able
to read the printed MRZ of the passport book.
Document Security Object A RFC3369 CMS Signed Data Structure, signed by the
Document Signer. It carries the hash values of the LDS
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 83 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
DG’s and is stored in the MRTD’s chip. It may carry the
Document Signer Certificate (CDS) [R14].
Document Signer Entity delegated by the Issuing State or Organization to
digitally sign the DG’s present in the LDS.
eavesdropper A threat agent with low attack potential reading the
communication between the MRTD’s chip and the
inspection system to gain the data on the MRTD’s chip.
enrolment The process of collecting biometric samples from a
person and the subsequent preparation and storage of
biometric reference templates representing that person's
identity [R14].
Extended Access Control Security mechanism identified in BSI TR-03110 [R7] by
which means the MTRD’s chip (i) verifies the
authentication of the inspection systems authorized to
read the optional biometric reference data, (ii) controls
the access to the optional biometric reference data and
(iii) protects the confidentiality and integrity of the optional
biometric reference data during their transmission to the
inspection system by secure messaging. The
Personalization Agent may use the same mechanism to
authenticate themselves with Personalization Agent
Authentication Private Keys and to get write and read
access to the logical MRTD and TSF data.
Extended Inspection System A role of a terminal as part of an inspection system which
is in addition to the BIS authorized by the Issuing State or
Organization to read the optional biometric reference
data and supports the terminals part of the Extended
Access Control Authentication Mechanism.
Forgery Fraudulent alteration of any part of the genuine
document, e.g. changes to the biographical data or the
portrait [R14].
General Inspection System A Basic Inspection System which implements sensitively
the Chip Authentication Mechanism.
Global interoperability The capability of inspection systems (either manual or
automated) in different States throughout the world to
exchange data, to process data received from systems in
other States, and to utilize that data in inspection
operations in their respective States. Global
interoperability is a major objective of the standardized
specifications for placement of both eye-readable and
machine readable data in all MRTDs.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 84 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
impostor A person who applies for and obtains a document by
assuming a false name and identity, or a person who
alters his or her physical appearance to represent himself
or herself as another person for the purpose of using that
person’s document [R14].
Initialization Data Any data defined by the TOE Manufacturer and injected
into the non-volatile memory by the Integrated Circuits
manufacturer (Phase 2). These data are, for instance,
used for traceability and for IC identification as MRTD’s
material (IC identification data).
inspection The act of a State examining an MRTD presented to it by
a traveler (the MRTD holder) and verifying its
authenticity.
Inspection System A technical system used by the border control officer of
the receiving State (i) examining an MRTD presented by
the traveler and verifying its authenticity and (ii) verifying
the traveler as MRTD holder.
Integrated Circuit Electronic component(s) designed to perform processing
and/or memory functions. The MRTD’s chip is an
integrated circuit.
integrity Ability to confirm the MRTD and its data elements on the
MRTD’s chip have not been altered from that created by
the Issuing State or Organization
Issuing Organization Organization authorized to issue an official travel
document (e.g. the United Nations Organization, issuer of
the passport) [R14].
Issuing State The Country issuing the MRTD [R14]
Logical Data Structure The collection of groupings of DG’s stored in the optional
capacity expansion technology [R14]. The capacity
expansion technology used is the MRTD’s chip.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 85 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Logical MRTD Data of the MRTD holder stored according to the LDS
[R14] as specified by ICAO on the contactless IC. It
presents contactless readable data including (but not
limited to):
i. personal data of the MRTD holder
ii. the digital Machine Readable Zone Data (digital
MRZ data, EF.DG1),
iii. the digitized portraits (EF.DG2),
iv. the biometric reference data of finger(s)
(EF.DG3) or iris image(s) (EF.DG4) or both and
v. the other data according to LDS (EF.DG5 to
EF.DG16).
Machine Readable Travel
Document
Official document issued by a State or Organization
which is used by the holder for international travel (e.g.
passport, visa, official document of identity) and which
contains mandatory visual (eye readable) data and a
separate mandatory data summary, intended for global
use, reflecting essential data elements capable of being
machine read [R14].
Machine Readable Zone Fixed dimensional area located on the front of the MRTD
Data Page or, in the case of the TD1, the back of the
MRTD, containing mandatory and optional data for
machine reading using OCR methods [R14].
machine-verifiable biometrics
feature
A unique physical personal identification feature (e.g. an
iris pattern, fingerprint or facial characteristics) stored on
a travel document in a form that can be read and verified
by machine.
MRTD application Non-executable data defining the functionality of the
operating system on the IC as the MRTD’s chip. It
includes:
i. the file structure implementing the LDS [R14],
ii. 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.DG 16) and
iii. the TSF Data including the definition the
authentication data but except the authentication
data itself.
MRTD Basic Access Control Mutual authentication protocol followed by secure
messaging between the inspection system and the
MRTD’s chip based on MRZ information as a 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
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 86 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
State or Organization personalized the MRTD.
MRTD’s chip A contactless integrated circuit chip complying with
ISO/IEC 14443 and programmed according to the LDS
[R14].
MRTD’s chip Embedded
Software
Software embedded in a MRTD’s chip and not being
developed by the IC Designer. The MRTD’s chip
Embedded Software is designed in phase 1 and
embedded into the MRTD’s chip in Phase 2 of the TOE
life-cycle.
Optional biometric reference
data
Data stored for biometric authentication of the MRTD
holder in the MRTD’s chip as (i) encoded finger image(s)
(EF.DG3) or (ii) encoded iris image(s) (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 Authentication Passive Authentication is a mechanism that ensures the
authenticity of the DG’s present in the LDS by:
i. the verification of the digital signature of the SOD
and
ii. comparing the hash values of the read LDS data
fields with the hash values contained in the SOD.
Personalization The process by which the portrait, signature and
biographical data are applied to the document [R14].
Personalization Agent The agent delegated by the Issuing State or Organization
to personalize the MRTD for the holder by
i. establishing the identity the holder for the
biographic data in the MRTD,
ii. enrolling the biometric reference data of the MRTD
holder i.e. the portrait, the encoded finger image(s)
or the encoded iris image(s) and
iii. writing these data on the physical and logical
MRTD for the holder.
Personalization Agent
Authentication Information
TSF data used for authentication proof and verification of
the Personalization Agent.
Physical travel document Travel document in the form of paper, plastic and chip
using secure printing to present data including (but not
limited to):
i. biographical data,
ii. data of the MRZ,
iii. photographic image and
iv. other data.
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 87 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Pre-personalization Data Any data that is injected into the non-volatile memory of
the TOE by the MRTD Manufacturer (Phase 2) for
traceability of non-personalized MRTD’s and/or to secure
shipment within or between life cycle phases 2 and 3. It
contains (but is not limited to) the Active Authentication
Key Pair and the Personalization Agent Key pair.
Pre-personalized MRTD’s chip MRTD’s chip equipped with a unique identifier, the
Personalization Agent Keys, and a unique asymmetric
Active Authentication Key Pair of the chip.
Primary Inspection System An 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 [R14].
reference data Data enrolled for a known identity and used by the
verifier to check the verification data provided by an entity
to prove this identity in an authentication attempt.
secure messaging Secure messaging using encryption and message
authentication code according to ISO/IEC 7816-4 [R17].
skimming Imitation of the inspection system to read the logical
MRTD or parts of it via the contactless communication
channel of the TOE without knowledge of the printed
MRZ data.
travel document A passport or other official document of identity issued by
a State or organization, which may be used by the rightful
holder for international travel.
traveler A person presenting the MRTD to the inspection system
and claiming the identity of the MRTD holder.
TSF data Data created by and for the TOE, that might affect the
operation of the TOE [R8].
Unpersonalized MRTD MRTD material prepared to produce an personalized
MRTD containing an initialized and pre-personalized
MRTD’s chip.
User data Data created by and for the user, that does not affect the
operation of the TSF [R8].
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 88 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
Verification The process of comparing a submitted biometric sample
against the biometric reference template of a single
enrollee whose identity is being claimed, to determine
whether it matches the enrollee’s template [R14].
Verification data Data provided by an entity in an authentication attempt to
prove their identity to the verifier. The verifier checks
whether the verification data match the reference data
known for the claimed identity.
8.3 Technical References
[R1] BSI: Certification Report BSI-DSZ-CC-0555-2009 for NXP Smart Card Controller
P5CD081V1A and its major configurations P5CC081V1A, P5CN08V1A,
P5CD041V1A, P5CD021V1A and P5CD016V1A each with specific IC Dedicated
Software
[R2] BSI: Assurance Maintenance Report BSI-DSZ-CC-0555-MA-01 NXP Smart Card
Controller P5CD081V1A and its major configurations P5CC081V1A, P5CN081V1A,
P5CD041V1A, P5CD021V1A and P5CD016V1A each with IC dedicated Software
[R3] BSI: Functionality classes and evaluation methodology for physical random number
generators, AIS31, Version 1, 25.9.2001
[R4] BSI: Security IC Platform Protection Profile version 1.0 15 June, 2007; registered
and certified by Bundesamt für Sicherheit in der Informationstechnik (BSI) under the
reference BSI-PP-0035
[R5] BSI: Common Criteria Protection Profile Machine Readable Travel Document with
„ICAO Application ", Basic Access Control, Version 1.10, 25th
March 2009, BSI-CC-
PP-0055.
[R6] BSI: Common Criteria Protection Profile Machine Readable Travel Document with
„ICAO Application ", Extended Access Control, Version 1.10, 25th
March 2009, BSI-
CC-PP-0056.
[R7] BSI: Technical Guideline TR-03110 - Advanced Security Mechanisms for Machine
Readable Travel Documents – Extended Access Control (EAC), Version 1.11
[R8] CCRA: Common Criteria for Information Technology Security Evaluation, Part 1:
Introduction and general model, July 2009, version 3.1 rev.3, CCMB-2009-07-001
[R9] CCRA: Common Criteria for Information Technology Security Evaluation, Part 2:
Security Functional Components, July 2009, version 3.1 rev.3, CCMB-2009-07-002
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 89 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
[R10] CCRA: Common Criteria for Information Technology Security Evaluation, Part 3:
Security Assurance Components, July 2009, version 3.1 rev 3, CCMB-2009-07-003
[R11] CCRA: Common Criteria for Information Technology Security Evaluation,
Composite evaluation for Smart Cards and similar devices, September 2007,
version 1.0 rev. 1, CCDB-2007-09-001
[R12] EMV CPS: EMV Card Personalization Specification – version 1.0, June 2003
[R13] Gep: Security Target Lite SOMA801NXP Electronic Passport, Extended Access
Control” v1.0 2012-05-16, ref TCLE120007.
[R14] ICAO: MACHINE READABLE TRAVEL DOCUMENTS – Part 3 Machine Readable Official
Travel Documents, Volume 2 Specifications for Electronically Enabled Official
Travel Documents with Biometric Identification Capability Approved by the
Secretary General and published under his authority – Doc 9303, Third Edition –
2008
[R15] ICAO: SUPPLEMENT TO DOC 9303 – Release 8 – March 19, 2010
[R16] IETF Network Working Group: Request For Comments 2119, Key words for use
in RFCs to Indicate Requirement Levels, March 1997.
[R17] ISO/IEC: International Standard 7816-4 2005 Information Technology – Integrated
circuit(s) cards with contacts – Part 4: Interindustry commands for interchange –
January 15, 2005
[R18] ISO/IEC: International Standard 9797-1 1999 nformation Technology – Security
Techniques – Message Authentication Codes – Part 1: Mechanisms using a block
cipher, 1999
[R19] ISO/IEC: International Standard 14443-1 - Identification cards – Contactless
Integrated circuit cards – Proximity cards. Part 1: Physical characteristics.
[R20] ISO/IEC: International Standard 14443-2 - Identification cards – Contactless
Integrated circuit cards – Proximity cards. Part 2: Radio frequency interface power
and signal interface.
[R21] ISO/IEC: International Standard 14443-3 - Identification cards – Contactless
Integrated circuit cards – Proximity cards. Part 3: Initialization and anticollision.
[R22] ISO/IEC: International Standard 14443-4 - Identification cards – Contactless
Integrated circuit cards – Proximity cards. Part 4: Transmission protocol.
[R23] NIST: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION FIPS PUB 46-3,
DATA ENCRYPTION STANDARD (DES), Reaffirmed 1999 October 25, U.S.
DEPARTMENT OF COMMERCE/National Institute of Standards and Technology
SOMA801NXP Security Target Lite - Basic Access Control ASE
Version: 1.0 Date: 2012-05-16 Reference: TCLE120006 page 90 of 90
This document may not be modified or partially reused without prior written consent of Gep S.p.A.
[R24] NIST: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION FIPS PUB 180-2,
SECURE HASH STANDARD, U.S. DEPARTMENT OF COMMERCE/National
Institute of Standards and Technology – 2002 August 1
[R25] NXP Semiconductors: NXP Secure Smart Card Controllers
P5CD016/021/041/051V1A and P5Cx081V1A Security Target Lite rev. 1.4, 25
October 2010, BSI-DSZ-CC-0555
[R26] RSA Laboratories: PKCS #3 - Diffie-Hellman Key-Agreement Standard, An RSA
Laboratories Technical Note, version 1.4 November 1993.
[R27] RSA Laboratories: PKCS#1 – RSA cryptography standard, An RSA Laboratories
Technical Note, version 2.1 June 2002.
END OF DOCUMENT