SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Reference: 2017_2000030456
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 2/130
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 3/130
TABLE OF CONTENTS
1 TOE REFERENCE ................................................................................................... 8
1.1 SECURITY TARGET IDENTIFICATION ...................................................................................... 8
1.2 TOE IDENTIFICATION........................................................................................................ 8
1.3 TOE DOCUMENTATION ...................................................................................................... 8
1.4 REFERENCES ................................................................................................................... 9
1.5 ACRONYMS ....................................................................................................................10
2 TOE OVERVIEW................................................................................................... 12
2.1 TOE TYPE .....................................................................................................................12
2.2 USAGE AND MAJOR SECURITY FEATURES OF THE TOE................................................................12
2.3 REQUIRED NON-TOE HARDWARE/SOFTWARE/FIRMWARE ...........................................................13
2.3.1 Off-Card Bytecode Verifier .....................................................................................13
2.3.2 Contact Based Communication...............................................................................13
2.3.3 Contactless Communication ...................................................................................13
2.3.4 Software Components out of TOE Scope ................................................................14
2.4 ACTORS OF THE TOE .......................................................................................................14
3 TOE DESCRIPTION ............................................................................................. 15
3.1 PHYSICAL SCOPE OF THE TOE ............................................................................................15
3.2 LOGICAL SCOPE OF THE TOE..............................................................................................16
3.2.1 IC, Crypto Library..................................................................................................16
3.2.2 Common Operating System ...................................................................................17
3.2.3 Java Card System .................................................................................................17
3.2.4 Card Management (CM).........................................................................................17
3.2.5 Cryptographic algorithms and functionality .............................................................18
3.2.6 PACE API..............................................................................................................18
3.2.7 DH API.................................................................................................................18
3.3 LIFE CYCLE ....................................................................................................................18
3.3.1 Life Cycle 1...........................................................................................................19
3.3.2 Life Cycle 2...........................................................................................................21
3.3.3 Life Cycle 3...........................................................................................................23
3.3.4 Actors & Coverage ................................................................................................25
3.3.5 Description of the TOE environment.......................................................................26
4 COMMON CRITERIA CONFORMANCE CLAIM...................................................... 27
4.1 COMMON CRITERIA CONFORMANCE......................................................................................27
4.2 CONFORMANCE WITH AN ASSURANCE PACKAGE ........................................................................27
4.2.1 AVA_VAN.5 and Industrial Key Length Requirements ..............................................27
4.3 CONFORMANCE WITH A PROTECTION PROFILE.........................................................................28
4.4 CONFORMANCE RATIONALE ................................................................................................28
4.4.1 TOE type consistency ............................................................................................28
4.4.2 SPD statement consistency....................................................................................28
4.4.3 Security Objectives Consistency .............................................................................29
4.4.4 Consistency of the Security Objectives for the environment .....................................29
4.4.5 Security Requirements Consistency ........................................................................29
5 SECURITY ASPECTS............................................................................................ 31
5.1 CONFIDENTIALITY ......................................................................................................31
5.2 INTEGRITY..................................................................................................................31
5.3 UNAUTHORIZED EXECUTIONS .....................................................................................31
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 4/130
5.4 BYTECODE VERIFICATION ...........................................................................................32
5.5 CARD MANAGEMENT....................................................................................................32
5.6 SERVICES ...................................................................................................................33
6 SECURITY PROBLEM DEFINITION ..................................................................... 35
6.1 ASSETS.........................................................................................................................35
6.1.1 Java Card System Protection Profile - Open Configuration........................................35
6.1.2 Card Management.................................................................................................36
6.2 THREATS.......................................................................................................................37
6.2.1 Java Card System Protection Profile - Open Configuration........................................37
6.2.2 Card Management.................................................................................................40
6.3 ORGANISATIONAL SECURITY POLICIES ..................................................................................41
6.3.1 Java Card System Protection Profile - Open Configuration........................................41
6.3.2 TOE .....................................................................................................................42
6.4 ASSUMPTIONS ................................................................................................................42
6.4.1 Java Card System Protection Profile - Open Configuration........................................42
6.4.2 TOE .....................................................................................................................42
7 SECURITY OBJECTIVES ...................................................................................... 43
7.1 SECURITY OBJECTIVES FOR THE TOE ...................................................................................43
7.1.1 Java Card System Protection Profile - Open Configuration........................................43
7.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................47
7.2.1 Java Card System Protection Profile - Open Configuration........................................47
7.2.2 TOE .....................................................................................................................47
7.3 SECURITY OBJECTIVES RATIONALE.......................................................................................49
7.3.1 Threats ................................................................................................................49
7.3.2 Organisational Security Policies ..............................................................................55
7.3.3 Assumptions .........................................................................................................56
7.3.4 SPD and Security Objectives ..................................................................................56
8 SECURITY REQUIREMENTS ................................................................................ 61
8.1 SECURITY FUNCTIONAL REQUIREMENTS ................................................................................61
8.1.1 TOE .....................................................................................................................61
8.1.2 Java Card System Protection Profile - Open Configuration........................................61
8.1.3 Operating System .................................................................................................86
8.1.4 Card Life Cycle Management SFRs .........................................................................87
8.1.5 SFRs for PACE API ................................................................................................89
8.2 SECURITY ASSURANCE REQUIREMENTS..................................................................................90
8.3 SECURITY REQUIREMENTS RATIONALE ..................................................................................91
8.3.1 Objectives ............................................................................................................91
8.3.2 Rationale tables of Security Objectives and SFRs.....................................................95
8.3.3 Dependencies .....................................................................................................100
8.3.4 Rationale for the Security Assurance Requirements ...............................................107
8.3.5 AVA_VAN.5 Advanced methodical vulnerability analysis .........................................108
8.3.6 ALC_DVS.2 Sufficiency of security measures .........................................................108
9 TOE SUMMARY SPECIFICATION....................................................................... 109
9.1 TOE SUMMARY SPECIFICATION.........................................................................................109
9.1.1 Functionalities.....................................................................................................109
9.2 SFRS AND TSS.............................................................................................................112
9.2.1 SFRs and TSS - Rationale ....................................................................................112
9.2.2 Association tables of SFRs and TSS ......................................................................121
10 STATEMENT OF COMPATIBILITY................................................................ 126
10.1 SEPARATION OF THE PLATFORM-TSF ............................................................................126
10.2 STATEMENT OF COMPATIBILITY FOR THE SECURITY ASSURANCE REQUIREMENTS .............................128
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 5/130
10.3 STATEMENT OF COMPATIBILITY FOR THE SECURITY ENVIRONMENT AND THE OBJECTIVES...................128
10.3.1 Objectives ..........................................................................................................128
10.3.2 Threats ..............................................................................................................129
10.3.3 Organizational security policies ............................................................................129
10.3.4 Assumptions .......................................................................................................130
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 6/130
Table of figures
Figure 1 – View of the smartcard and pins .....................................................................................15
Figure 2 Product architecture ..................................................................................................16
Figure 3 Flashing and generic BlackBox loading at founder site on wafer; pre-personalization on card
............................................................................................................................................20
Figure 4 Flashing and generic BlackBox loading at founder site on wafer; pre-personalization on
module .................................................................................................................................22
Figure 5 Flashing and dedicated BlackBox loading at founder site on wafer; pre-personalization on IC
............................................................................................................................................24
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 7/130
Table of tables
Table 1 Actors of the smart card product .......................................................................................26
Table 2 Threats and Security Objectives - Coverage ......................................................................57
Table 3 Security Objectives and Threats - Coverage ......................................................................59
Table 4 OSPs and Security Objectives - Coverage..........................................................................59
Table 5 Security Objectives and OSPs - Coverage..........................................................................60
Table 6 Assumptions and Security Objectives for the Operational Environment - Coverage ..............60
Table 7 Security Objectives for the Operational Environment and Assumptions - Coverage ..............60
Table 8 Security Objectives and SFRs - Coverage ..........................................................................97
Table 9 SFRs and Security Objectives .........................................................................................100
Table 10 SFRs Dependencies .....................................................................................................106
Table 11 SARs Dependencies .....................................................................................................107
Table 12 SFRs and TSS - Coverage.............................................................................................124
Table 13 TSS and SFRs - Coverage.............................................................................................125
Table 14 Coverage of IC platform SFRs........................................................................................128
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 8/130
1 TOE reference
The Target of Evaluation (TOE) is the open smartcard platform developed by IDEMIA, identified as
“IDeal Citiz v2.1.2 open platform”. The TOE offers GlobalPlatform compliant card management
capabilities in conjunction with an open Java Card platform. This operating system (IDeal Citiz v2.1.2
open platform) is embedded in a smartcard on top of the Infineon M7892 B11 (SLE78CLFX4000P,
SLE78CLFX4000PM, SLE78CFX4000P) chip with optional RSA2048/4096 v1.02.013, EC v1.02.013,
SHA-2 v1.01 and Toolbox v1.02.013 libraries and with specific IC dedicated software (firmware)
produced by Infineon Technologies AG.
1.1 Security Target Identification
The Security Target identification is described in the table below:
ST Identification
Title: SECURITY TARGET LITE OF IDEAL CITIZ V2.16I ON INFINEON
M7892 B11 -JAVA CARD OPEN PLATFORM-
Version: 1.2
Reference: 2017_2000030456
Date of production 06/10/2017
Origin: IDEMIA
Assurance Level: EAL5 augmented with ALC_DVS.2 and AVA_VAN.5
CC Version: 3.1 Release 5
Compliant Protection Profile [PP_JC]
1.2 TOE Identification
The TOE reference is described in the table below:
TOE Identification
Product name : IDeal Citiz v2.1.2 open platform
Commercial name IDeal Citiz v2.16i on Infineon M7892 B11
TOE Reference OFFICIEL_IDealCitiz_SLE78CLFX4000PM_2_1_2_0_03
Version number: 2.1.2
Date of issue 01/09/2017
TOE Identification Method See [AGD_PRE]
Origin: IDEMIA
Chip Identifier: Infineon M7892 B11 (SLE78CLFX4000P, SLE78CLFX4000PM,
SLE78CFX4000P) with optional RSA2048/4096 v1.02.013, EC
v1.02.013, SHA-2 v1.01 and Toolbox v1.02.013 libraries and with
specific IC dedicated software (firmware) [ST_IC]
Chip Ref. Certificate M7892 B11 : BSI-DSZ-CC-0782-V3-2017 [CR_IC]
1.3 TOE documentation
The TOE guidance documentation is listed in the table below:
TOE documentation
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 9/130
TOE documentation
[AGD_PRE]
2017_2000026239 - IDealCitiz_v2.1.2 - PRE- Preparative
Procedures
[AGD_OPE]
2017_2000026333 - IDealCitiz_v2.1.2 - OPE - Operational User
Guidance
[API]
2017_2000026306 - IDealCitiz_v2.1.2 - Global Platform and
JavaCard API
[VAR] 2017_2000026376 - IDealCitiz_v2.1.2 – Verification Authority Rules
[BADR]
2017_2000026343 - IDealCitiz_v2.1.2 – Basic Applet Development
Recommendations
[SADR]
2017_2000026334 - IDealCitiz_v2.1.2 – Secure Applet
Development Recommendations
1.4 References
Ref. Document title
[CC_Part1]
Common Criteria for information Technology Security Evaluation, Part 1:
Introduction and general model,
CCMB-2017-04-001,
Version 3.1 – Revision 5, April 2017
[CC_Part2]
Common Criteria for information Technology Security Evaluation, Part 2:
Security Functional Requirements,
CCMB-2017-04-002,
Version 3.1 – Revision 5, April 2017
[CC_Part3]
Common Criteria for information Technology Security Evaluation, Part 2:
Security Assurance Requirements,
CCMB-2017-04-003,
Version 3.1 – Revision 5, April 2017
[CCDB_COMP]
Composite product evaluation for Smart Cards and similar devices,
CCDB-2012-04-001,
Version 1.2, April 2012
[FIPS_46-3]
DATA ENCRYPTION STANDARD (DES), FIPS Publication 46-3, National
Institute of Standards and Technology, 1999
[FIPS_180-4]
Secure Hash Standard (SHS), FIPS Publication 180-4, National Institute of
Standards and Technology, 2015
[FIPS_186-4]
Digital Signature Standard (DSS), FIPS Publication 186-4, National Institute
of Standards and Technology, 2013
[FIPS_197]
ADVANCED ENCRYPTION STANDARD (AES), FIPS Publication 197, National
Institute of Standards and Technology, 2001
[FIPS_198-1]
The Keyed-Hash Message Authentication Code (HMAC), FIPS Publication
198-1, National Institute of Standards and Technology, 2008
[GP_CS]
GlobalPlatform, Card Specification,
Version 2.1.1, March 2003
[ICAO-9303:Part 11]
International Civil Aviation Organization, ICAO Doc 9303, Machine
Readable Travel Documents, Part 11: Security Mechanisms for MRTDs –
7th edition, 2015
[IEEE1363]
Standard Specifications for Public-Key Cryptography, IEEE 1363, Institute
of Electrical and Electronic Engineers, 2000
[ISO/IEC9796]
ISO/IEC 9796-02:2002, Information technology – Security techniques –
Digital Signature Schemes giving message recovery – Part 2: Integer
factorization based mechanisms, 2002
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 10/130
Ref. Document title
[JCAPI]
Java Card Platform, Application Programming Interface, Classic Edition,
Version 3.0.1 May 2009, including Specification Errata, October 2010,
Updated February 2011
[JCVM]
Java Card Platform, Virtual Machine Specification, Classic Edition, Version
3.0.1 May 2009, including Specification Errata, October 2010, Updated
February 2011
[JCRE]
Java Card Platform, Runtime Environment Specification, Classic Edition,
Version 3.0.1 May 2009, including Specification Errata, October 2010,
Updated February 2011
[NIST_SP800-38B]
Recommendation for Block Cipher Modes of operation: The CMAC Mode for
Authentication, NIST Special Publication 800-38B, 2016
[NIST_SP800-56A]
Recommendation for Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography, NIST Special Publication 800-56A, Rev 2, 2013
[NIST_SP800-90A]
Recommendation for Random Number Generation Using Deterministic
Random Bit Generators, NIST Special Publication 800-90A, Rev 1, 2015
[PKCS#3]
Diffie-Hellman Key-Agreement Standard. An RSA Laboratories Technical
note Version 1.4. Revised November 1, 1993, supersedes June 3, 1991,
which was also published as NIST/OSI implementors’ workshop document
SEC-SIG-91-19
[PP_IC]
Security IC Platform Protection Profile with Augmentation Packages Version
1.0, Registered and Certified by Bundesamt für Sicherheit in der
Informationstechnik (BSI) under the reference BSI-CC-PP-0084-2014.
[PP_JC]
Java Card Protection Profile – Open Configuration, Version 3.0, May, 2012.
Certified by ANSSI under the reference ANSSI-CC-PP-2010/03-M01
[ST_IC]
Infineon, Security Target Lite, M7892 B11, Recertification, Including
optional Software Libraries RSA - EC - SHA- 2 - Toolbox, Common Criteria
CC v3.1 EAL6 augmented (EAL6+), version 2.6, 2017-08-02
[CR_IC]
BSI Certification Report BSI-DSZ-CC-0782-V3-2017 for Infineon Security
Controller M7892 B11, September 2017
[SP800-67]
Recommendation for the Triple Data Encryption Algorithm (TDEA) Block
Cipher, NIST Special Publication 800-67, 2012
[TR03111]
Technical Guideline TR-03111, Elliptic Curve Cryptography, v2.0,
Bundesamt für Sicherheit in der Informationstechnik, 2012
[X9.42]
X.9.42-2003 Public Key Cryptography for the financial Services Industry :
Agreement pf Symmetric Keys Using Discrete Logarithm Cryptography-
Accredited Standards Committee X9, Incorporated Financial Industry
Standards- Date approved : November 19, 2003
1.5 Acronyms
Acronym Definition
AES Advanced Encryption Standard
AID Application IDentifier
APDU Application Protocol Data Unit
ATR Answer To Reset
CAD Card Acceptance Device
CBC Cipher Block Chaining
CC Common Criteria
CRT Chinese Remainder Theorem
CVM Cardholder Verification Method
DAP Data Authentication Pattern
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 11/130
Acronym Definition
DES Data Encryption Standard
EAL Evaluation Assurance Level
ECB Electronic Code Book
ECC Elliptic Curve Cryptosystem
ECDH Elliptic Curve Diffie Hellman
ECDSA Elliptic Curve Digital Signature Algorithm
GP GlobalPlatform
IC Integrated Circuit(s) Card
JCAPI Java Card Application Programming Interface
JCRE Java Card Runtime Environment
JCVM Java Card Virtual Machine
OSP Organizational Security Policy
PACE Password Authenticated Connection Establishment
PKCS Public-Key Cryptography Standards
PM Project Manager
PP Protection Profile
RNG Random Number Generator
RSA Rivest Shamir Adleman
SAR Security Assurance Requirements
SCP Smart Card Platform
SCP02 Secure Channel Protocol 02
SCP03 Secure Channel Protocol 03
SFP Security Function Policy
SFR Security Functional Requirement
SHA Secure Hash Algorithm
ST Security Target
TOE Target Of Evaluation
TSF TOE Security Functions
VA Verification Authority
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 12/130
2 TOE overview
The TOE is an open Java Card and GlobalPlateform operating system platform primarily intended to
host a set of core Java Card applications (high level of complexity supporting security evaluations) as
well as the possibility to host applets developed by the customer or a third party. For that, the system
can be augmented with additional applets installed during the pre-issuance and/or the post-issuance
phase of TOE’s life cycle.
The TOE is a high-security system evaluated according to the CC assurance level EAL5 augmented
with ALC_DVS.2 and AVA_VAN.5 offering strong security services to the application layer.
2.1 TOE type
The TOE is composed of the smartcard integrated circuit Infineon (IFX) M7892 B11
(SLE78CLFX4000P, SLE78CLFX4000PM, SLE78CFX4000P) containing the IDEMIA Operating System
dedicated to identity product (hereafter called MOSID) as embedded software. The operating system
implements GlobalPlatform services and an open Java Card platform. The functional level of the
operating system is based on a Java multi-application platform, compliant with GlobalPlatform 2.1.1
specifications and Java Card 3.0.1 classic edition, May 2009, including Specification Errata, October
2010, Updated February 2011.
IDeal Citiz v2.1.2 open platform is an Identity product suitable to the identity market worldwide
thanks to its Common Criteria certifications.
IDeal Citiz v2.1.2 is a state of the art security product to help government to issue a trustable identity
document, would it be an identity card, a driving license, a health care card or a passport.
It brings new era to government to jump in the digital world with a truly secure element thanks to the
Common Criteria certification. It enables citizen not only to uniquely identify themselves toward the
civil servant (in city hall, in the street with police officer or at the border) but also with online services
with government as well as private service provider who needs, by regulation, to authenticate and
identify the customer (for instance online banking or telecom operator)
2.2 Usage and major security features of the TOE
The TOE offers the following major product features:
 the contact interface protocol according to ISO or EMV standards (mutually exclusive)
 the contactless interface compliant with ISO 14443 (Type A)
 Java Card V3.0.1 (classic) compliant Java Platform Implementation
 GlobalPlatform 2.1.1 [GP_CS]
o Delegated Management
o Security Domain with DAP verification and Delegated Management
o Manage CVM (Application Privilege)
o Application Extradition.
The major security features of the TOE are the following:
 Secured GlobalPlatform Card Management and GlobalPlatform Domain Separation which
allows a protected post-issuance applet installation under full control of the card issuer,
mobile network operator and application provider respectively
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 13/130
 Protected Java Card Virtual Machine and Runtime Environment, including Strong Java Card
Applet Isolation to protect the integrity and confidentiality of sensitive applet data
 Secure symmetric cryptographic algorithm support including
o (T)DES cipher
o AES cipher with up to 256 bits key length
 Secure asymmetric cryptographic algorithm support including
o RSA CRT with up to 3072 bits key length
o ECC (ECDSA and ECDH) with up to 521 bits key length
 Secure hash algorithm
o SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 hash algorithm.
 Secure Random Generation
o Pseudo-Random Number Generation (PRNG).
 Secure data personalization through GlobalPlatform Secure Channel Protocol:
o SCP02 (i=15)
o SCP03 supported according to GlobalPlatform 2.2 Amendment D.
The TOE offers post-issuance capabilities by downloading additional applets or removing existing
ones. The post-issuance is possible thanks to the GlobalPlatform secure mechanism (SCP). The TOE
provides a full set of Common Criteria certified features to perform such management.
In the same time, the strong protection mechanisms ensure that applet data and code are isolated
(i.e. an applet cannot access data or code of another applet present in the card) and that the overall
integrity of the system is always protected. Thus, the platform is able to host sensitive applets like
mobile payment or transport applications.
2.3 Required non-TOE hardware/software/firmware
The TOE requires the following non-TOE hardware, software and firmware. These non-TOE elements
are outside the scope of evaluation.
2.3.1 Off-Card Bytecode Verifier
The TOE, and in particular the underlying Java Card Platform, rely on an off-card bytecode verifier.
Prior the execution of the file on the card (the loading of the applet), a program running out of the
card (i.e. on a computer) is statically checking the bytecodes of the CAP file methods. Bytecode
verification is a key component of security: applet isolation, for instance, depends on the file satisfying
the properties a verifier checks to hold. A method of a CAP file that has been verified shall not
contain, for instance, an instruction that allows forging a memory address or an instruction that makes
improper use of a return address as if it were an object reference. In other words, bytecodes are
verified to hold up to the intended use to which they are defined.
2.3.2 Contact Based Communication
For direct contact-based communication the environment uses the ISO7816 contact plate of the TOE.
Therefore, no specific additional hardware is required by the TOE itself.
2.3.3 Contactless Communication
For contactless communication, the reader device is using ISO/IEC 14443 communication protocol to
interact with the TOE. This is achieved through the antenna embedded in the product (card or
passport).
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 14/130
2.3.4 Software Components out of TOE Scope
Before the TOE delivery, the audited ALC phases can update the code. This is done through a specific
native software part of the MOSID operating system. When the TOE is delivered, this specific native
software is automatically deleted i.e. the code cannot be updated any more. Therefore this
mechanism is outside the scope of the TOE.
The other native parts of the MOSID system and also pre-loaded applet mechanism are considered in
the evaluation even though some components are “SFR-non-interfering”.
For a detailed overview of the precise TOE boundary and the separation into SFR-related and SFR-
non-interfering parts refer to the TOE description in the next chapter.
2.4 Actors of the TOE
One of the characteristics of the Java Card platforms is that several entities are represented inside
these platforms:
- The Application Provider (AP), entity or institution responsible for the applications and their
associated services. It is mainly a government institution.
- The Card Issuer (CI), entity or institution responsible for the Card issuance and
administration. It is mainly the Government.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 15/130
3 TOE description
3.1 Physical scope of the TOE
From a physical point of view, the Target of Evaluation (TOE) consists of those hardware and software
resources of an IC with embedded software. All non-IC components of the smart card (e.g. magnetic
stripes, holograms, printed or embossed data...) are outside TOE perimeter.
The product is a smart card which uses the following pins as described in the Figure 1 below for
communication.
Figure 1 – View of the smartcard and pins
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 16/130
3.2 Logical scope of the TOE
From a logical point of view, the Target of Evaluation (TOE) is a Smartcard consisting of the MOSID
operating system embedded into an M7892 B11 (SLE78CLFX4000P, SLE78CLFX4000PM,
SLE78CFX4000P) security IC manufactured by Infineon.
Figure 2 Product architecture
The MOS ID operating system is a full operating system implementing an open Java Card platform
and GP card management.
Loaded Applications are outside the scope of the TOE.
With respect to the TOE scope the following aspects have to be considered:
 the product evaluation is a composite evaluation which re-uses the result of a baseline
certification conducted by the IC manufacturer. This baseline evaluation covers the dark-
orange-coloured components in the product, namely the integrated circuit IC and its Crypto
Library.
 the security functionality implementing core of the system consist of the common operating
system, the Java Card system and the secured card content management functions as
specified by Global Platform. Additionally, the security domain hierarchy which is part of a
customer profile has to be taken into account.
3.2.1 IC, Crypto Library
The M7892 B11 (SLE78CLFX4000P, SLE78CLFX4000PM, SLE78CFX4000P) consists of Security Dual
Interface Controllers as integrated circuits, meeting the highest requirements in terms of performance
and security. They are manufactured by Infineon Technologies AG in a 90 nm CMOS-technology
(L90). This M7892 B11 (SLE78CLFX4000P, SLE78CLFX4000PM, SLE78CFX4000P) consists of a core
system, memories, co-processors, peripherals, security modules and analogue peripherals. The major
components of the core system are the two CPUs (Central Processing Units), the MMU (Memory
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 17/130
Management Unit) and MED (Memory Encryption/Decryption Unit). The co-processor block contains
the processors for RSA/ECC and DES/AES processing.
The chip contains two co-processors for cryptographic operations: The Crypto2304T for calculation of
asymmetric algorithms like RSA and Elliptic Curve (ECC) and the Symmetric Cryptographic Processor
(SCP) for dual-key or triple-key triple-DES and AES calculations.
3.2.2 Common Operating System
The Common Operating System is the inner core of the MOSID. Its primary purpose is to implement
an interface between the IC with crypto library and the Java Card System. It serves as a hardware
abstraction layer and implements the following functionalities.
 APDU I/O management
 Memory access and management
 Transaction management
 Exception management
 Timer management
 (Interface to hardware / library) cryptographic functions
 Chip bootstrap
 Chip initialisation
3.2.3 Java Card System
The Java Card System (JCS) allows Java Card based applications (applets) to be run securely on smart
cards. The JCS consists of the Java Card virtual machine (JCVM), the Java Card runtime environment
(JCRE) and the Java Card Application Programming Interface (JCAPI). The Java Card System provides
an intermediate layer between the operating system of the card and the applications. That layer
allows applications written with Java Card technology to be run on any other Java Card platform.
The JCVM is a bytecode interpreter embedded in the smart card. The JCRE is responsible for card
resource management, communication, applet execution, on-card system and applet security.
The JCAPI provides classes and interfaces to the Java Card applets. It defines the calling conventions
by which an applet may access the Java Card RE and native services such as, I/O management
functions, PIN and cryptographic specific management and the exceptions mechanism.
The JCS is based on Java Card 3.0.1 classic edition: see [JCVM], [JCRE] and [JCAPI].
3.2.4 Card Management (CM)
The Card Management component of the TOE implements the functionalities specified in [GP_CS].
These functionalities provide APIs and technologies for secure management of the card content and
especially for the applications hosted by the card.
The Card Management component includes the following optional functionalities:
 Logical Channel Management (channel 1, 2 and 3)
 Supplementary Security Domains
 SCP02
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 18/130
 SCP03
 Delegated Management (without blacklist support)
 DAP Verification and Mandated DAP
 RSA key support (1024 bits)
 Cardholder Verification Method (CVM)
 Global Services Management
 GET STATUS, completely supported (including tag list)
3.2.5 Cryptographic algorithms and functionality
 3DES (56, 112 and 168 bit keys) for en-/decryption (CBC and ECB) and MAC generation and
verification (Retail-MAC, CMAC and CBC-MAC)
 AES (Advanced Encryption Standard) with key length of 128, 192, and 256 Bit for en-
/decryption (CBC and ECB) and MAC generation and verification (CMAC, CBC-MAC)
 RSA (768 up to 2112 bits keys) and RSA CRT (768 up to 3072 bits keys) for en-/decryption
and signature generation and verification.
 RSA and RSA CRT key generation 768 up to 3072 bits keys (except 1120 and 2272 bits)
 SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 hash algorithm
 ECC with key sizes (up to 521 bits key length) that can be used for: (i) signature generation
and signature verification (ECDSA); (ii) key pair generation; (iii) Elliptic Curve Diffie Hellman
(ECDH)
 PRNG which is compliant with [NIST_SP800-90A] and which uses the certified Hardware
Random Generator that fulfils the requirements of AIS31 (see [ST_IC])
3.2.6 PACE API
The PACE API is part of the TOE and provides the following services:
 SAC PACE authentication (DES/AES algorithms)
 Secure Messaging initialization with session keys issued from the PACE authentication.
 PACE mapping (point generation with ECDH and domain generation)
This API is optional as it can be removed during personalisation phase: The memory zone which
contains data for PACE is made unavailable and error messages are returned when API is called.
3.2.7 DH API
The DH API is part of the TOE and provides the following services:
 Key exchange
 Key generation
3.3 Life cycle
The following description introduces generics but fine-grained 3 models for the life-cycle of secure
smartcard products. The 3 models are compliant to standard smartcard life-cycle models as defined in
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 19/130
[PP_JC] and [PP_IC]. Since applets loading is outside the TOE, this document focuses on the Java
Card platform (the TOE) life cycle which is part of the smart card product life cycle.
The intent of the more fine-grained models is to cover the specific aspects of new technologies like
flashing or applet loading in a comprehensive way and to add some flexibility with respect to the
separation of responsibilities between the various parties involved. Consider the following 3 life-cycle
supported for this product (LC1 to LC3).
The smartcard product life-cycle is decomposed in 7 steps that describe the competent authorities for
each of these steps.
The embedded software development is the core scope of the composite evaluation and corresponds
directly to step 1 of the standard smartcard life-cycle defined in [PP_IC]. The embedded software
development shall occur in a controlled environment that avoids disclosure of source code, data and
any critical documentation and that guarantees the integrity of these elements. The purpose of the
embedded software designed in step 1 is to control and protect the TOE during steps 5 to 7 (product
usage).
The step 2 “IC Development” of the standard life-cycle is directly visible in the life-cycle overview.
The Life Cycle model extracts the OS Flash-loading process from step 3 “IC Manufacturing” because
for Flash products the “OS Loading” is no longer directly coupled to the IC manufacturing. Thus, the
IC manufacturing primarily deals with the physical manufacturing of the IC (production of wafers) and
IC pre-personalisation. Whether the IC manufacturer takes also care of the OS loading (either by
masking or by flashing) depends on the product and is detailed in the concrete product-type specific
instantiation of the life-cycle.
The step 4 “IC initialization” from the standard model is also focussed on the logical production steps
which are detailed into “OS loading” (masking or flashing). During this step the IDEMIA software is
loaded with a blackbox. The generic blackbox contains only authentication keys. The dedicated
blackbox contains keys, specific initialization and pre-personalization values. Moreover, this step
includes the configuration (CNF) stage, which is a IDEMIA proprietary card life cycle stage. The TOE
delivery point is placed at the end of step 4 for Life cycles 1 and 2, since the entire TOE is built and
embedded in the Security IC.
The step 5 “Product Pre-Personalisation” corresponds to the loading of non-card individual data. The
TOE delivery point is placed at the end of this step for the Life Cycle 3.
The step 6 “Personalisation” of the standard model as described in [PP_IC] corresponds directly to
the “Product Personalisation” (loading of card individual data). During the personalisation, the PACE
API can be removed, as described in 3.2.6. Notice that this step is not included in the present
evaluation. Appropriate security recommendations are provided to the Personalizer through the
guidance documents.
3.3.1 Life Cycle 1
For this Life Cycle “LC1”, the wafer is manufactured and initialized at the founder site. It is
then shipped to IDEMIA, successively through the module and the inlay (CL interface only)
manufacturers. IDEMIA may be responsible for the embedding process and for the pre-personalization
of the card too. Finally, the card is shipped to the Personalizer. During the shipment from IC
manufacturer to IDEMIA, the chip is protected by a diversified key derived from the IDEMIA factory
dedicated master key. During the shipment from IDEMIA to the Personalizer, the card is protected by
a diversified key derived from a Personalizer dedicated master key.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 20/130
Phase 1
Development
Step 1 Embedded software
development
Step 2 IC design and dedicated
software development
Step 3
Integration
Photomask fabrication
IC manufacturing
Phase 2
Manufacturing
Step 4
IC initialization
Card pre-personalization
Step 5
Phase 3
Personalization
Embedding process
Step 6
Phase 4
Usage Usage
Step 7
End of life
TOE
under
construction
Secured
by
Environement
TOE
operational
Secured
by
TOE
Development sites
IC manufacturer
Embedder
Module manufacturer
Personalizer
User
Module manufacturing
Inlay manufacturing
Personalization
Inlay manufacturer
Flashing +
Generic BB
Pre-personalizer
CT / DIC
CL
Figure 3 Flashing and generic BlackBox loading at founder site on wafer; pre-
personalization on card
Step/Phase Role Actors Sites Covered by
Phase 1-Step 1 Embedded
Software
Developer
Idemia Osny ALC R&D sites
Phase 1-Step 2 Integrated
Circuit (IC)
Developer
Infineon Munich, Graz ,
Augsburg
ALC (IC
certification)
Phase 1&2-Step 3 Integrated
Circuit (IC)
Manufacturer
Infineon Dresden ALC (IC
certification)
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 21/130
Phase 2-Step 4 Integrated
Circuit (IC)
Manufacturer
(Configurator)
Infineon Dresden ALC (IC
certification)
Phase 2-Module
Manufacturing
Module
Manufacturer
Infineon
Nedcard
Dresden
Wijchen
AGD_PRE
Phase 2-Inlay
Manufacturing
Inlay
Manufacturer
Smartrac
HID
Kulim
Kulaijaya
AGD_PRE
Phase 2-Embedding
process
Embedder Idemia
SELP
Customer
Haarlem/Ostra
va
Angouleme
Customer
premises
AGD_PRE
Phase 2-Step 5 Pre-
personalizer
Idemia or
Infineon
Haarlem/Ostra
va
or
Dresden
AGD_PRE
Phase 3-Step 6 Personalizer Idemia or
Customer
Haarlem/Ostra
va
Customer
premises
AGD_PRE
Phase 4-Step 7 User The End user of the
Card
AGD_OPE
3.3.2 Life Cycle 2
For this Life Cycle “LC2”, the wafer is manufactured and initialized at the founder site. It is
then shipped to IDEMIA through the module manufacturer. IDEMIA may be responsible for pre-
personalization of the module prior to being sent successively to the inlay manufacturer and the
embedding process. Finally, the card is shipped to the Personalizer directly. During the shipment from
IC manufacturer to IDEMIA, the chip is protected by a diversified key derived from the IDEMIA factory
dedicated master key. During the shipment from IDEMIA to the Personalizer (through the inlay
manufacturer and the embedded), the chip is protected by a diversified key derived from a
Personalizer dedicated master key.
TOE Delivery
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 22/130
Phase 1
Development
Step 1 Embedded software
development
Step 2 IC design and dedicated
software development
Step 3
Integration
Photomask fabrication
IC manufacturing
Phase 2
Manufacturing
Step 4
IC initialization
Module pre-personalization
Step 5
Phase 3
Personalization
Embedding process
Step 6
Phase 4
Usage Usage
Step 7
End of life
TOE
under
construction
Secured
by
Environement
TOE
operational
Secured
by
TOE
Development sites
IC manufacturer
Embedder
Module manufacturer
Personalizer
User
Module manufacturing
Inlay manufacturing
Personalization
Inlay manufacturer
Pre-personalizer
Flashing +
Generic BB
CT / DIC
CL
Figure 4 Flashing and generic BlackBox loading at founder site on wafer; pre-
personalization on module
Step/Phase Role Actors Sites Covered by
Phase 1-Step 1 Embedded
Software
Developer
Idemia Osny ALC R&D sites
Phase 1-Step 2 Integrated
Circuit (IC)
Developer
Infineon Munich, Graz ,
Augsburg
ALC (IC
certification)
Phase 2-Step 3 Integrated
Circuit (IC)
Manufacturer
Infineon Dresden ALC (IC
certification)
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 23/130
Phase 2-Step 4 Integrated
Circuit (IC)
Manufacturer
(Configurator)
Infineon Dresden ALC (IC
certification)
Phase 2-Module
Manufacturing
Module
Manufacturer
Infineon
Nedcard
Dresden
Wijchen
AGD_PRE
Phase 2-Step 5 Pre-
personalizer
Idemia or
Infineon
Haarlem/Ostrava
or
Dresden
AGD_PRE
Phase 2-Inlay
Manufacturing
Inlay
Manufacturer
Smartrac
HID
Kulim
Kulaijaya
AGD_PRE
Phase 2-Embedding
process
Embedder Idemia
SELP
Customer
Haarlem/Ostrava
Angouleme
Customer
premises
AGD_PRE
Phase 3-Step 6 Personalizer Idemia or
customer
Haarlem/Ostrava
Customer
premises
AGD_PRE
Phase 4-Step 7 User The End user of
the Card
AGD_OPE
3.3.3 Life Cycle 3
For this Life Cycle “LC3”, the wafer is manufactured, initialized and pre-personalized at the
founder site. It is then shipped to Idemia through the module manufacturer and the inlay
manufacturer (CL interface only). Idemia may then be responsible for the embedding process. Finally,
the card is shipped to the Personalizer directly. During the shipment from the Pre-personalizer to the
Personalizer, the card is protected by a diversified key derived from a Personalizer dedicated master
key.
TOE Delivery
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 24/130
Phase 1
Development
Step 1 Embedded software
development
Step 2 IC design and dedicated
software development
Step 3
Integration
Photomask fabrication
IC manufacturing
Phase 2
Manufacturing
Step 4
IC initialization
IC pre-personalization
Step 5
Phase 3
Personalization
Embedding process
Step 6
Phase 4
Usage Usage
Step 7
End of life
TOE
under
construction
Secured
by
Environement
TOE
operational
Secured
by
TOE
Development sites
IC manufacturer
Embedder
Module manufacturer
Personalizer
User
Module manufacturing
Inlay manufacturing
Personalization
Inlay manufacturer
Flashing +
Generic BB
Pre-personalizer
CT / DIC
CL
Figure 5 Flashing and dedicated BlackBox loading at founder site on wafer; pre-
personalization on IC
Step/Phase Role Actors Sites Covered by
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 25/130
Phase 1-Step 1 Embedded
Software
Developer
Idemia Osny ALC R&D
sites
Phase 1-Step 2 Integrated
Circuit (IC)
Developer
Infineon Munich, Graz ,
Augsburg
ALC (IC
certificatio
n)
Phase 1&2-Step 3 Integrated
Circuit (IC)
Manufacturer
Infineon Dresden ALC (IC
certificatio
n)
Phase 2-Step 4 Integrated
Circuit (IC)
Manufacturer
(Configurator)
Infineon Dresden ALC (IC
certificatio
n)
Phase 2-Step 5 Pre-
personalizer
Infineon Dresden ALC (IC
certificatio
n)
Phase 2-Module
Manufacturing
Module
Manufacturer
Infineon
Nedcard
Dresden
Wijchen
AGD_PRE
Phase 2-Inlay
Manufacturing
Inlay
Manufacturer
Smartrac
HID
Kulim
Kulaijaya
AGD_PRE
Phase 2-Embedding
process
Embedder Idemia
SELP
Customer
Haarlem/Ostrava
Angouleme
Customer
premises
AGD_PRE
Phase 3-Step 6 Personalizer Idemia or
Customer
Haarlem/Ostrava
Customer
premises
AGD_PRE
Phase 4-Step 7 User The End user of the
Card
AGD_OPE
3.3.4 Actors & Coverage
The actors of the smart card product life-cycle are listed on the table below:
Actors Identification
Integrated Circuit (IC) developer Infineon
Embedded software developer Idemia (Osny)
Card manufacturer
Integrated Circuit
(IC) manufacturer
Infineon
Integrated Circuit
(IC) configurator
Infineon
Module manufacturer Nedcard, Infineon
Inlay manufacturer HID, Smartrac
Pre-personalizer Idemia or Infineon
Embedder Idemia, SELP, Customer
TOE Delivery
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 26/130
Actors Identification
Personalizer / Issuer
The agent who is acting on the behalf of the
issuing State or Organization and personalize the
card for the holder by activities establishing the
identity of the holder with biographic data.
Card Holder / User
The rightful holder of the card for whom the
issuing State or Organization personalizes the card.
Table 1 Actors of the smart card product
3.3.5 Description of the TOE environment
The TOE environment is defined as follows:
- Development environment corresponding to steps 1 and 2;
- Production environment:
 IC Photomask fabrication and IC Manufacturing environment corresponding to steps 3;
 Smartcard finishing process environment and pre-personalisation (initialization)
corresponding to steps 4 and 5;
 Personalization environment corresponding to step 6.
- Card exploitation environment corresponding to step 7.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 27/130
4 Common Criteria Conformance Claim
4.1 Common Criteria Conformance
This Security Target claims conformance to Common Criteria version 3.1 Revision 4, with the following
documents:
- “Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and
general model”, [CC_Part1]
- “Common Criteria for Information Technology Security Evaluation, Part 2: Security Functional
requirements”, [CC_Part2]
- “Common Criteria for Information Technology Security Evaluation, Part 3: Security Assurance
requirements”, [CC_Part3]
Conformance is claimed as follows:
- Part 1: conformant
- Part 2: conformant
- Part 3: conformant, compliant to EAL5 augmented with ALC_DVS.2 and AVA_VAN.5.
4.2 Conformance with an assurance package
The set of assurance requirements is the package EAL5 augmented by:
- ALC_DVS.2, “Sufficiency of security measures”
- AVA_VAN.5, “Advanced methodical vulnerability analysis”
Assurance requirements are split in two packages, one for the TOE itself and one for its development
environment, allowing for separate package assessment. However, both assessments must be
combined in order to fulfil the whole set of PP assurance requirements.
4.2.1 AVA_VAN.5 and Industrial Key Length Requirements
The assurance level EAL5 augmented with AVA_VAN.5 implies that the product shall enforce
resistance against an attacker with a high-attack potential. This in particular also has implications on
brute-force attacks on cryptographic algorithms. With respect to such kinds of attacks, the resistance
of a cryptographic scheme depends massively on the length of the cryptographic key material used,
which defines the size of the key space a single key is selected from. Therefore, certification bodies
and other national cryptography approval bodies publish minimum requirements for the key material
of the various crypto schemes.
For example, the currently recommended length for RSA keys is 2048 bits and the long-term
resistance of TDES is no longer confirmed.
However, some industrial standards still use shorter key lengths than those considered the
recommended minimum for ensuring resistance against brute force attacks with a high attack
potential. For example, the usage of RSA keys in the context of GlobalPlatform card content
management permits the usage of 1024 bits RSA keys.
This usage of slightly weaker keys than the recommended ones can be perfectly reasonable from a
risk management perspective of the customer. This is in particular true if a long-term migration
strategy is to be taken into account for updating an already running eco-system including e.g. a large
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 28/130
background infrastructure. However, the usage of no longer recommended key length produces a
formal incompliance with the AVA_VAN.5 resistance level the product has to achieve.
To resolve this issue, the assurance claim should be interpreted more precisely as follows for the
product specified in this security target: the product reaches the assurance level EAL5 augmented
with AVA_VAN.5 if appropriate, recommended key length are used. Even in the case that industrial
standards require the usage of weaker keys, the product is still highly-resistant with respect to all
attack scenarios with the limitation of highly resistant to all attack scenarios with the limitation of
brute force attacks on small keys.
4.3 Conformance with a Protection Profile
This Security Target is conformant with the Java Card Protection Profile [PP_JC], without the RMI
(Remote Method Invocation) option, which is not implemented and out of the scope of this evaluation.
Therefore RMI related entities, subject, object, information, operation and security attribute, as well
as the corresponding SFRs of the Java Card Protection Profile [PP_JC] are excluded from this
Security Target.
4.4 Conformance Rationale
This Security Target claims a Strict conformance with the Java Card Protection Profile [PP_JC].
4.4.1 TOE type consistency
The TOE type is "Java Card 3.0.1 conformant to GlobalPlatform 2.1.1, implemented on a Infineon chip
of the M7892 B11 (SLE78CLFX4000P, SLE78CLFX4000PM, SLE78CFX4000P) family” and protection
profile TOE type is "smart card platform enabled with Java Card technology". TOE types are
compatible since the security target's TOE is a smart card that is enabled with Java Card technology.
4.4.2 SPD statement consistency
All assets and threats from [PP_JC] are included in this ST. The only exception is that the threat
T.EXE-CODE-REMOTE is removed due to the fact that the product does not support the threatened
RMI functionality.
4 additional assets have been added to those of the [PP_JC] : D.COMMAND, D.GP_CODE,
D.SD_KEYS and D.ISD_KEYS. These assets have been included because the security domain and the
GlobalPlatform framework are parts of the TOE.
1 optional asset from the [PP_JC] , D.BIO, has been included because biometric templates are part
of the TOE.
4 additional threats have been added to those of the [PP_JC]: T.APP_DATA_INTEGRITY,
T.UNAUTH_CARD_MNGT, T.LIFE_CYCLE and T.UNAUTH_ACCESS. These threats have been added
because card management becomes part of the TOE.
All OSPs from [PP_JC] are included in this ST and 4 OSPs are added: OSP.SECURITY_DOMAINS,
OSP.QUOTAS, OSP.KEY_GENERATION and OSP.SHARE-CONTROL.
OSP.SECURITY_DOMAINS and OSP.QUOTAS have been included because the security domain is part
of the TOE.
All assumptions from [PP_JC] are included in this ST. However, some assumptions from the PP are
removed in the ST for the following reasons: A.DELETION becomes irrelevant in this ST as card
management, applet deletion included, is a TOE feature.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 29/130
The assumption A.PRODUCTION has been added because of the TOE life cycle (the TOE can be
delivered before step 6). This assumption doesn’t mitigate any threat and doesn’t fulfil any OSP meant
to be addressed by security objectives for the TOE in the PP.
The statement of SPD is therefore consistent with those stated in [PP_JC].
4.4.3 Security Objectives Consistency
The TOE objectives are a superset of those in [PP_JC]. Actually, all the TOE objectives from the PP
are copied in the ST with the exception of the optional objective O.REMOTE, which is an objective for
the not supported RMI functionality. Additionally, the objectives for the operational environment from
the PP related the SCP (IC and Microkernel parts) are moved as TOE objectives in the ST. These
objectives are: O.SCP.IC, O.SCP.RECOVERY and O.SCP.SUPPORT.
The card manager becomes part of the TOE: the objective for the operational environment OE.CARD-
MANAGEMENT is moved as TOE objective in the ST.
The optional security objective from the [PP_JC], O.BIO-MNGT has been added because biometric
template is part of the TOE
Objectives for the environment in this ST are identical to those in [PP_JC]. However, some objectives
for the environment from the PP are removed in the ST for the following reasons:
 OE.CARD-MANAGEMENT, OE.SCP.IC, OE.SCP.RECOVERY and OE.SCP.SUPPORT are
transformed into TOE objectives. These objectives don’t mitigate any threats of the PP and
don’t fulfil any OSPs meant to be addressed by security objectives for the TOE in the PP.
4.4.4 Consistency of the Security Objectives for the environment
The security objectives for the operational environment directly taken over from [PP_JC] are:
OE.APPLET, OE.VERIFICATION and OE.CODE-EVIDENCE.
Others security objectives for the operational environment from [PP_JC] become objectives for the
TOE.
Additionally, these security objectives for the operational environment are added to the ST:
OE.SECURITY-DOMAINS, OE.QUOTAS, OE.SHARE-CONTROL, OE.KEY_GENERATION and
OE.PRODUCTION.
4.4.5 Security Requirements Consistency
The set of SFRs is a superset of those in the [PP_JC] with the exception that the SFRs related to RMI
functionality are not part of this security target. Actually, all the SFRs taken over from the PP are
refined in the ST. Furthermore, the following SFRs, related to the IT requirements introduced in
[PP_JC] by the Smart Group Platform and that are imposed on the operating system and the
integrated circuit underlying the implementation of the Runtime Environment, have been added:
 FPT_RCV.3/OS;
 FPT_RCV.4/OS;
 FPT_FLS.1/OS;
 FPT_PHP.3/OS;
The following SFRs related to the Card Life Cycle Management have been added:
 FDP_ACC.1/CardLifeCycleManagement;
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 30/130
 FDP_ACF.1/CardLifeCycleManagement;
 FMT_MSA.1/CardLifeCycleManagement;
 FMT_MSA.3/CardLifeCycleManagement;
 FTP_ITC.1/CardLifeCycleManagement.
The following SFRs related to the PACE API have been added:
 FCS_CKM.2/PACE;
 FCS_CKM.3/PACE;
 FCS_COP.1/PACE.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 31/130
5 SECURITY ASPECTS
This chapter describes the main security issues of the Java Card System and its environment
addressed in this Security Target, called “security aspects”, in a CC-independent way. In addition to
this, they also give a semi-formal framework to express the CC security environment and objectives of
the TOE. They can be instantiated as assumptions, threats, objectives (for the TOE and the
environment) or organizational security policies.
5.1 CONFIDENTIALITY
#.CONFID-APPLI-DATA Application data must be protected against unauthorized disclosure.
This concerns logical attacks at runtime in order to gain read access to other application’s data.
#.CONFID-JCS-CODE Java Card System code must be protected against unauthorized
disclosure. Knowledge of the Java Card System code may allow bypassing the TSF. This
concerns logical attacks at runtime in order to gain a read access to executable code, typically
by executing an application that tries to read the memory area where a piece of Java Card
System code is stored.
#.CONFID-JCS-DATA Java Card System data must be protected against unauthorized
disclosure. This concerns logical attacks at runtime in order to gain a read access to Java Card
System data. Java Card System data includes the data managed by the Java Card RE, the Java
Card VM and the internal data of Java Card platform API classes as well.
5.2 INTEGRITY
#.INTEG-APPLI-CODE Application code must be protected against unauthorized
modification. This concerns logical attacks at runtime in order to gain write access to the
memory zone where executable code is stored. In post-issuance application loading, this threat
also concerns the modification of application code in transit to the card.
#.INTEG-APPLI-DATA Application data must be protected against unauthorized modification.
This concerns logical attacks at runtime in order to gain unauthorized write access to
application data. In post-issuance application loading, this threat also concerns the modification
of application data contained in a package in transit to the card. For instance, a package
contains the values to be used for initializing the static fields of the package.
#.INTEG-JCS-CODE Java Card System code must be protected against unauthorized
modification. This concerns logical attacks at runtime in order to gain write access to executable
code.
#.INTEG-JCS-DATA Java Card System data must be protected against unauthorized
modification. This concerns logical attacks at runtime in order to gain write access to Java Card
System data. Java Card System data includes the data managed by the Java Card RE, the Java
Card VM and the internal data of Java Card API classes as well.
5.3 UNAUTHORIZED EXECUTIONS
#.EXE-APPLI-CODE Application (byte) code must be protected against unauthorized
execution. This concerns (1) invoking a method outside the scope of the accessibility rules
provided by the access modifiers of the Java programming language; (2) jumping inside a
method fragment or interpreting the contents of a data memory area as if it was executable
code.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 32/130
#.EXE-JCS-CODE Java Card System bytecode must be protected against unauthorized
execution. Java Card System bytecode includes any code of the Java Card RE or API. This
concerns (1) invoking a method outside the scope of the accessibility rules provided by the
access modifiers of the Java programming language; (2) jumping inside a method fragment or
interpreting the contents of a data memory area as if it was executable code. Note that execute
access to native code of the Java Card System and applications is the concern of #.NATIVE.
#.FIREWALL The Firewall shall ensure controlled sharing of class instances, and isolation of
their data and code between packages (that is, controlled execution contexts) as well as
between packages and the JCRE context. An applet shall not read, write, compare a piece of
data belonging to an applet that is not in the same context, or execute one of the methods of
an applet in another context without its authorization.
#.NATIVE Because the execution of native code is outside of the JCS TSF scope, it must be
secured so as to not provide ways to bypass the TSFs of the JCS. Loading of native code, which
is as well outside those TSFs, is submitted to the same requirements. Should native software be
privileged in this respect, exceptions to the policies must include a rationale for the new
security framework they introduce.
5.4 BYTECODE VERIFICATION
#.VERIFICATION Bytecode must be verified prior to being executed. Bytecode verification
includes (1) how well-formed CAP file is and the verification of the typing constraints on the
bytecode, (2) binary compatibility with installed CAP files and the assurance that the export files
used to check the CAP file correspond to those that will be present on the card when loading
occurs.
5.5 CARD MANAGEMENT
#.INSTALL (1) The TOE must be able to return to a safe and consistent state when the
installation of a package or an applet fails or be cancelled (whatever the reasons). (2) Installing
an applet must have no effect on the code and data of already installed applets. The installation
procedure should not be used to bypass the TSFs. In short, it is an atomic operation, free of
harmful effects on the state of the other applets. (3) The procedure of loading and installing a
package shall ensure its integrity and authenticity.
#.SID (1) Users and subjects of the TOE must be identified. (2) The identity of sensitive users
and subjects associated with administrative and privileged roles must be particularly protected;
this concerns the Java Card RE, the applets registered on the card, and especially the default
applet and the currently selected applet (and all other active applets in Java Card System
2.2.x). A change of identity, especially standing for an administrative role (like an applet
impersonating the Java Card RE), is a severe violation of the Security Functional Requirements
(SFR). Selection controls the access to any data exchange between the TOE and the CAD and
therefore, must be protected as well. The loading of a package or any exchange of data
through the APDU buffer (which can be accessed by any applet) can lead to disclosure of keys,
application code or data, and so on.
#.OBJ-DELETION (1) Deallocation of objects should not introduce security holes in the form
of references pointing to memory zones that are no longer in use, or have been reused for
other purposes. Deletion of collection of objects should not be maliciously used to circumvent
the TSFs. (2) Erasure, if deemed successful, shall ensure that the deleted class instance is no
longer accessible.
#.DELETION (1) Deletion of installed applets (or packages) should not introduce security
holes in the form of broken references to garbage collected code or data, nor should they alter
integrity or confidentiality of remaining applets. The deletion procedure should not be
maliciously used to bypass the TSFs. (2) Erasure, if deemed successful, shall ensure that any
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 33/130
data owned by the deleted applet is no longer accessible (shared objects shall either prevent
deletion or be made inaccessible). A deleted applet cannot be selected or receive APDU
commands. Package deletion shall make the code of the package no longer available for
execution. (3) Power failure or other failures during the process shall be taken into account in
the implementation so as to preserve the SFRs. This does not mandate, however, the process
to be atomic. For instance, an interrupted deletion may result in the loss of user data, as long
as it does not violate the SFRs.
The deletion procedure and its characteristics (whether deletion is either physical or logical,
what happens if the deleted application was the default applet, the order to be observed on the
deletion steps) are implementation-dependent. The only commitment is that deletion shall not
jeopardize the TOE (or its assets) in case of failure (such as power shortage).
Deletion of a single applet instance and deletion of a whole package are functionally different
operations and may obey different security rules. For instance, specific packages can be
declared to be undeletable (for instance, the Java Card API packages), or the dependency
between installed packages may forbid the deletion (like a package using super classes or super
interfaces declared in another package).
5.6 SERVICES
#.ALARM The TOE shall provide appropriate feedback upon detection of a potential security
violation. This particularly concerns the type errors detected by the bytecode verifier, the
security exceptions thrown by the Java Card VM, or any other security-related event occurring
during the execution of a TSF.
#.OPERATE (1) The TOE must ensure continued correct operation of its security functions. (2)
In case of failure during its operation, the TOE must also return to a well-defined valid state
before the next service request.
#.RESOURCES The TOE controls the availability of resources for the applications and enforces
quotas and limitations in order to prevent unauthorized denial of service or malfunction of the
TSFs. This concerns both execution (dynamic memory allocation) and installation (static
memory allocation) of applications and packages.
#.CIPHER The TOE shall provide a means to the applications for ciphering sensitive data, for
instance, through a programming interface to low-level, highly secure cryptographic services. In
particular, those services must support cryptographic algorithms consistent with cryptographic
usage policies and standards.
#.KEY-MNGT The TOE shall provide a means to securely manage cryptographic keys. This
includes: (1) Keys shall be generated in accordance with specified cryptographic key generation
algorithms and specified cryptographic key sizes, (2) Keys must be distributed in accordance
with specified cryptographic key distribution methods, (3) Keys must be initialized before being
used, (4) Keys shall be destroyed in accordance with specified cryptographic key destruction
methods.
#.PIN-MNGT The TOE shall provide a means to securely manage PIN objects. This includes:
(1) Atomic update of PIN value and try counter, (2) No rollback on the PIN-checking function,
(3) Keeping the PIN value (once initialized) secret (for instance, no clear-PIN-reading function),
(4) Enhanced protection of PIN’s security attributes (state, try counter…) in confidentiality and
integrity.
#.SCP The smart card platform must be secure with respect to the SFRs. Then: (1) After a
power loss, RF signal loss or sudden card removal prior to completion of some communication
protocol, the SCP will allow the TOE on the next power up to either complete the interrupted
operation or revert to a secure state. (2) It does not allow the SFRs to be bypassed or altered
and does not allow access to other low-level functions than those made available by the
packages of the Java Card API. That includes the protection of its private data and code
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 34/130
(against disclosure or modification) from the Java Card System. (3) It provides secure low-level
cryptographic processing to the Java Card System. (4) It supports the needs for any update to
a single persistent object or class field to be atomic, and possibly a low-level transaction
mechanism. (5) It allows the Java Card System to store data in “persistent technology memory”
or in volatile memory, depending on its needs (for instance, transient objects must not be
stored in non-volatile memory). The memory model is structured and allows for low–level
control accesses (segmentation fault detection). (6) It safely transmits low–level exceptions to
the TOE (arithmetic exceptions, checksum errors), when applicable. Finally, it is required that
(7) the IC is designed in accordance with a well-defined set of policies and standards (for
instance, those specified in [PP0035]), and will be tamper resistant to actually prevent an
attacker from extracting or altering security data (like cryptographic keys) by using commonly
employed techniques (physical probing and sophisticated analysis of the chip). This especially
matters to the management (storage and operation) of cryptographic keys. .
#.TRANSACTION The TOE must provide a means to execute a set of operations atomically.
This mechanism must not jeopardise the execution of the user applications. The transaction
status at the beginning of an applet session must be closed (no pending updates).
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 35/130
6 Security Problem Definition
6.1 Assets
6.1.1 Java Card System Protection Profile - Open Configuration
Assets are security-relevant elements to be directly protected by the TOE. Confidentiality of
assets is always intended with respect to un-trusted people or software, as various parties
are involved during the first stages of the smart card product life-cycle; details are given in
threats hereafter.
Assets may overlap, in the sense that distinct assets may refer (partially or wholly) to the
same piece of information or data. For example, a piece of software may be either a piece of
source code (one asset) or a piece of compiled code (another asset), and may exist in
various formats at different stages of its development (digital supports, printed paper). This
separation is motivated by the fact that a threat may concern one form at one stage, but be
meaningless for another form at another stage.
The assets to be protected by the TOE are listed below. They are grouped according to
whether it is data created by and for the user (User data) or data created by and for the TOE
(TSF data). For each asset it is specified the kind of dangers that weigh on it.
6.1.1.1 User data
D.APP_CODE
The code of the applets and libraries loaded on the card.
To be protected from unauthorized modification.
D.APP_C_DATA
Confidential sensitive data of the applications, like the data contained in an object, a static
field of a package, a local variable of the currently executed method, or a position of the
operand stack.
To be protected from unauthorized disclosure.
D.APP_I_DATA
Integrity sensitive data of the applications, like the data contained in an object, a static
field of a package, a local variable of the currently executed method, or a position of the
operand stack.
To be protected from unauthorized modification.
D.APP_KEYs
Cryptographic keys owned by the applets.
To be protected from unauthorized disclosure and modification.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 36/130
D.PIN
Any end-user's PIN.
To be protected from unauthorized disclosure and modification.
D.BIO
Biometric template. Only the fingerprint is in the scope of the TOE. To be protected from
unauthorized disclosure and modification.
6.1.1.2 TSF data
D.API_DATA
Private data of the API, like the contents of its private fields.
To be protected from unauthorized disclosure and modification.
D.CRYPTO
Cryptographic data used in runtime cryptographic computations, like a seed used to
generate a key.
To be protected from unauthorized disclosure and modification.
D.JCS_CODE
The code of the Java Card System.
To be protected from unauthorized disclosure and modification.
D.JCS_DATA
The internal runtime data areas necessary for the execution of the Java Card VM, such as,
for instance, the frame stack, the program counter, the class of an object, the length
allocated for an array, any pointer used to chain data-structures.
To be protected from unauthorized disclosure or modification.
D.SEC_DATA
The runtime security data of the Java Card RE, like, for instance, the AIDs used to identify
the installed applets, the currently selected applet, the current context of execution and
the owner of each object.
To be protected from unauthorized disclosure and modification.
6.1.2 Card Management
6.1.2.1 User Data
D.COMMAND
An APDU commands addressed to the Security Domains contains a request for a card
management service. Valid requests come either from the Cardholder or from the Card
Administrator. This asset shall be protected from unauthorized modification. Some specific
card management commands, like those containing keys, shall be also protected from
unauthorized disclosure.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 37/130
6.1.2.2 TSF Data
D.GP_CODE
The code of the GlobalPlatform framework on the card. To be protected from
unauthorized modification.
D.SD_KEYS
The cryptographic keys that the Security Domain uses for ensuring the integrity and origin
of card management requests. This asset shall be protected from unauthorized disclosure
and modification.
D.ISD_KEYS
During personalization, the cryptographic keys are stored in the Issuer Security Domain,
the on-card representative of the Card Issuer. These keys needed to support several card
management functions, like setting up a secure channel with the terminal. If the card is
issued with Supplementary Security Domains, cryptographic keys of these Security
Domain are also personalized. These assets shall be protected from disclosure and
unauthorized modification.
6.2 Threats
This section describes the threats that concerned the TOE. Only the threat concerning IDeal
Citiz v2.1.2 open platform are described, but threats on the table below (from [ST_IC]) must
be considered:
T.Phys-Manipulation Physical Manipulation
T.Phys-Probing Physical Probing
T.Malfunction Malfunction due to Environmental Stress
T.Leak-Inherent Inherent Information Leakage
T.Leak-Forced Forced Information Leakage
T.Abuse-Func Abuse of Functionality
T.RND Deficiency of Random Numbers
T.Mem-Access Memory Access Violation
6.2.1 Java Card System Protection Profile - Open Configuration
This section introduces the threats to the assets against which specific protection within the
TOE or its environment is required. Several groups of threats are distinguished according to
the configuration chosen for the TOE and the means used in the attack. The classification is
also inspired by the components of the TOE that are supposed to counter each threat.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 38/130
6.2.1.1 CONFIDENTIALITY
T.CONFID-APPLI-DATA
The attacker executes an application to disclose data belonging to another application.
See #.CONFID-APPLI-DATA for details.
Directly threatened asset(s): D.APP_C_DATA, D.PIN, D.BIO and D.APP_KEYs.
T.CONFID-JCS-CODE
The attacker executes an application to disclose the Java Card System code. See
#.CONFID-JCS-CODE for details.
Directly threatened asset(s): D.JCS_CODE.
T.CONFID-JCS-DATA
The attacker executes an application to disclose data belonging to the Java Card System.
See #.CONFID-JCS-DATA for details.
Directly threatened asset(s): D.API_DATA, D.SEC_DATA, D.JCS_DATA and D.CRYPTO.
6.2.1.2 INTEGRITY
T.INTEG-APPLI-CODE
The attacker executes an application to alter (part of) its own code or another
application's code. See #.INTEG-APPLI-CODE for details.
Directly threatened asset(s): D.APP_CODE.
T.INTEG-APPLI-CODE.LOAD
The attacker modifies (part of) its own or another application code when an application
package is transmitted to the card for installation. See #.INTEG-APPLI-CODE for details.
Directly threatened asset(s): D.APP_CODE.
T.INTEG-APPLI-DATA
The attacker executes an application to alter (part of) another application's data. See
#.INTEG-APPLI-DATA for details.
Directly threatened asset(s): D.APP_I_DATA, D.PIN, D.BIO and D.APP_KEYs.
T.INTEG-APPLI-DATA.LOAD
The attacker modifies (part of) the initialization data contained in an application package
when the package is transmitted to the card for installation. See #.INTEG-APPLI-DATA for
details.
Directly threatened asset(s): D.APP_I_DATA and D_APP_KEY.
T.INTEG-JCS-CODE
The attacker executes an application to alter (part of) the Java Card System code. See
#.INTEG-JCS-CODE for details.
Directly threatened asset(s): D.JCS_CODE.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 39/130
T.INTEG-JCS-DATA
The attacker executes an application to alter (part of) Java Card System or API data. See
#.INTEG-JCS-DATA for details.
Directly threatened asset(s): D.API_DATA, D.SEC_DATA, D.JCS_DATA and D.CRYPTO.
Other attacks are in general related to one of the above, and aimed at disclosing or
modifying on-card information. Nevertheless, they vary greatly on the employed means and
threatened assets, and are thus covered by quite different objectives in the sequel. That is
why a more detailed list is given hereafter.
6.2.1.3 IDENTITY USURPATION
T.SID.1
An applet impersonates another application, or even the Java Card RE, in order to gain
illegal access to some resources of the card or with respect to the end user or the
terminal. See #.SID for details.
Directly threatened asset(s): D.SEC_DATA (other assets may be jeopardized should this
attack succeed, for instance, if the identity of the JCRE is usurped), D.PIN and
D.APP_KEYs.
T.SID.2
The attacker modifies the TOE's attribution of a privileged role (e.g. default applet and
currently selected applet), which allows illegal impersonation of this role. See #.SID for
further details.
Directly threatened asset(s): D.SEC_DATA (any other asset may be jeopardized should
this attack succeed, depending on whose identity was forged).
6.2.1.4 UNAUTHORIZED EXECUTION
T.EXE-CODE.1
An applet performs an unauthorized execution of a method. See #.EXE-JCS-CODE and
#.EXE-APPLI-CODE for details.
Directly threatened asset(s): D.APP_CODE.
T.EXE-CODE.2
An applet performs an execution of a method fragment or arbitrary data. See #.EXE-JCS-
CODE and #.EXE-APPLI-CODE for details.
Directly threatened asset(s): D.APP_CODE.
T.NATIVE
An applet executes a native method to bypass a TOE Security Function such as the
firewall. See #.NATIVE for details.
Directly threatened asset(s): D.JCS_DATA.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 40/130
6.2.1.5 DENIAL OF SERVICE
T.RESOURCES
An attacker prevents correct operation of the Java Card System through consumption of
some resources of the card: RAM or NVRAM. See #.RESOURCES for details.
Directly threatened asset(s): D.JCS_DATA.
6.2.1.6 CARD MANAGEMENT
T.DELETION
The attacker deletes an applet or a package already in use on the card, or uses the
deletion functions to pave the way for further attacks (putting the TOE in an insecure
state). See #.DELETION for details).
Directly threatened asset(s): D.SEC_DATA and D.APP_CODE.
T.INSTALL
The attacker fraudulently installs post-issuance of an applet on the card. This concerns
either the installation of an unverified applet or an attempt to induce a malfunction in the
TOE through the installation process. See #.INSTALL for details.
Directly threatened asset(s): D.SEC_DATA (any other asset may be jeopardized should
this attack succeed, depending on the virulence of the installed application).
6.2.1.7 SERVICES
T.OBJ-DELETION
The attacker keeps a reference to a garbage collected object in order to force the TOE to
execute an unavailable method, to make it to crash, or to gain access to a memory
containing data that is now being used by another application. See #.OBJ-DELETION for
further details.
Directly threatened asset(s): D.APP_C_DATA, D.APP_I_DATA and D.APP_KEYs.
6.2.2 Card Management
T.PHYSICAL
The attacker discloses or modifies the design of the TOE, its sensitive data or application
code by physical (opposed to logical) tampering means. This threat includes IC failure
analysis, electrical probing, unexpected tearing, and DPA. That also includes the
modification of the runtime execution of Java Card System or SCP software through
alteration of the intended execution order of (set of) instructions through physical
tampering techniques.
This threatens all the identified assets.
This threat refers to the point (7) of the security aspect #.SCP, and all aspects related to
confidentiality and integrity of code and data.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 41/130
T.APP_DATA_INTEGRITY
The attacker through a malicious applet loaded on the card modifies application data,
application keys or authentication data. Directly threatened asset(s): D.ISD_KEYS,
D.API_DATA and D.APP_KEYs.
T.UNAUTH_CARD_MNGT
The attacker performs unauthorized card management operations (for instance
impersonates one of the actor represented on the card) in order to take benefit of the
privileges or services granted to this actor on the card such as fraudulent:
o load of a package file;
o installation of a package file;
o extradition of a package file or an applet;
o personalization of an applet or a Security Domain;
o deletion of a package file or an applet;
o privileges update of an applet or a Security Domain.
Directly threatened asset(s): D.ISD_KEYS, D.APP_KEYs, D.APP_C_DATA, D.APP_I_DATA
and D.APP_CODE.
T.LIFE_CYCLE
An attacker accesses to an application outside of its expected availability range thus
violating irreversible life cycle phases of the application (for instance, an attacker re-
personalizes the application). Directly threatened asset(s): D.APP_I_DATA and
D.APP_C_DATA.
T.UNAUTH_ACCESS
By using the shareable object mechanism on which relies the communication between
two applets, the attacker uses an applet on card to get access or to modify data from
another applet that he should not have access to. Directly threatened asset(s): all.
6.3 Organisational Security Policies
This section describes the security policies of the TOE. The OSP from [ST_IC] must also be
considered:
P.Process-TOE Protection during TOE Development and Production
P.Add-Functions_HW Hardware Additional Specific Security Functionality
6.3.1 Java Card System Protection Profile - Open Configuration
This section describes the organizational security policies to be enforced with respect to the
TOE environment.
OSP.VERIFICATION
This policy shall ensure the consistency between the export files used in the verification
and those used for installing the verified file. The policy must also ensure that no
modification of the file is performed in between its verification and the signing by the
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 42/130
verification authority. See #.VERIFICATION for details. If the application development
guidance provided by the platform developer contains recommandations related to the
isolation property of the platform, this policy shall also ensure that the verification
authority checks that these recommandations are applied in the application code.
6.3.2 TOE
OSP.SECURITY_DOMAINS
Security domains can be dynamically created, deleted and blocked during usage phase in
post-issuance mode.
OSP.QUOTAS
Security domains are subject to quotas of memory at creation.
OSP.KEY_GENERATION
The personalizer must enforce a policy ensuring that generated keys cannot be accessed
in plaintext.
Application Note:
This can be applied by encrypting the generated key just after its generation with the
public key of the recipient.
OSP.SHARE-CONTROL
The Shareable interface functionality should be strictly controlled for all applications to
prevent transitive data flows between applets (i.e., no resharing of a shareable object
with a third applet) and thus prevent access to unauthorized data.
6.4 Assumptions
6.4.1 Java Card System Protection Profile - Open Configuration
This section introduces the assumptions made on the environment of the TOE.
A.APPLET
Applets loaded post-issuance do not contain native methods. The Java Card specification
explicitly "does not include support for native methods" ([JCVM], §3.3) outside the API.
A.VERIFICATION
All the bytecodes are verified at least once, before the loading, before the installation or
before the execution, depending on the card capabilities, in order to ensure that each
bytecode is valid at execution time.
6.4.2 TOE
A.PRODUCTION
Production and personalization environment if the TOE delivery occurs before step 6 of
the TOE life cycle must be trusted and secure.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 43/130
7 Security Objectives
7.1 Security Objectives for the TOE
This section describes the security objectives for the TOE. The security objectives described
are those from the IDeal Citiz v2.1.2 open platform, but the security objectives for the TOE
from [ST_IC], see table below, must be also considered.
Security Objectives Description
O.Phys-Manipulation Protection against Physical Manipulation
O.Phys-Probing Protection against Physical Probing
O.Malfunction Protection against Malfunction
O.Leak-Inherent Protection against Inherent Information Leakage
O.Leak-Forced Protection against Forced Information Leakage
O.Abuse-Func Protection against Abuse of Functionality
O.Identification TOE Identification
O.RND Random Numbers
O.Add-Functions_HW Hardware Additional Specific Security Functionality
O.Mem-Access Area based Memory Access Control
7.1.1 Java Card System Protection Profile - Open Configuration
This section defines the security objectives to be achieved by the TOE.
7.1.1.1 IDENTIFICATION
O.SID
The TOE shall uniquely identify every subject (applet, or package) before granting it
access to any service.
7.1.1.2 EXECUTION
O.FIREWALL
The TOE shall ensure controlled sharing of data containers owned by applets of different
packages or the JCRE and between applets and the TSFs. See #.FIREWALL for details.
O.GLOBAL_ARRAYS_CONFID
The TOE shall ensure that the APDU buffer that is shared by all applications is always
cleaned upon applet selection.
The TOE shall ensure that the global byte array used for the invocation of the install
method of the selected applet is always cleaned after the return from the install method.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 44/130
O.GLOBAL_ARRAYS_INTEG
The TOE shall ensure that only the currently selected applications may have a write
access to the APDU buffer and the global byte array used for the invocation of the install
method of the selected applet.
O.NATIVE
The only means that the Java Card VM shall provide for an application to execute native
code is the invocation of a method of the Java Card API, or any additional API. See
#.NATIVE for details.
O.OPERATE
The TOE must ensure continued correct operation of its security functions. See
#.OPERATE for details.
O.REALLOCATION
The TOE shall ensure that the re-allocation of a memory block for the runtime areas of
the Java Card VM does not disclose any information that was previously stored in that
block.
O.RESOURCES
The TOE shall control the availability of resources for the applications. See #.RESOURCES
for details.
7.1.1.3 SERVICES
O.ALARM
The TOE shall provide appropriate feedback information upon detection of a potential
security violation. See #.ALARM for details.
O.CIPHER
The TOE shall provide a means to cipher sensitive data for applications in a secure way.
In particular, the TOE must support cryptographic algorithms consistent with
cryptographic usage policies and standards. See #.CIPHER for details.
O.KEY-MNGT
The TOE shall provide a means to securely manage cryptographic keys. This concerns the
correct generation, distribution, access and destruction of cryptographic keys. See #.KEY-
MNGT.
O.PIN-MNGT
The TOE shall provide a means to securely manage PIN objects. See #.PIN-MNGT for
details.
O.BIO-MNGT
The TOE shall provide a means to securely manage biometric templates. This concerns
the optional package javacardx.biometry of the Java Card platform.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 45/130
O.TRANSACTION
The TOE must provide a means to execute a set of operations atomically. See
#.TRANSACTION for details.
O.KEY-MNGT, O.PIN-MNGT, O.BIO-MNGT, O.TRANSACTION and O.CIPHER are actually
provided to applets in the form of Java Card APIs. Vendor-specific libraries can also be
present on the card and made available to applets; those may be built on top of the Java
Card API or independently. These proprietary libraries will be evaluated together with the
TOE.
7.1.1.4 OBJECT DELETION
O.OBJ-DELETION
The TOE shall ensure the object deletion shall not break references to objects. See
#.OBJ-DELETION for further details.
7.1.1.5 APPLET MANAGEMENT
O.DELETION
The TOE shall ensure that both applet and package deletion perform as expected. See
#.DELETION for details.
O.LOAD
The TOE shall ensure that the loading of a package into the card is safe.
Besides, for code loaded post-issuance, the TOE shall verify the integrity and authenticity
evidences generated during the verification of the application package by the verification
authority. This verification by the TOE shall occur during the loading or later during the
install process.
O.INSTALL
The TOE shall ensure that the installation of an applet performs as expected (See
#.INSTALL for details). Besides, for code loaded post-issuance, the TOE shall verify the
integrity and authenticity evidences generated during the verification of the application
package by the verification authority. If not performed during the loading process, this
verification by the TOE shall occur during the install process.
7.1.1.6 OPEN CONFIGURATION
O.SCP.IC
The SCP shall provide all IC security features against physical attacks.
This security objective for the environment refers to the point (7) of the security aspect
#.SCP:
o It is required that the IC is designed in accordance with a well-defined set of
policies and Standards (likely specified in another protection profile), and will be
tamper resistant to actually prevent an attacker from extracting or altering security
data (like cryptographic keys) by using commonly employed techniques (physical
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 46/130
probing and sophisticated analysis of the chip). This especially matters to the
management (storage and operation) of cryptographic keys.
O.SCP.RECOVERY
If there is a loss of power, or if the smart card is withdrawn from the CAD while an
operation is in progress, the SCP must allow the TOE to eventually complete the
interrupted operation successfully, or recover to a consistent and secure state.
This security objective refers to the security aspect #.SCP(1):
o The smart card platform must be secure with respect to the SFRs. Then after a
power loss or sudden card removal prior to completion of some communication
protocol, the SCP will allow the TOE on the next power up to either complete the
interrupted operation or revert to a secure state.
O.SCP.SUPPORT
The SCP shall support the TSFs of the TOE.
This security objective refers to the security aspects 2, 3, 4 and 5 of #.SCP:
(2) It does not allow the TSFs to be bypassed or altered and does not allow access to
other low-level functions than those made available by the packages of the API. That
includes the protection of its private data and code (against disclosure or modification)
from the Java Card System.
(3) It provides secure low-level cryptographic processing to the Java Card System.
(4) It supports the needs for any update to a single persistent object or class field to be
atomic, and possibly a low-level transaction mechanism.
(5) It allows the Java Card System to store data in "persistent technology memory" or in
volatile memory, depending on its needs (for instance, transient objects must not be
stored in non-volatile memory). The memory model is structured and allows for low-level
control accesses (segmentation fault detection).
7.1.1.7 CARD MANAGEMENT
O.CARD-MANAGEMENT
The card manager shall control the access to card management functions such as the
installation, update or deletion of applets. It shall also implement the card issuer's policy
on the card.
The card manager is an application with specific rights, which is responsible for the
administration of the smart card. This component will in practice be tightly connected with
the TOE, which in turn shall very likely rely on the card manager for the effective
enforcing of some of its security functions. Typically the card manager shall be in charge
of the life cycle of the whole card, as well as that of the installed applications (applets).
The card manager should prevent that card content management (loading, installation,
deletion) is carried out, for instance, at invalid states of the card or by non-authorized
actors. It shall also enforce security policies established by the card issuer.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 47/130
7.2 Security Objectives for the Operational Environment
7.2.1 Java Card System Protection Profile - Open Configuration
This section introduces the security objectives to be achieved by the environment.
OE.APPLET
No applet loaded post-issuance shall contain native methods.
OE.VERIFICATION
All the bytecodes shall be verified at least once, before the loading, before the installation
or before the execution, depending on the card capabilities, in order to ensure that each
bytecode is valid at execution time. See #.VERIFICATION for details.
OE.CODE-EVIDENCE
For application code loaded pre-issuance, evaluated technical measures implemented by
the TOE or audited organizational measures must ensure that loaded application has not
been changed since the code verifications required in OE.VERIFICATION. For application
code loaded post-issuance and verified off-card according to the requirements of
OE.VERIFICATION, the verification authority shall provide digital evidence to the TOE that
the application code has not been modified after the code verification and that he is the
actor who performed code verification. For application code loaded post-issuance and
partially or entirely verified on-card, technical measures must ensure that the verification
required in OE.VERIFICATION are performed. On-card bytecode verifier is out of the
scope of the used Protection Profile.
7.2.2 TOE
This section introduces the security objectives to be achieved by the environment associated
to the TOE. The significant security objectives for the environment of the TOE are the ones
linked to relevant assumptions and OSPs.
OE.SECURITY-DOMAINS
Security domains can be dynamically created, deleted and blocked during usage phase in
post-issuance mode.
OE.QUOTAS
Security domains are subject to quotas of memory at creation.
OE.SHARE-CONTROL
All applications (basic and secure applications) must have means to identify the
applications with whom they share data using the Shareable Interface.
OE.KEY_GENERATION
The personalizer must ensure that the generated keys cannot be accessed by
unauthorized users.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 48/130
OE.PRODUCTION
Production and personalization environment if the TOE delivery occurs before step 6 of
the TOE life cycle must be trusted and secure. In particular, within the environments the
corresponding guidance documents have to be taken into account.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 49/130
7.3 Security Objectives Rationale
7.3.1 Threats
7.3.1.1 Java Card System Protection Profile - Open Configuration
CONFIDENTIALITY
T.CONFID-APPLI-DATA This threat is countered by the security objective for the
operational environment regarding bytecode verification (OE.VERIFICATION). It is also
covered by the isolation commitments stated in the (O.FIREWALL) objective. It relies in its
turn on the correct identification of applets stated in (O.SID). Moreover, as the firewall is
dynamically enforced, it shall never stop operating, as stated in the (O.OPERATE)
objective. As the firewall is a software tool automating critical controls, the objective
O.ALARM asks for it to provide clear warning and error messages, so that the appropriate
counter-measure can be taken. The objectives O.CARD-MANAGEMENT and
OE.VERIFICATION contribute to cover this threat by controlling the access to card
management functions and by checking the bytecode, respectively. The objectives
O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the O.OPERATE and
O.ALARM objectives of the TOE, so they are indirectly related to the threats that these
latter objectives contribute to counter. As applets may need to share some data or
communicate with the CAD, cryptographic functions are required to actually protect the
exchanged information (O.CIPHER). Remark that even if the TOE shall provide access to
the appropriate TSFs, it is still the responsibility of the applets to use them. Keys,
Biometry, PIN's are particular cases of an application's sensitive data (the Java Card
System may possess keys as well) that ask for appropriate management (O.KEY-MNGT,
O.PIN-MNGT, O.BIO-MNGT, O.TRANSACTION). If the PIN class of the Java Card API is
used, the objective (O.FIREWALL) shall contribute in covering this threat by controlling
the sharing of the global PIN between the applets. Other application data that is sent to
the applet as clear text arrives to the APDU buffer, which is a resource shared by all
applications. The disclosure of such data is prevented by the security objective
O.GLOBAL_ARRAYS_CONFID. Finally, any attempt to read a piece of information that was
previously used by an application but has been logically deleted is countered by the
O.REALLOCATION objective. That objective states that any information that was formerly
stored in a memory block shall be cleared before the block is reused.
T.CONFID-JCS-CODE This threat is countered by the list of properties described in the
(#.VERIFICATION) security aspect. Bytecode verification ensures that each of the
instructions used on the Java Card platform is used for its intended purpose and in the
intended scope of accessibility. As none of those instructions enables reading a piece of
code, no Java Card applet can therefore be executed to disclose a piece of code. Native
applications are also harmless because of the objective O.NATIVE, so no application can
be run to disclose a piece of code.
The (#.VERIFICATION) security aspect is addressed in this ST by the objective for the
environment OE.VERIFICATION.
The objectives O.CARD-MANAGEMENT and OE.VERIFICATION contribute to cover this
threat by controlling the access to card management functions and by checking the
bytecode, respectively.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 50/130
T.CONFID-JCS-DATA This threat is covered by bytecode verification (OE.VERIFICATION)
and the isolation commitments stated in the (O.FIREWALL) security objective. This latter
objective also relies in its turn on the correct identification of applets stated in (O.SID).
Moreover, as the firewall is dynamically enforced, it shall never stop operating, as stated
in the (O.OPERATE) objective.
As the firewall is a software tool automating critical controls, the objective O.ALARM asks
for it to provide clear warning and error messages, so that the appropriate counter-
measure can be taken.
The objectives O.CARD-MANAGEMENT and OE.VERIFICATION contribute to cover this
threat by controlling the access to card management functions and by checking the
bytecode, respectively.
The objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the
O.OPERATE and O.ALARM objectives of the TOE, so they are indirectly related to the
threats that these latter objectives contribute to counter.
INTEGRITY
T.INTEG-APPLI-CODE This threat is countered by the list of properties described in the
(#.VERIFICATION) security aspect. Bytecode verification ensures that each of the
instructions used on the Java Card platform is used for its intended purpose and in the
intended scope of accessibility. As none of these instructions enables modifying a piece of
code, no Java Card applet can therefore be executed to modify a piece of code. Native
applications are also harmless because of the objective O.NATIVE, so no application can
run to modify a piece of code.
The (#.VERIFICATION) security aspect is addressed in this configuration by the objective
for the environment OE.VERIFICATION.
The objectives O.CARD-MANAGEMENT and OE.VERIFICATION contribute to cover this
threat by controlling the access to card management functions and by checking the
bytecode, respectively.
The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that
integrity and authenticity evidences exist for the application code loaded into the
platform.
T.INTEG-APPLI-CODE.LOAD This threat is countered by the security objective O.LOAD
which ensures that the loading of packages is done securely and thus preserves the
integrity of packages code.
The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that the
application code loaded into the platform has not been changed after code verification,
which ensures code integrity and authenticity. By controlling the access to card
management functions such as the installation, update or deletion of applets the objective
O.CARD-MANAGEMENT contributes to cover this threat.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 51/130
T.INTEG-APPLI-DATA This threat is countered by bytecode verification
(OE.VERIFICATION) and the isolation commitments stated in the (O.FIREWALL) objective.
This latter objective also relies in its turn on the correct identification of applets stated in
(O.SID). Moreover, as the firewall is dynamically enforced, it shall never stop operating,
as stated in the (O.OPERATE) objective.
As the firewall is a software tool automating critical controls, the objective O.ALARM asks
for it to provide clear warning and error messages, so that the appropriate counter-
measure can be taken.
The objectives O.CARD-MANAGEMENT and OE.VERIFICATION contribute to cover this
threat by controlling the access to card management functions and by checking the
bytecode, respectively.
The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that the
application code loaded into the platform has not been changed after code verification,
which ensures code integrity and authenticity.
The objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the
O.OPERATE and O.ALARM objectives of the TOE, so they are indirectly related to the
threats that these latter objectives contribute to counter.
Concerning the confidentiality and integrity of application sensitive data, as applets may
need to share some data or communicate with the CAD, cryptographic functions are
required to actually protect the exchanged information (O.CIPHER). Remark that even if
the TOE shall provide access to the appropriate TSFs, it is still the responsibility of the
applets to use them. Keys, Biometry and PIN's are particular cases of an application's
sensitive data (the Java Card System may possess keys as well) that ask for appropriate
management (O.KEY-MNGT, O.PIN-MNGT, O.BIO-MNGT, O.TRANSACTION). If the PIN
class of the Java Card API is used, the objective (O.FIREWALL) is also concerned.
Other application data that is sent to the applet as clear text arrives to the APDU buffer,
which is a resource shared by all applications. The integrity of the information stored in
that buffer is ensured by the objective O.GLOBAL_ARRAYS_INTEG.
Finally, any attempt to read a piece of information that was previously used by an
application but has been logically deleted is countered by the O.REALLOCATION objective.
That objective states that any information that was formerly stored in a memory block
shall be cleared before the block is reused.
T.INTEG-APPLI-DATA.LOAD This threat is countered by the security objective O.LOAD
which ensures that the loading of packages is done securely and thus preserves the
integrity of applications data.
The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that the
application code loaded into the platform has not been changed after code verification,
which ensures code integrity and authenticity. By controlling the access to card
management functions such as the installation, update or deletion of applets the objective
O.CARD-MANAGEMENT contributes to cover this threat.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 52/130
T.INTEG-JCS-CODE This threat is countered by the list of properties described in the
(#.VERIFICATION) security aspect. Bytecode verification ensures that each of the
instructions used on the Java Card platform is used for its intended purpose and in the
intended scope of accessibility. As none of these instructions enables modifying a piece of
code, no Java Card applet can therefore be executed to modify a piece of code. Native
applications are also harmless because of the objective O.NATIVE, so no application can
be run to modify a piece of code.
The (#.VERIFICATION) security aspect is addressed in this configuration by the objective
for the environment OE.VERIFICATION.
The objectives O.CARD-MANAGEMENT and OE.VERIFICATION contribute to cover this
threat by controlling the access to card management functions and by checking the
bytecode, respectively.
The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that the
application code loaded into the platform has not been changed after code verification,
which ensures code integrity and authenticity.
T.INTEG-JCS-DATA This threat is countered by bytecode verification (OE.VERIFICATION)
and the isolation commitments stated in the (O.FIREWALL) objective. This latter objective
also relies in its turn on the correct identification of applets stated in (O.SID). Moreover,
as the firewall is dynamically enforced, it shall never stop operating, as stated in the
(O.OPERATE) objective.
As the firewall is a software tool automating critical controls, the objective O.ALARM asks
for it to provide clear warning and error messages, so that the appropriate counter-
measure can be taken.
The objectives O.CARD-MANAGEMENT and OE.VERIFICATION contribute to cover this
threat by controlling the access to card management functions and by checking the
bytecode, respectively.
The objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the
O.OPERATE and O.ALARM objectives of the TOE, so they are indirectly related to the
threats that these latter objectives contribute to counter.
IDENTITY USURPATION
T.SID.1 As impersonation is usually the result of successfully disclosing and modifying some
assets, this threat is mainly countered by the objectives concerning the isolation of
application data (like PINs), ensured by the (O.FIREWALL). Uniqueness of subject-identity
(O.SID) also participates to face this threat. It should be noticed that the AIDs, which are
used for applet identification, are TSF data.
In this configuration, usurpation of identity resulting from a malicious installation of an
applet on the card is covered by the objective O.INSTALL.
The installation parameters of an applet (like its name) are loaded into a global array that
is also shared by all the applications. The disclosure of those parameters (which could be
used to impersonate the applet) is countered by the objectives
O.GLOBAL_ARRAYS_CONFID and O.GLOBAL_ARRAYS_INTEG.
The objective O.CARD-MANAGEMENT contributes, by preventing usurpation of identity
resulting from a malicious installation of an applet on the card, to counter this threat.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 53/130
T.SID.2 This is covered by integrity of TSF data, subject-identification (O.SID), the firewall
(O.FIREWALL) and its good working order (O.OPERATE).
The objective O.INSTALL contributes to counter this threat by ensuring that installing an
applet has no effect on the state of other applets and thus can't change the TOE's
attribution of privileged roles.
The objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the
O.OPERATE objective of the TOE, so they are indirectly related to the threats that this
latter objective contributes to counter.
UNAUTHORIZED EXECUTION
T.EXE-CODE.1 Unauthorized execution of a method is prevented by the objective
OE.VERIFICATION. This threat particularly concerns the security aspect #VERIFICATION
(access modifiers and scope of accessibility for classes, fields and methods). The
O.FIREWALL objective is also concerned, because it prevents the execution of non-
shareable methods of a class instance by any subject apart from the class instance owner.
T.EXE-CODE.2 Unauthorized execution of a method fragment or arbitrary data is prevented
by the objective OE.VERIFICATION. This threat particularly concerns those points of the
security aspect related to control flow confinement and the validity of the method
references used in the bytecodes.
T.NATIVE This threat is countered by O.NATIVE which ensures that a Java Card applet can
only access native methods indirectly that is, through an API. OE.APPLET also covers this
threat by ensuring that no native applets shall be loaded in post-issuance. In addition to
this, the bytecode verifier also prevents the program counter of an applet to jump into a
piece of native code by confining the control flow to the currently executed method
(OE.VERIFICATION).
DENIAL OF SERVICE
T.RESOURCES This threat is directly countered by objectives on resource-management
(O.RESOURCES) for runtime purposes and good working order (O.OPERATE) in a general
manner.
Consumption of resources during installation and other card management operations are
covered, in case of failure, by O.INSTALL.
It should be noticed that, for what relates to CPU usage, the Java Card platform is single-
threaded and it is possible for an ill-formed application (either native or not) to
monopolize the CPU. However, a smart card can be physically interrupted (card removal
or hardware reset) and most CADs implement a timeout policy that prevent them from
being blocked should a card fails to answer. That point is out of scope of this Protection
Profile, though.
Finally, the objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the
O.OPERATE and O.RESOURCES objectives of the TOE, so they are indirectly related to the
threats that these latter objectives contribute to counter.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 54/130
CARD MANAGEMENT
T.DELETION This threat is covered by the O.DELETION security objective which ensures
that both applet and package deletion perform as expected.
The objective O.CARD-MANAGEMENT controls the access to card management functions
and thus contributes to cover this threat.
T.INSTALL This threat is covered by the security objective O.INSTALL which ensures that
the installation of an applet performs as expected and the security objectives O.LOAD
which ensures that the loading of a package into the card is safe.
The objective O.CARD-MANAGEMENT controls the access to card management functions
and thus contributes to cover this threat.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 55/130
SERVICES
T.OBJ-DELETION This threat is covered by the O.OBJ-DELETION security objective which
ensures that object deletion shall not break references to objects.
7.3.1.2 Card Management
T.PHYSICAL Covered by O.SCP.IC. Physical protections rely on the underlying platform.
T.APP_DATA_INTEGRITY The security objective O.SCP.SUPPORT provides functionality to
ensure atomicity of sensitive operations, secure low level access control and protection
against bypassing of the security features of the TOE. In particular, it explicitly ensures
the independent protection in integrity of the platform data. The security objectives
covering the threat T.INTEG-APPLI-DATA also cover this threat.
T.UNAUTH_CARD_MNGT This threat is covered by the security objective O.CARD-
MANAGEMENT that controls the access to card management functions such as the
loading, installation, extradition or deletion of applets.
T.LIFE_CYCLE This threat is covered by the security objectives O.CARD-MANAGEMENT that
controls the access to card management functions such as the loading, installation,
extradition or deletion of applets and prevent attacks intended to modify or exploit the
current life cycle of applications.
T.UNAUTH_ACCESS This threat is covered by the security objective on the operational
environment of the TOE OE.SHARE-CONTROL which ensures that sharing objects
functionality is strictly controlled to stop data transitive flows between applets and thus
stop access to unauthorized data.
7.3.2 Organisational Security Policies
7.3.2.1 Java Card System Protection Profile - Open Configuration
OSP.VERIFICATION This policy is upheld by the security objective of the environment
OE.VERIFICATION which guarantees that all the bytecodes shall be verified at least once,
before the loading, before the installation or before the execution in order to ensure that
each bytecode is valid at execution time. This policy is also upheld by the security
objective of the environment OE.CODE-EVIDENCE which ensures that evidences exist that
the application code has been verified and not changed after verification.
7.3.2.2 TOE
OSP.SECURITY_DOMAINS This OSP is enforced by the security objective for the
operational environment of the TOE OE.SECURITY-DOMAINS.
OSP.QUOTAS This OSP is enforced by the security objective for the operational
environment of the TOE OE.QUOTAS.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 56/130
OSP.KEY_GENERATION This OSP is directly enforced by the security objective for the
operational environment of the TOE OE.KEY_GENERATION.
OSP.SHARE-CONTROL This OSP is directly enforced by the security objective for the
operational environment of the TOE OE.SHARE-CONTROL.
7.3.3 Assumptions
7.3.3.1 Java Card System Protection Profile - Open Configuration
A.APPLET This assumption is upheld by the security objective for the operational
environment OE.APPLET which ensures that no applet loaded post-issuance shall contain
native methods.
A.VERIFICATION This assumption is upheld by the security objective on the operational
environment OE.VERIFICATION which guarantees that all the bytecodes shall be verified
at least once, before the loading, before the installation or before the execution in order
to ensure that each bytecode is valid at execution time.
This assumption is also upheld by the security objective of the environment OE.CODE-
EVIDENCE which ensures that evidences exist that the application code has been verified
and not changed after verification.
7.3.3.2 TOE
A.PRODUCTION This assumption is directly upheld by OE.PRODUCTION.
7.3.4 SPD and Security Objectives
Threats Security Objectives Rationale
T.CONFID-APPLI-DATA O.SCP.RECOVERY, O.SCP.SUPPORT,
OE.VERIFICATION, O.SID, O.OPERATE,
O.FIREWALL, O.GLOBAL_ARRAYS_CONFID,
O.ALARM, O.TRANSACTION, O.CIPHER, O.PIN-
MNGT, O.KEY-MNGT, O.REALLOCATION,
O.CARD-MANAGEMENT, O.BIO-MNGT
Section 7.3.1
T.CONFID-JCS-CODE OE.VERIFICATION, O.NATIVE, O.CARD-
MANAGEMENT
Section 7.3.1
T.CONFID-JCS-DATA O.SCP.RECOVERY, O.SCP.SUPPORT,
OE.VERIFICATION, O.SID, O.OPERATE,
O.FIREWALL, O.ALARM, O.CARD-MANAGEMENT
Section 7.3.1
T.INTEG-APPLI-CODE OE.VERIFICATION, O.NATIVE, O.CARD-
MANAGEMENT, OE.CODE-EVIDENCE
Section 7.3.1
T.INTEG-APPLI-
CODE.LOAD
O.LOAD, O.CARD-MANAGEMENT, OE.CODE-
EVIDENCE
Section 7.3.1
T.INTEG-APPLI-DATA O.SCP.RECOVERY, O.SCP.SUPPORT,
OE.VERIFICATION, O.SID, O.OPERATE,
Section 7.3.1
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 57/130
O.FIREWALL, O.GLOBAL_ARRAYS_INTEG,
O.ALARM, O.TRANSACTION, O.CIPHER, O.PIN-
MNGT, O.KEY-MNGT, O.REALLOCATION,
O.CARD-MANAGEMENT, OE.CODE-EVIDENCE,
O.BIO-MNGT
T.INTEG-APPLI-
DATA.LOAD
O.LOAD, O.CARD-MANAGEMENT, OE.CODE-
EVIDENCE
Section 7.3.1
T.INTEG-JCS-CODE OE.VERIFICATION, O.NATIVE, O.CARD-
MANAGEMENT, OE.CODE-EVIDENCE
Section 7.3.1
T.INTEG-JCS-DATA O.SCP.RECOVERY, O.SCP.SUPPORT,
OE.VERIFICATION, O.SID, O.OPERATE,
O.FIREWALL, O.ALARM, O.CARD-MANAGEMENT
Section 7.3.1
T.SID.1 O.FIREWALL, O.GLOBAL_ARRAYS_CONFID,
O.GLOBAL_ARRAYS_INTEG, O.INSTALL, O.SID,
O.CARD-MANAGEMENT
Section 7.3.1
T.SID.2 O.SCP.RECOVERY, O.SCP.SUPPORT, O.SID,
O.OPERATE, O.FIREWALL, O.INSTALL
Section 7.3.1
T.EXE-CODE.1 OE.VERIFICATION, O.FIREWALL Section 7.3.1
T.EXE-CODE.2 OE.VERIFICATION Section 7.3.1
T.NATIVE OE.VERIFICATION, OE.APPLET, O.NATIVE Section 7.3.1
T.RESOURCES O.INSTALL, O.OPERATE, O.RESOURCES,
O.SCP.RECOVERY, O.SCP.SUPPORT
Section 7.3.1
T.DELETION O.DELETION, O.CARD-MANAGEMENT Section 7.3.1
T.INSTALL O.INSTALL, O.LOAD, O.CARD-MANAGEMENT Section 7.3.1
T.OBJ-DELETION O.OBJ-DELETION Section 7.3.1
T.PHYSICAL O.SCP.IC Section 7.3.1
T.APP_DATA_INTEGRITY O.SCP.SUPPORT Section 7.3.1
T.UNAUTH_CARD_MNGT O.CARD-MANAGEMENT Section 7.3.1
T.LIFE_CYCLE O.CARD-MANAGEMENT Section 7.3.1
T.UNAUTH_ACCESS OE.SHARE-CONTROL Section 7.3.1
Table 2 Threats and Security Objectives - Coverage
Security Objectives Threats Rationale
O.SID T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA,
T.INTEG-APPLI-DATA, T.INTEG-JCS-DATA,
T.SID.1, T.SID.2
O.FIREWALL T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA,
T.INTEG-APPLI-DATA, T.INTEG-JCS-DATA,
T.SID.1, T.SID.2, T.EXE-CODE.1
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 58/130
O.GLOBAL_ARRAYS_CONFID T.CONFID-APPLI-DATA, T.SID.1
O.GLOBAL_ARRAYS_INTEG T.INTEG-APPLI-DATA, T.SID.1
O.NATIVE T.CONFID-JCS-CODE, T.INTEG-APPLI-CODE,
T.INTEG-JCS-CODE, T.NATIVE
O.OPERATE T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA,
T.INTEG-APPLI-DATA, T.INTEG-JCS-DATA,
T.SID.2, T.RESOURCES
O.REALLOCATION T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA
O.RESOURCES T.RESOURCES
O.ALARM T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA,
T.INTEG-APPLI-DATA, T.INTEG-JCS-DATA
O.CIPHER T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA
O.KEY-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA
O.PIN-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA
O.BIO-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA
O.TRANSACTION T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA
O.OBJ-DELETION T.OBJ-DELETION
O.DELETION T.DELETION
O.LOAD T.INTEG-APPLI-CODE.LOAD, T.INTEG-APPLI-
DATA.LOAD, T.INSTALL
O.INSTALL T.SID.1, T.SID.2, T.RESOURCES, T.INSTALL
O.SCP.IC T.PHYSICAL
O.SCP.RECOVERY T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA,
T.INTEG-APPLI-DATA, T.INTEG-JCS-DATA,
T.SID.2, T.RESOURCES
O.SCP.SUPPORT T.APP_DATA_INTEGRITY, T.CONFID-APPLI-
DATA, T.CONFID-JCS-DATA, T.INTEG-APPLI-
DATA, T.INTEG-JCS-DATA, T.SID.2,
T.RESOURCES
O.CARD-MANAGEMENT T.UNAUTH_CARD_MNGT, T.LIFE_CYCLE,
T.CONFID-APPLI-DATA, T.CONFID-JCS-CODE,
T.CONFID-JCS-DATA, T.INTEG-APPLI-CODE,
T.INTEG-APPLI-CODE.LOAD, T.INTEG-APPLI-
DATA, T.INTEG-APPLI-DATA.LOAD, T.INTEG-
JCS-CODE, T.INTEG-JCS-DATA, T.SID.1,
T.DELETION, T.INSTALL
OE.APPLET T.NATIVE
OE.VERIFICATION T.CONFID-APPLI-DATA, T.CONFID-JCS-CODE,
T.CONFID-JCS-DATA, T.INTEG-APPLI-CODE,
T.INTEG-APPLI-DATA, T.INTEG-JCS-CODE,
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 59/130
T.INTEG-JCS-DATA, T.EXE-CODE.1, T.EXE-
CODE.2, T.NATIVE
OE.CODE-EVIDENCE T.INTEG-APPLI-CODE, T.INTEG-APPLI-
CODE.LOAD, T.INTEG-APPLI-DATA, T.INTEG-
APPLI-DATA.LOAD, T.INTEG-JCS-CODE
OE.SECURITY-DOMAINS
OE.QUOTAS
OE.SHARE-CONTROL T.UNAUTH_ACCESS
OE.KEY_GENERATION
OE.PRODUCTION
Table 3 Security Objectives and Threats - Coverage
Organisational Security Policies Security Objectives Rationale
OSP.VERIFICATION OE.VERIFICATION, OE.CODE-EVIDENCE Section 7.3.2
OSP.SECURITY_DOMAINS OE.SECURITY-DOMAINS Section 7.3.2
OSP.QUOTAS OE.QUOTAS Section 7.3.2
OSP.KEY_GENERATION OE.KEY_GENERATION Section 7.3.2
OSP.SHARE-CONTROL OE.SHARE-CONTROL Section 7.3.2
Table 4 OSPs and Security Objectives - Coverage
Security Objectives Organisational Security Policies Rationale
O.SID
O.FIREWALL
O.GLOBAL_ARRAYS_CONFID
O.GLOBAL_ARRAYS_INTEG
O.NATIVE
O.OPERATE
O.REALLOCATION
O.RESOURCES
O.ALARM
O.CIPHER
O.KEY-MNGT
O.PIN-MNGT
O.BIO-MNGT
O.TRANSACTION
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 60/130
O.OBJ-DELETION
O.DELETION
O.LOAD
O.INSTALL
O.SCP.IC
O.SCP.RECOVERY
O.SCP.SUPPORT
O.CARD-MANAGEMENT
OE.APPLET
OE.VERIFICATION OSP.VERIFICATION
OE.CODE-EVIDENCE OSP.VERIFICATION
OE.SECURITY-DOMAINS OSP.SECURITY_DOMAINS
OE.QUOTAS OSP.QUOTAS
OE.SHARE-CONTROL OSP.SHARE-CONTROL
OE.KEY_GENERATION OSP.KEY_GENERATION
OE.PRODUCTION
Table 5 Security Objectives and OSPs - Coverage
Assumptions Security Objectives for the Operational Environment Rationale
A.APPLET OE.APPLET Section 7.3.3
A.VERIFICATION OE.VERIFICATION, OE.CODE-EVIDENCE Section 7.3.3
A.PRODUCTION OE.PRODUCTION Section 7.3.3
Table 6 Assumptions and Security Objectives for the Operational Environment - Coverage
Security Objectives for the Operational Environment Assumptions Rationale
OE.APPLET A.APPLET
OE.VERIFICATION A.VERIFICATION
OE.CODE-EVIDENCE A.VERIFICATION
OE.SECURITY-DOMAINS
OE.QUOTAS
OE.SHARE-CONTROL
OE.KEY_GENERATION
OE.PRODUCTION A.PRODUCTION
Table 7 Security Objectives for the Operational Environment and Assumptions - Coverage
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 61/130
8 Security Requirements
8.1 Security Functional Requirements
8.1.1 TOE
This section introduces the security functional requirements of the TOE that is composed of
the open operating system IDeal Citiz v2.1.2 open platform and a chip SCR400L. The
following lists of SFRs are those from the security target [ST_IC] of the Infineon M7892 B11
chip. They must be considered for the composite TOE, but they are not repeated in it.
Details can be found on the security target [ST_IC].
 FRU_FLT.2 "Limited fault tolerance"
 FPT_FLS.1 "Failure with preservation of secure state"
 FMT_LIM.1 "Limited capabilities"
 FMT_LIM.2 "Limited availability"
 FAU_SAS.1 "Audit storage"
 FDP_SDC.1 "Stored data confidentiality"
 FDP_SDI.2 "Stored data integrity monitoring and action"
 FPT_PHP.3 "Resistance to physical attack"
 FDP_ITT.1 "Basic internal transfer protection"
 FPT_ITT.1 "Basic internal TSF data transfer protection"
 FDP_IFC.1 "Subset information flow control"
 FCS_RNG.1 "Cryptographic operation"
 FCS_COP.1/A "Cryptographic operation"
 FCS_COP.1/B "Cryptographic operation"
 FDP_ACC.1 "Subset access control"
 FDP_ACF.1 "Security attribute based access control"
 FMT_MSA.1 "Management of security attributes"
 FMT_MSA.3 "Static attribute initialisation"
The TOE does not provide the optional JCRMI functionality, therefore JCRMI related entities,
subject, object, information, operation and security attribute, of the Java Card Protection
Profile [PP_JC] are excluded from the ST (the corresponding SFRs also).
8.1.2 Java Card System Protection Profile - Open Configuration
This section states the security functional requirements for the Java Card System - Open
configuration. For readability and for compatibility with the original Java Card System
Protection Profile Collection - Standard 2.2 Configuration, requirements are arranged into
groups. All the groups defined in the table below apply to this Protection Profile.
Group Description
Core with Logical
Channels
The CoreG_LC contains the requirements concerning the runtime
environment of the Java Card System implementing logical channels.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 62/130
(CoreG_LC) This includes the firewall policy and the requirements related to the Java
Card API. Logical channels are a Java Card specification version 2.2
feature.
Installation
(InstG)
The InstG contains the security requirements concerning the installation
of post-issuance applications. It does not address card management
issues in the broad sense, but only those security aspects of the
installation procedure that are related to applet execution.
Applet deletion
(ADELG)
The ADELG contains the security requirements for erasing installed
applets from the card, a feature introduced in Java Card specification
version 2.2.
Object deletion
(ODELG)
The ODELG contains the security requirements for the object deletion
capability. This provides a safe memory recovering mechanism. This is a
Java Card specification version 2.2 feature.
Secure carrier
(CarG)
The CarG group contains minimal requirements for secure downloading
of applications on the card. This group contains the security
requirements for preventing, in those configurations that do not support
on-card static or dynamic bytecode verification, the installation of a
package that has not been bytecode verified, or that has been modified
after bytecode verification.
Subjects are active components of the TOE that (essentially) act on the behalf of users. The
users of the TOE include people or institutions (like the applet developer, the card issuer,
and the verification authority), hardware (like the CAD where the card is inserted or the
PCD) and software components (like the application packages installed on the card). Some of
the users may just be aliases for other users. For instance, the verification authority in
charge of the bytecode verification of the applications may be just an alias for the card
issuer.
Subjects (prefixed with an "S") are described in the following table:
Subject Description
S.ADEL The applet deletion manager which also acts on behalf of the card issuer. It
may be an applet ([JCRE], §11), but its role asks anyway for a specific
treatment from the security viewpoint. This subject is unique and is involved
in the ADEL security policy.
S.APPLET Any applet instance.
S.BCV The bytecode verifier (BCV), which acts on behalf of the verification
authority who is in charge of the bytecode verification of the packages. This
subject is involved in the PACKAGE LOADING security policy.
S.CAD The CAD represents the actor that requests, by issuing commands to the
card, for RMI services. It also plays the role of the off-card entity that
communicates with the S.INSTALLER.
S.INSTALLER The installer is the on-card entity which acts on behalf of the card issuer.
This subject is involved in the loading of packages and installation of
applets.
S.JCRE The runtime environment under which Java programs in a smart card are
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 63/130
executed.
S.JCVM The bytecode interpreter that enforces the firewall at runtime.
S.LOCAL Operand stack of a JCVM frame, or local variable of a JCVM frame containing
an object or an array of references.
S.MEMBER Any object's field, static field or array position.
S.PACKAGE A package is a namespace within the Java programming language that may
contain classes and interfaces, and in the context of Java Card technology, it
defines either a user library, or one or several applets.
S.CM Card Manager
Objects (prefixed with an "O") are described in the following table:
Object Description
O.APPLET Any installed applet, its code and data.
O.CARD_LC Card Manager Life Cycle State.
O.CODE_PKG The code of a package, including all linking information. On the Java Card
platform, a package is the installation unit.
O.JAVAOBJECT Java class instance or array. It should be noticed that KEYS, PIN, arrays
and applet instances are specific objects in the Java programming
language.
Information (prefixed with an "I") is described in the following table:
Information Description
I.APDU Any APDU sent to or from the card through the communication channel.
I.DATA JCVM Reference Data: objectref addresses of APDU buffer, JCRE-owned
instances of APDU class and byte array for install method.
Security attributes linked to these subjects, objects and information are described in the
following table with their values:
Security
attribute
Description/Value
Active Applets The set of the active applets' AIDs. An active applet is an applet that is
selected on at least one of the logical channels.
Applet Selection
Status
"Selected" or "Deselected".
Applet's version
number
The version number of an applet (package) indicated in the export file.
Applet
Privileges
Privileges of an applet.
CARD_LC State Life Cycle States: OP_READY, INITIALIZED, SECURED, CARD_LOCKED,
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 64/130
and TERMINATED.
Class Identifies the implementation class of the remote object.
Context Package AID or "Java Card RE".
Currently Active
Context
Package AID or "Java Card RE".
Dependent
package AID
Allows the retrieval of the Package AID and Applet's version number
([JCVM], §4.5.2).
ExportedInfo Boolean (indicates whether the remote object is exportable or not).
Identifier The Identifier of a remote object or method is a number that uniquely
identifies the remote object or method, respectively.
Key Value The value of key associated with Security Domains [GP_CS].
Key Version The version of key associated with Security Domains [GP_CS].
Key Identifier The indentifier of key associated with Security Domains [GP_CS].
LC Selection
Status
Multiselectable, Non-multiselectable or "None".
LifeTime CLEAR_ON_DESELECT or PERSISTENT (*).
Owner The Owner of an object is either the applet instance that created the
object or the package (library) where it has been defined (these latter
objects can only be arrays that initialize static fields of the package). The
owner of a remote object is the applet instance that created the object.
Package AID The AID of each package indicated in the export file.
Registered
Applets
The set of AID of the applet instances registered on the card.
Resident
Packages
The set of AIDs of the packages already loaded on the card.
Selected Applet
Context
Package AID or "None".
Sharing Standards, SIO, Java Card RE entry point or global array.
Static
References
Static fields of a package may contain references to objects. The Static
References attribute records those references.
(*) Transient objects of type CLEAR_ON_RESET behave like persistent objects in that they can be
accessed only when the Currently Active Context is the object's context.
Operations (prefixed with "OP") are described in the following table. Each operation has
parameters given between brackets, among which there is the "accessed object", the first
one, when applicable. Parameters may be seen as security attributes that are under the
control of the subject performing the operation.
Operation Description
OP.ARRAY_ACCESS(O.JAVAOBJECT, field) Read/Write an array component.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 65/130
OP.CREATE(Sharing, LifeTime) (*) Creation of an object (new or
makeTransient call).
OP.DELETE_APPLET(O.APPLET,...) Delete an installed applet and its objects,
either logically or physically.
OP.DELETE_PCKG(O.CODE_PKG,...) Delete a package, either logically or
physically.
OP.DELETE_PCKG_APPLET(O.CODE_PKG,...) Delete a package and its installed
applets, either logically or physically.
OP.INSTANCE_FIELD(O.JAVAOBJECT, field) Read/Write a field of an instance of a
class in the Java programming language.
OP.INVK_VIRTUAL(O.JAVAOBJECT, method,
arg1,...)
Invoke a virtual method (either on a class
instance or an array object).
OP.INVK_INTERFACE(O.JAVAOBJECT, method,
arg1,...)
Invoke an interface method.
OP.JAVA(...) Any access in the sense of [JCRE],
§6.2.8. It stands for one of the
operations OP.ARRAY_ACCESS,
OP.INSTANCE_FIELD, OP.INVK_VIRTUAL,
OP.INVK_INTERFACE, OP.THROW,
OP.TYPE_ACCESS.
OP.PUT(S1,S2,I) Transfer a piece of information I from S1
to S2.
OP.SET_CARD_STATE(…) (**) Set Card Life Cycle State.
OP.THROW(O.JAVAOBJECT) Throwing of an object (athrow, see
[JCRE], §6.2.8.7).
OP.TYPE_ACCESS(O.JAVAOBJECT, class) Invoke checkcast or instanceof on an
object in order to access to classes
(standard or shareable interfaces
objects).
(*) For this operation, there is no accessed object. This rule enforces that shareable transient objects
are not allowed. For instance, during the creation of an object, the JavaCardClass attribute's value is
chosen by the creator.
(**) This operation, not present in [PP JC] has been added for the Card Life Cycle Management
SFRs.
8.1.2.1 CoreG_LC Security Functional Requirements
This group is focused on the main security policy of the Java Card System, known as the
firewall.
Firewall Policy
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 66/130
FDP_ACC.2/FIREWALL Complete access control
FDP_ACC.2.1/FIREWALL The TSF shall enforce the FIREWALL access control SFP on
S.PACKAGE, S.JCRE, S.JCVM, O.JAVAOBJECT and all operations among subjects and
objects covered by the SFP.
Refinement:
The operations involved in the policy are:
o OP.CREATE,
o OP.INVK_INTERFACE,
o OP.INVK_VIRTUAL,
o OP.JAVA,
o OP.THROW,
o OP.TYPE_ACCESS.
FDP_ACC.2.2/FIREWALL The TSF shall ensure that all operations between any subject
controlled by the TSF and any object controlled by the TSF are covered by an access
control SFP.
FDP_ACF.1/FIREWALL Security attribute based access control
FDP_ACF.1.1/FIREWALL The TSF shall enforce the FIREWALL access control SFP to
objects based on the following:
Subject/Object Security attributes
S.PACKAGE LC Selection Status
S.JCVM Active Applets, Currently Active Context
S.JCRE Selected Applet Context
O.JAVAOBJECT Sharing, Context, LifeTime
.
FDP_ACF.1.2/FIREWALL The TSF shall enforce the following rules to determine if an
operation among controlled subjects and controlled objects is allowed:
o R.JAVA.1 ([JCRE], §6.2.8): S.PACKAGE may freely perform
OP.ARRAY_ACCESS, OP.INSTANCE_FIELD, OP.INVK_VIRTUAL,
OP.INVK_INTERFACE, OP.THROW or OP.TYPE_ACCESS upon any
O.JAVAOBJECT whose Sharing attribute has value "JCRE entry point" or
"global array".
o R.JAVA.2 ([JCRE], §6.2.8): S.PACKAGE may freely perform
OP.ARRAY_ACCESS, OP.INSTANCE_FIELD, OP.INVK_VIRTUAL,
OP.INVK_INTERFACE or OP.THROW upon any O.JAVAOBJECT whose
Sharing attribute has value "Standard" and whose Lifetime attribute has
value "PERSISTENT" only if O.JAVAOBJECT's Context attribute has the
same value as the active context.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 67/130
o R.JAVA.3 ([JCRE], §6.2.8.10): S.PACKAGE may perform
OP.TYPE_ACCESS upon an O.JAVAOBJECT whose Sharing attribute has
value "SIO" only if O.JAVAOBJECT is being cast into (checkcast) or is
being verified as being an instance of (instanceof) an interface that
extends the Shareable interface.
o R.JAVA.4 ([JCRE], §6.2.8.6): S.PACKAGE may perform
OP.INVK_INTERFACE upon an O.JAVAOBJECT whose Sharing attribute
has the value "SIO", and whose Context attribute has the value
"Package AID", only if the invoked interface method extends the
Shareable interface and one of the following conditions applies:
 a) The value of the attribute Selection Status of the package whose
AID is "Package AID" is "Multiselectable",
 b) The value of the attribute Selection Status of the package whose
AID is "Package AID" is "Non-multiselectable", and either "Package
AID" is the value of the currently selected applet or otherwise
"Package AID" does not occur in the attribute Active Applets.
o R.JAVA.5: S.PACKAGE may perform OP.CREATE only if the value of the
Sharing parameter is "Standard".
FDP_ACF.1.3/FIREWALL The TSF shall explicitly authorise access of subjects to objects
based on the following additional rules:
o 1) The subject S.JCRE can freely perform OP.JAVA(") and OP.CREATE,
with the exception given in FDP_ACF.1.4/FIREWALL, provided it is the
Currently Active Context.
o 2) The only means that the subject S.JCVM shall provide for an
application to execute native code is the invocation of a Java Card API
method (through OP.INVK_INTERFACE or OP.INVK_VIRTUAL).
FDP_ACF.1.4/FIREWALL The TSF shall explicitly deny access of subjects to objects based
on the following additional rules:
o 1) Any subject with OP.JAVA upon an O.JAVAOBJECT whose LifeTime
attribute has value "CLEAR_ON_DESELECT" if O.JAVAOBJECT's Context
attribute is not the same as the Selected Applet Context.
o 2) Any subject attempting to create an object by the means of
OP.CREATE and a "CLEAR_ON_DESELECT" LifeTime parameter if the
active context is not the same as the Selected Applet Context.
FDP_IFC.1/JCVM Subset information flow control
FDP_IFC.1.1/JCVM The TSF shall enforce the JCVM information flow control SFP on
S.JCVM, S.LOCAL, S.MEMBER, I.DATA and OP.PUT(S1, S2, I).
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 68/130
FDP_IFF.1/JCVM Simple security attributes
FDP_IFF.1.1/JCVM The TSF shall enforce the JCVM information flow control SFP
based on the following types of subject and information security attributes:
Subjects Security attributes
S.JCVM Currently Active Context
.
FDP_IFF.1.2/JCVM The TSF shall permit an information flow between a controlled subject
and controlled information via a controlled operation if the following rules hold:
o An operation OP.PUT(S1, S.MEMBER, I.DATA) is allowed if and only if
the Currently Active Context is "Java Card RE";
o other OP.PUT operations are allowed regardless of the Currently Active
Context's value.
FDP_IFF.1.3/JCVM The TSF shall enforce the following additional information flow
control SFP rules: none.
FDP_IFF.1.4/JCVM The TSF shall explicitly authorise an information flow based on the
following rules: none.
FDP_IFF.1.5/JCVM The TSF shall explicitly deny an information flow based on the
following rules: one of the conditions in the element FDP_IFF.1.2-JCVM above is
not satisfied.
FDP_RIP.1/OBJECTS Subset residual information protection
FDP_RIP.1.1/OBJECTS The TSF shall ensure that any previous information content of a
resource is made unavailable upon the allocation of the resource to the following
objects: class instances and arrays.
FMT_MSA.1/JCRE Management of security attributes
FMT_MSA.1.1/JCRE The TSF shall enforce the FIREWALL access control SFP to
restrict the ability to modify the security attributes Selected Applet Context to the
Java Card RE.
Remark The TOE is compliant with GlobalPlatform's specifications and includes
the GlobalPlatform Environment that provide an API to applications, command
dispatch, Card Content management and manages the installation of
applications to the card and loading of these latter. These functions are
available if not provided by the Java Card RE, or if provided but in a way not
complying with GlobalPlatform's specifications.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 69/130
FMT_MSA.1/JCVM Management of security attributes
FMT_MSA.1.1/JCVM The TSF shall enforce the FIREWALL access control SFP and the
JCVM information flow control SFP to restrict the ability to modify the security
attributes Currently Active Context and Active Applets to the Java Card VM
(S.JCVM).
FMT_MSA.2/FIREWALL_JCVM Secure security attributes
FMT_MSA.2.1/FIREWALL_JCVM The TSF shall ensure that only secure values are
accepted for all the security attributes of subjects and objects defined in the
FIREWALL access control SFP and the JCVM information flow control SFP.
FMT_MSA.3/FIREWALL Static attribute initialisation
FMT_MSA.3.1/FIREWALL The TSF shall enforce the FIREWALL access control SFP to
provide restrictive default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/FIREWALL [Editorially Refined] The TSF shall not allow any role to
specify alternative initial values to override the default values when an object or
information is created.
FMT_MSA.3/JCVM Static attribute initialisation
FMT_MSA.3.1/JCVM The TSF shall enforce the JCVM information flow control SFP to
provide restrictive default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/JCVM [Editorially Refined] The TSF shall not allow any role to specify
alternative initial values to override the default values when an object or information is
created.
FMT_SMF.1 Specification of Management Functions
FMT_SMF.1.1 The TSF shall be capable of performing the following management functions:
o modify the Currently Active Context, the Selected Applet Context and
the Active Applets.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 70/130
FMT_SMR.1 Security roles
FMT_SMR.1.1 The TSF shall maintain the roles:
o Java Card RE (JCRE),
o Java Card VM (JCVM).
FMT_SMR.1.2 The TSF shall be able to associate users with roles.
Application Programming Interface
The following SFRs are related to the Java Card API.
The whole set of cryptographic algorithms is generally not implemented because of limited
memory resources and/or limitations due to exportation. Therefore, the following
requirements only apply to the implemented subset.
It should be noticed that the execution of the additional native code is not within the TSF.
Nevertheless, access to API native methods from the Java Card System is controlled by TSF
because there is no difference between native and interpreted methods in their interface or
invocation mechanism.
FCS_CKM.1 Cryptographic key generation
FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified
cryptographic key generation algorithm see table below and specified cryptographic key
sizes see table below that meet the following: see table below
Iteration Algorithm Key Size Standard
RSA-CRT RSA-CRT key generation 768 to 1024 bits with a
step of 16 bits
Proprietary
algorithm
RSA-CRT RSA-CRT key generation 1040 to 3072 bits
(except 1120 and 2272
bits) with a step of 16
bits
[FIPS_186-4]
EC_FP Elliptic Curve Prime Field
Algorithm key generation
for ECDSA & ECDH
112, 128, 160, 192, 224,
256, 320, 384, 512, 521
bits
[IEEE1363],
[FIPS_186-4]
DH DH key generation 1024, 1536, 2048 [ANSI X9.42]
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 71/130
FCS_CKM.2 Cryptographic key distribution
FCS_CKM.2.1 The TSF shall distribute cryptographic keys in accordance with a specified
cryptographic key distribution method Diffie-Hellman key agreement based on
elliptic curve cryptography algorithm defined in [JCAPI]:
o ALG_EC_SVDP_DH
o ALG_EC_SVDP_DH_KDF
o ALG_EC_SVDP_DH_PLAIN
o ALG_EC_SVDP_DHC
o ALG_EC_SVDP_DHC_KDF
o ALG_EC_SVDP_DHC_PLAIN
that meets the following: [NIST_SP800-56A] and [IEEE1363].
FCS_CKM.3 Cryptographic key access
FCS_CKM.3.1 The TSF shall perform see table below in accordance with a specified
cryptographic key access method see table below that meets the following: see table
below
Iteration Key Access Method Standard
JCS key access using API of class Key [JCAPI]
.
FCS_CKM.4 Cryptographic key destruction
FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified
cryptographic key destruction method overwritting of data that meets the following:
none.
FCS_COP.1 Cryptographic operation
FCS_COP.1.1 The TSF shall perform see table below in accordance with a specified
cryptographic algorithm see table below and cryptographic key sizes see table below
that meet the following: see tables below
Asymetric encryption/decryption and signature/verification:
Iteration Operation Algorithm Key Size Standard
RSA-
CRT_SIG
user data
signature
generation and
verification
RSA CRT 768 to 3072
bits
[ISO/IEC9796]
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 72/130
RSA-
CRT_CPH
user data
encryption and
decryption
RSA CRT 768 to 3072
bits
[ISO/IEC9796]
ECDH key agreement ECDH 112, 128,
160, 192,
224, 256,
320, 384,
512, 521
[IEEE1363]
ECDSA user data
signature
generation and
verification
Elliptic Curve
Digital
Signature
Algorithm
112, 128,
160, 192,
224, 256,
320, 384,
512, 521
[FIPS_186-4],
[TR03111]
DH key exchange Diffie-Helmann 1024, 1536,
2048
[ANSI X9.42]
Symetric encryption/decryption:
Iteration Operation Algorithm Key Size Standard
TDES encryption and
decryption of application
instance's data
Triple DES ECB
or CBC mode
128, 192
bits
[SP800-67],
[FIPS_46-3]
AES encryption and
decryption of application
instance's data
AES ECB or CBC
mode
128,
192, 256
bits
[FIPS_197]
Hash:
Iteration Operation Algorithm Hash Size Standard
SHA user data hash
generation
Secure Hash
Algorithm
160, 224, 256,
384, 512 bits
[FIPS_180-
4]
MAC:
Iteration Operation Algorithm Key
Size
Standard
HMAC computation of
message
authentication code
based on hash
algorithm
Keyed-Hash
Message
Authentication
Code
160,
224,
256,
384,
512 bits
[FIPS_198-1]
CMAC computation of
message
authentication code
based on cipher
algorithm
Cipher-based
Message
Authentication
Code
128,
192,
256 bits
[NIST_SP800-
38B]
.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 73/130
FDP_RIP.1/ABORT Subset residual information protection
FDP_RIP.1.1/ABORT The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the resource from the
following objects: any reference to an object instance created during an aborted
transaction.
FDP_RIP.1/APDU Subset residual information protection
FDP_RIP.1.1/APDU The TSF shall ensure that any previous information content of a
resource is made unavailable upon the allocation of the resource to the following
objects: the APDU buffer.
FDP_RIP.1/bArray Subset residual information protection
FDP_RIP.1.1/bArray The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the resource from the
following objects: the bArray object.
FDP_RIP.1/KEYS Subset residual information protection
FDP_RIP.1.1/KEYS The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the resource from the
following objects: the cryptographic buffer (D.CRYPTO).
FDP_RIP.1/TRANSIENT Subset residual information protection
FDP_RIP.1.1/TRANSIENT The TSF shall ensure that any previous information content of
a resource is made unavailable upon the deallocation of the resource from the
following objects: any transient object.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 74/130
FDP_ROL.1/FIREWALL Basic rollback
FDP_ROL.1.1/FIREWALL The TSF shall enforce the FIREWALL access control SFP
and the JCVM information flow control SFP to permit the rollback of the
operations OP.JAVA and OP.CREATE on the object O.JAVAOBJECT.
FDP_ROL.1.2/FIREWALL The TSF shall permit operations to be rolled back within the
scope of a select(), deselect(), process(), install() or uninstall() call,
notwithstanding the restrictions given in [JCRE], §7.7, within the bounds of
the Commit Capacity ([JCRE], §7.8), and those described in [JCAPI].
Card Security Management
FAU_ARP.1 Security alarms
FAU_ARP.1.1 The TSF shall take one of the following actions:
o throw an exception,
o lock the card session,
o reinitialize the Java Card System and its data
o Increment an application error counter and mute the card. When the
application error counter reaches its maximum value, the application is
locked.
o Increment a card error counter and mute the card. When the card error
counter reaches its maximum value, the card is terminated
upon detection of a potential security violation.
Refinement:
The "potential security violation" stands for one of the following events:
o CAP file inconsistency,
o typing error in the operands of a bytecode,
o applet life cycle inconsistency,
o card tearing (unexpected removal of the Card out of the CAD) and power failure,
o abort of a transaction in an unexpected context, (see abortTransaction(), [JCAPI]
and ([JCRE], §7.6.2)
o violation of the Firewall or JCVM SFPs,
o unavailability of resources,
o array overflow,
o hidden alarm signalled by the application layer,
o failure of explicit integrity checks triggered by the application layer.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 75/130
FDP_SDI.2 Stored data integrity monitoring and action
FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for
integrity errors on all objects, based on the following attributes:
o User Packages
o PIN Objects
o OwnerBioTemplate Objects created by
javacardx.biometry.buildBioTemplate()
o Cipher Objects created by the javacardx.crypto.Cipher.getInstance()
method
o Signature Objects created by the
javacard.security.Signature.getInstance() method
o RandomData Objects created by the
javacard.security.RandomData.getInstance() method
o MessageDigest Objects created by the
javacard.security.MessageDigest.getInstance() method
o InitializedMessageDigest Objects created by the
javacard.security.MessageDigest.getInitializedMessageDigestInstance()
method
o Key Objects created by the javacard.security.KeyBuilder.buildKey()
method.
FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall reset the card.
FPR_UNO.1 Unobservability
FPR_UNO.1.1 The TSF shall ensure that any off-card or on-card subject other than
the runtime environment (S.JCRE) and the currently running applet are unable
to observe the operation PIN verification operations, bio datamatching operation,
encryption and decryption operations, signature generation and verification
operations, random data generation operations, key agreement operations,
key access operations, signalling of a hidden alarm on PIN Objects, Cipher
objects, signature objects, random data objects, key pair objects, key
agreement objects, key objects, or the currently running applet by the subject
S.JCRE or the currently running applet.
FPT_FLS.1 Failure with preservation of secure state
FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures
occur: those associated to the potential security violations described in
FAU_ARP.1.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 76/130
FPT_TDC.1 Inter-TSF basic TSF data consistency
FPT_TDC.1.1 The TSF shall provide the capability to consistently interpret the CAP files,
the bytecode and its data arguments when shared between the TSF and another
trusted IT product.
FPT_TDC.1.2 The TSF shall use
o the rules defined in [JCVM] specification,
o the API tokens defined in the export files of reference implementation
when interpreting the TSF data from another trusted IT product.
AID Management
FIA_ATD.1/AID User attribute definition
FIA_ATD.1.1/AID The TSF shall maintain the following list of security attributes belonging
to individual users:
o Package AID,
o Applet's version number,
o Registered applet AID,
o Applet Selection Status ([JCVM], §6.5).
Refinement:
"Individual users" stand for applets.
FIA_UID.2/AID User identification before any action
FIA_UID.2.1/AID The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 77/130
FIA_USB.1/AID User-subject binding
FIA_USB.1.1/AID The TSF shall associate the following user security attributes with
subjects acting on the behalf of that user: Package AID.
FIA_USB.1.2/AID The TSF shall enforce the following rules on the initial association of
user security attributes with subjects acting on the behalf of users: the AID of the
package acting on the behalf of the user shall be equal to the Package AID
security attribute of the user.
FIA_USB.1.3/AID The TSF shall enforce the following rules governing changes to the user
security attributes associated with subjects acting on the behalf of users: the Package
AID security attribute of a user shall not be modified.
FMT_MTD.1/JCRE Management of TSF data
FMT_MTD.1.1/JCRE The TSF shall restrict the ability to modify the list of registered
applets' AIDs to the JCRE.
FMT_MTD.3/JCRE Secure TSF data
FMT_MTD.3.1/JCRE The TSF shall ensure that only secure values are accepted for the
registered applets' AIDs.
8.1.2.2 InstG Security Functional Requirements
This group consists of the SFRs related to the installation of the applets, which addresses
security aspects outside the runtime. The installation of applets is a critical phase, which lies
partially out of the boundaries of the firewall, and therefore requires specific treatment. In
this ST, loading a package or installing an applet modeled as importation of user data (that
is, user application's data) with its security attributes (such as the parameters of the applet
used in the firewall rules).
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 78/130
FDP_ITC.2/Installer Import of user data with security attributes
FDP_ITC.2.1/Installer The TSF shall enforce the PACKAGE LOADING information
flow control SFP when importing user data, controlled under the SFP, from outside of
the TOE.
FDP_ITC.2.2/Installer The TSF shall use the security attributes associated with the
imported user data.
FDP_ITC.2.3/Installer The TSF shall ensure that the protocol used provides for the
unambiguous association between the security attributes and the user data received.
FDP_ITC.2.4/Installer The TSF shall ensure that interpretation of the security attributes
of the imported user data is as intended by the source of the user data.
FDP_ITC.2.5/Installer The TSF shall enforce the following rules when importing user data
controlled under the SFP from outside the TOE:
Package loading is allowed only if, for each dependent package, its AID
attribute is equal to a resident package AID attribute, the major (minor)
Version attribute associated to the dependent package is lesser than or equal
to the major (minor) Version attribute associated to the resident package
([JCVM], §4.5.2).
FMT_SMR.1/Installer Security roles
FMT_SMR.1.1/Installer The TSF shall maintain the roles: Installer.
FMT_SMR.1.2/Installer The TSF shall be able to associate users with roles.
FPT_FLS.1/Installer Failure with preservation of secure state
FPT_FLS.1.1/Installer The TSF shall preserve a secure state when the following types of
failures occur: the installer fails to load/install a package/applet as described in
[JCRE] §11.1.4.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 79/130
FPT_RCV.3/Installer Automated recovery without undue loss
FPT_RCV.3.1/Installer When automated recovery from any package loading session
interruption or failure, any applet installation interruption or failure is not
possible, the TSF shall enter a maintenance mode where the ability to return to a secure
state is provided.
FPT_RCV.3.2/Installer For any package loading session interruption or failure,
any applet installation interruption or failure, the TSF shall ensure the return of the
TOE to a secure state using automated procedures.
FPT_RCV.3.3/Installer The functions provided by the TSF to recover from failure or
service discontinuity shall ensure that the secure initial state is restored without exceeding
the loss of the package or applet installed for loss of TSF data or objects under the
control of the TSF.
FPT_RCV.3.4/Installer The TSF shall provide the capability to determine the objects that
were or were not capable of being recovered.
8.1.2.3 ADELG Security Functional Requirements
This group consists of the SFRs related to the deletion of applets and/or packages, enforcing
the applet deletion manager (ADEL) policy on security aspects outside the runtime. Deletion
is a critical operation and therefore requires specific treatment.
FDP_ACC.2/ADEL Complete access control
FDP_ACC.2.1/ADEL The TSF shall enforce the ADEL access control SFP on S.ADEL,
S.JCRE, S.JCVM, O.JAVAOBJECT, O.APPLET and O.CODE_PKG and all operations
among subjects and objects covered by the SFP.
Refinement:
The operations involved in the policy are:
o OP.DELETE_APPLET,
o OP.DELETE_PCKG,
o OP.DELETE_PCKG_APPLET.
FDP_ACC.2.2/ADEL The TSF shall ensure that all operations between any subject
controlled by the TSF and any object controlled by the TSF are covered by an access
control SFP.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 80/130
FDP_ACF.1/ADEL Security attribute based access control
FDP_ACF.1.1/ADEL The TSF shall enforce the ADEL access control SFP to objects
based on the following:
Subject/Object Attributes
S.JCVM Active Applets
S.JCRE Selected Applet Context, Registered Applets, Resident
Packages
O.CODE_PKG Package AID, Dependent Package AID, Static References
O.APPLET Applet Selection Status
O.JAVAOBJECT Owner, Remote
.
FDP_ACF.1.2/ADEL The TSF shall enforce the following rules to determine if an operation
among controlled subjects and controlled objects is allowed:
In the context of this policy, an object O is reachable if and only one of the
following conditions hold:
o (1) the owner of O is a registered applet instance A (O is reachable from
A),
o (2) a static field of a resident package P contains a reference to O (O is
reachable from P),
o (3) there exists an object O' that is reachable according to either (1) or
(2) above and O' contains a reference to O (the reachability status of O
is that of O').
The following access control rules determine when an operation among
controlled subjects and objects is allowed by the policy:
o R.JAVA.14 ([JCRE], §11.3.4.1, Applet Instance Deletion): S.ADEL may
perform OP.DELETE_APPLET upon an O.APPLET only if,
 (1) S.ADEL is currently selected,
 (2) there is no instance in the context of O.APPLET that is active in
any logical channel and
 (3) there is no O.JAVAOBJECT owned by O.APPLET such that either
O.JAVAOBJECT is reachable from an applet instance distinct from
O.APPLET, or O.JAVAOBJECT is reachable from a package P.
o R.JAVA.15 ([JCRE], §11.3.4.1, Multiple Applet Instance Deletion):
S.ADEL may perform OP.DELETE_APPLET upon several O.APPLET only if,
 (1) S.ADEL is currently selected,
 (2) there is no instance of any of the O.APPLET being deleted that is
active in any logical channel and
 (3) there is no O.JAVAOBJECT owned by any of the O.APPLET being
deleted such that either O.JAVAOBJECT is reachable from an applet
instance distinct from any of those O.APPLET, or O.JAVAOBJECT is
reachable from a package P.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 81/130
o R.JAVA.16 ([JCRE], §11.3.4.2, Applet/Library Package Deletion): S.ADEL
may perform OP.DELETE_PCKG upon an O.CODE_PKG only if,
 (1) S.ADEL is currently selected,
 (2) no reachable O.JAVAOBJECT, from a package distinct from
O.CODE_PKG that is an instance of a class that belongs to
O.CODE_PKG, exists on the card and
 (3) there is no resident package on the card that depends on
O.CODE_PKG.
o R.JAVA.17 ([JCRE], §11.3.4.3, Applet Package and Contained Instances
Deletion): S.ADEL may perform OP.DELETE_PCKG_APPLET upon an
O.CODE_PKG only if,
 (1) S.ADEL is currently selected,
 (2) no reachable O.JAVAOBJECT, from a package distinct from
O.CODE_PKG, which is an instance of a class that belongs to
O.CODE_PKG exists on the card,
 (3) there is no package loaded on the card that depends on
O.CODE_PKG, and
 (4) for every O.APPLET of those being deleted it holds that: (i) there
is no instance in the context of O.APPLET that is active in any logical
channel and (ii) there is no O.JAVAOBJECT owned by O.APPLET such
that either O.JAVAOBJECT is reachable from an applet instance not
being deleted, or O.JAVAOBJECT is reachable from a package not
being deleted.
FDP_ACF.1.3/ADEL The TSF shall explicitly authorise access of subjects to objects based
on the following additional rules: none.
FDP_ACF.1.4/ADEL [Editorially Refined] The TSF shall explicitly deny access of any
subject but S.ADEL to O.CODE_PKG or O.APPLET for the purpose of deleting
them from the card.
FDP_RIP.1/ADEL Subset residual information protection
FDP_RIP.1.1/ADEL The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the resource from the
following objects: applet instances and/or packages when one of the deletion
operations in FDP_ACC.2.1/ADEL is performed on them.
FMT_MSA.1/ADEL Management of security attributes
FMT_MSA.1.1/ADEL The TSF shall enforce the ADEL access control SFP to restrict the
ability to modify the security attributes Registered Applets and Resident Packages
to the Java Card RE.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 82/130
FMT_MSA.3/ADEL Static attribute initialisation
FMT_MSA.3.1/ADEL The TSF shall enforce the ADEL access control SFP to provide
restrictive default values for security attributes that are used to enforce the SFP.
FMT_MSA.3.2/ADEL The TSF shall allow the following role(s): none, to specify
alternative initial values to override the default values when an object or information is
created.
FMT_SMF.1/ADEL Specification of Management Functions
FMT_SMF.1.1/ADEL The TSF shall be capable of performing the following management
functions: modify the list of registered applets' AIDs and the Resident Packages.
FMT_SMR.1/ADEL Security roles
FMT_SMR.1.1/ADEL The TSF shall maintain the roles: applet deletion manager.
FMT_SMR.1.2/ADEL The TSF shall be able to associate users with roles.
FPT_FLS.1/ADEL Failure with preservation of secure state
FPT_FLS.1.1/ADEL The TSF shall preserve a secure state when the following types of
failures occur: the applet deletion manager fails to delete a package/applet as
described in [JCRE], §11.3.4.
8.1.2.4 ODELG Security Functional Requirements
The following requirements concern the object deletion mechanism. This mechanism is
triggered by the applet that owns the deleted objects by invoking a specific API method.
FDP_RIP.1/ODEL Subset residual information protection
FDP_RIP.1.1/ODEL The TSF shall ensure that any previous information content of a
resource is made unavailable upon the deallocation of the resource from the
following objects: the objects owned by the context of an applet instance which
triggered the execution of the method
javacard.framework.JCSystem.requestObjectDeletion().
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 83/130
FPT_FLS.1/ODEL Failure with preservation of secure state
FPT_FLS.1.1/ODEL The TSF shall preserve a secure state when the following types of
failures occur: the object deletion functions fail to delete all the unreferenced
objects owned by the applet that requested the execution of the method.
8.1.2.5 CarG Security Functional Requirements
This group includes requirements for preventing the installation of packages that has not
been bytecode verified, or that has been modified after bytecode verification.
FCO_NRO.2/CM Enforced proof of origin
FCO_NRO.2.1/CM The TSF shall enforce the generation of evidence of origin for
transmitted application packages at all times.
FCO_NRO.2.2/CM [Editorially Refined] The TSF shall be able to relate the identity of
the originator of the information, and the application package contained in the
information to which the evidence applies.
FCO_NRO.2.3/CM The TSF shall provide a capability to verify the evidence of origin of
information to recipient given immediate verification.
FDP_IFC.2/CM Complete information flow control
FDP_IFC.2.1/CM The TSF shall enforce the PACKAGE LOADING information flow
control SFP on S.INSTALLER, S.BCV, S.CAD and I.APDU and all operations that
cause that information to flow to and from subjects covered by the SFP.
FDP_IFC.2.2/CM The TSF shall ensure that all operations that cause any information in the
TOE to flow to and from any subject in the TOE are covered by an information flow
control SFP.
FDP_IFF.1/CM Simple security attributes
FDP_IFF.1.1/CM The TSF shall enforce the PACKAGE LOADING information flow
control SFP based on the following types of subject and information security attributes:
Subjects (for all secure channel protocol implementations): S.CAD and S.BCV,
S.CM, Subjects (package loading): S.CM’s Security Domain with Authorized
Management (i.e. Card Issuer Security domain) or Delegated Management
privilege, S.CM’s Security Domain with Mandated DAP verification privilege
(i.e. Verification Authority Security Domain), S.CM’s Security Domain with
Token verification privilege, S.CM’s OPEN. Information: I.APDU INSTALL [for
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 84/130
load] command data, I.APDU LOAD command data. Security attributes: Secure
channel key(s), Security level, Privileges.
FDP_IFF.1.2/CM The TSF shall permit an information flow between a controlled subject
and controlled information via a controlled operation if the following rules hold: the rules
describing the communication protocol (SCP02 or SCP03) used by the CAD and
the card for transmitting a new package.
FDP_IFF.1.3/CM The TSF shall enforce the none.
FDP_IFF.1.4/CM The TSF shall explicitly authorise an information flow based on the
following rules: none.
FDP_IFF.1.5/CM The TSF shall explicitly deny an information flow based on the following
rules:
o the TOE fails to verify the integrity and authenticity evidences of the
application package.
o when at least one of the conditions listed in the element FDP_IFF.1.2
does not hold.
FDP_UIT.1/CM Data exchange integrity
FDP_UIT.1.1/CM The TSF shall enforce the PACKAGE LOADING information flow
control SFP to receive user data in a manner protected from replay, insertion,
deletion and modification errors.
FDP_UIT.1.2/CM [Editorially Refined] The TSF shall be able to determine on receipt of
user data, whether modification, deletion, insertion or replay of some of the
pieces of the application sent by the CAD has occurred.
FIA_UID.1/CM Timing of identification
FIA_UID.1.1/CM The TSF shall allow application selection, initializing a secure
channel with the card and requesting data that identifies the card or the Card
Issuer on behalf of the user to be performed before the user is identified.
FIA_UID.1.2/CM The TSF shall require each user to be successfully identified before
allowing any other TSF-mediated actions on behalf of that user.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 85/130
FMT_MSA.1/CM Management of security attributes
FMT_MSA.1.1/CM The TSF shall enforce the PACKAGE LOADING information flow
control SFP to restrict the ability to delete, modify, query and change_default the
security attributes key value, key version, key identifier to Security Domain.
FMT_MSA.3/CM Static attribute initialisation
FMT_MSA.3.1/CM The TSF shall enforce the PACKAGE LOADING information flow
control SFP to provide restrictive default values for security attributes that are used to
enforce the SFP.
FMT_MSA.3.2/CM The TSF shall allow the currently selected Security Domain to
specify alternative initial values to override the default values when an object or
information is created.
FMT_SMF.1/CM Specification of Management Functions
FMT_SMF.1.1/CM The TSF shall be capable of performing the following management
functions:
o loading
o installation
o extradition
o content removal
o application personalization
o card life cycle.
Application Note:
These Management functions are specified in GlobalPlatform specifications [GP_CS].
FMT_SMR.1/CM Security roles
FMT_SMR.1.1/CM The TSF shall maintain the roles Card Administrator.
FMT_SMR.1.2/CM The TSF shall be able to associate users with roles.
Application Note:
A Security Domain is just the on-card counterpart of a representative of the Card Issuer. It is
introduced as a separate role in order to distinguish an application acting inside the smart
card on behalf of the Card Issuer from the Card Administrator.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 86/130
FTP_ITC.1/CM Inter-TSF trusted channel
FTP_ITC.1.1/CM The TSF shall provide a communication channel between itself and
another trusted IT product that is logically distinct from other communication channels
and provides assured identification of its end points and protection of the channel data
from modification or disclosure.
FTP_ITC.1.2/CM [Editorially Refined] The TSF shall permit the CAD placed in the
card issuer secured environment to initiate communication via the trusted channel.
FTP_ITC.1.3/CM The TSF shall initiate communication via the trusted channel for
loading/installing a new application package on the card.
8.1.3 Operating System
The Smart Card Platform group introduced in [PP_JC] specifies the IT requirements that are
imposed on the Operating System and the Integrated Circuit underlying the implementation
of the Runtime Environment. Because of the modification in the scope of evaluation, which
does include in this Security Target the Operating System and the Integrated Circuit, those
requirements on the IT environment become requirements on the TOE itself.
8.1.3.1 OSG Security Functional Requirements
FPT_RCV.3/OS Automated recovery without undue loss
FPT_RCV.3.1/OS When automated recovery from security policy violation is not
possible, the TSF shall enter a maintenance mode where the ability to return to a secure
state is provided.
FPT_RCV.3.2/OS For execution access to a memory zone reserved for TSF data,
writing access to a memory zone reserved for TSF's code, and any
segmentation fault performed by a Java Card applet, the TSF shall ensure the
return of the TOE to a secure state using automated procedures.
FPT_RCV.3.3/OS The functions provided by the TSF to recover from failure or service
discontinuity shall ensure that the secure initial state is restored without exceeding
o the contents of Java Card static fields, instance fields, and array
positions that fall under the scope of an open transaction;
o the Java Card objects that were allocated into the scope of an open
transaction;
o the contents of Java Card transient objects;
o any possible Executable Load File being loaded when the failure
occurred
for loss of TSF data or objects under the control of the TSF.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 87/130
FPT_RCV.3.4/OS The TSF shall provide the capability to determine the objects that were
or were not capable of being recovered.
FPT_RCV.4/OS Function recovery
FPT_RCV.4.1/OS The TSF shall ensure that reading from and writing to static and
objects fields interrupted by power loss have the property that the function either
completes successfully, or for the indicated failure scenarios, recovers to a consistent and
secure state.
FPT_FLS.1/OS Failure with preservation of secure state
FPT_FLS.1.1/OS The TSF shall preserve a secure state when the following types of failures
occur:
o invalid reference exception;
o code or data integrity failure;
o power loss;
o NVM failure.
FPT_PHP.3/OS Resistance to physical attack
FPT_PHP.3.1/OS The TSF shall resist physical manipulation and physical probing to
the TSF by responding automatically such that the SFRs are always enforced.
8.1.4 Card Life Cycle Management SFRs
These SFRs have been added to cover the O.CARD-MANAGEMENT objective as it becomes a
TOE objective.
FDP_ACC.1/CardLifeCycleManagement Subset access control
FDP_ACC.1.1/CardLifeCycleManagement The TSF shall enforce the CARD LIFE
CYCLE MANAGEMENT access control SFP on
o Subjects: S.CM, S.APPLET, S.CAD;
o Operations: OP.SET_CARD_STATE.
o Objects: O.CARD_LC.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 88/130
FDP_ACF.1/CardLifeCycleManagement Security attribute based access control
FDP_ACF.1.1/CardLifeCycleManagement The TSF shall enforce the CARD LIFE
CYCLE MANAGEMENT access control SFP to objects based on the following:
o the security attributes of O.CARD_LC: State as defined in [GP_CS]
Section 5.1: OP_READY, INITIALIZED, SECURED, CARD_LOCKED,
TERMINATED.
o the security attributes of S.APPLET: Privileges as defined in [GP_CS]
Section 6.6: Card Lock, Card Terminate.
FDP_ACF.1.2/CardLifeCycleManagement The TSF shall enforce the following rules to
determine if an operation among controlled subjects and controlled objects is allowed:
o S.CM is allowed to set the Card Life Cycle to INITIALIZED, SECURED,
CARD_LOCKED, and TERMINATED as defined in [GP_CS] Section 5.1.2.
o S.APPLET is allowed to set the Card Life Cycle to CARD_LOCKED if
S.APPLET has the Privilege Card Lock
o S.APPLET is allowed to set the Card Life Cycle to TERMINATED if
S.APPLET has the Privilege Card Terminate.
FDP_ACF.1.3/CardLifeCycleManagement The TSF shall explicitly authorise access of
subjects to objects based on the following additional rules: none.
FDP_ACF.1.4/CardLifeCycleManagement The TSF shall explicitly deny access of
subjects to objects based on the following additional rules:
o If the O.CARD_LC State=TERMINATED, the TOE is disabled, and the
access of subjects is no more allowed.
o Or when at least one of the rules defined by [GP_CS] does not hold.
FMT_MSA.1/CardLifeCycleManagement Management of security attributes
FMT_MSA.1.1/CardLifeCycleManagement The TSF shall enforce the CARD LIFE
CYCLE MANAGEMENT access control SFP to restrict the ability to modify the
security attributes O.CARD_LC State to S.CM and S.APPLET.
Application Note:
S.APPLET should be an application with Card Lock, Card Terminate Privileges as defined in
[GP_CS].
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 89/130
FMT_MSA.3/CardLifeCycleManagement Static attribute initialisation
FMT_MSA.3.1/CardLifeCycleManagement The TSF shall enforce the CARD LIFE
CYCLE MANAGEMENT access control SFP to provide restrictive default values for
security attributes that are used to enforce the SFP.
FMT_MSA.3.2/CardLifeCycleManagement The TSF shall allow the following role(s):
none to specify alternative initial values to override the default values when an object or
information is created.
FTP_ITC.1/CardLifeCycleManagement Inter-TSF trusted channel
FTP_ITC.1.1/CardLifeCycleManagement The TSF shall provide a communication
channel between itself and another trusted IT product that is logically distinct from other
communication channels and provides assured identification of its end points and
protection of the channel data from modification or disclosure.
FTP_ITC.1.2/CardLifeCycleManagement [Editorially Refined] The TSF shall permit
the CAD placed in the card issuer secured environment to initiate communication
via the trusted channel.
FTP_ITC.1.3/CardLifeCycleManagement The TSF shall initiate communication via the
trusted channel for setting the Card Life Cycle State.
8.1.5 SFRs for PACE API
These SFRs have been added to cover the PACE API of the TOE.
This group of SFRs apply only if the TOE provides PACE API, as it is removable.
FCS_CKM.2/PACE Cryptographic key distribution
FCS_CKM.2.1/PACE The TSF shall distribute cryptographic keys in accordance with a
specified cryptographic key distribution method Diffie-Hellman key agreement based
on the ephemeral domain parameters and generates the session keys for
encryption/decryption and authentication that meets the following: none.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 90/130
FCS_CKM.3/PACE Cryptographic key access
FCS_CKM.3.1/PACE The TSF shall perform see table below in accordance with a
specified cryptographic key access method see table below that meets the following:
see table below
Iteration Key Access Method Standard
ENC Key for encryption/decryption getSessionKeyEnc none
MAC Key for authentication getSessionKeyMac none
.
FCS_COP.1/PACE Cryptographic operation
FCS_COP.1.1/PACE The TSF shall perform see table below in accordance with a
specified cryptographic algorithm see table below and cryptographic key sizes see
table below that meet the following: see table below
Operation Algorithm Key Size Standard
Generates and encrypts the
nonce, which is used to perform
the following operations of a
PACE
3DES and AES,
in CBC mode
112 bits for
TDES and 128,
192 or 256 bits
for AES
[ICAO-
9303:Part
11]
Computes the ephemeral domain
parameters of the PACE
3DES and AES,
in CBC mode
112 bits for
TDES and 128,
192 or 256 bits
for AES
[ICAO-
9303:Part
11]
Performs a mutual authentication:
exchange and verify an
authentication token
Retail MAC
with 3DES,
AES
112 bits for
TDES and 128,
192 or 256 bits
for AES
[ICAO-
9303:Part
11]
.
8.2 Security Assurance Requirements
The Evaluation Assurance Level is EAL5 augmented with AVA_VAN.5 and ALC_DVS.2.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 91/130
8.3 Security Requirements Rationale
8.3.1 Objectives
8.3.1.1 Security Objectives for the TOE
Java Card System Protection Profile - Open Configuration
IDENTIFICATION
O.SID Subjects' identity is AID-based (applets, packages), and is met by the following SFRs:
FDP_ITC.2/Installer, FIA_ATD.1/AID, FMT_MSA.1/JCRE, FMT_MSA.1/JCVM,
FMT_MSA.1/ADEL, FMT_MSA.1/CM, FMT_MSA.3/ADEL, FMT_MSA.3/FIREWALL,
FMT_MSA.3/JCVM, FMT_MSA.3/CM, FMT_SMF.1/CM, FMT_SMF.1/ADEL,
FMT_SMF.1/ADEL, FMT_MTD.1/JCRE and FMT_MTD.3/JCRE.
Lastly, installation procedures ensure protection against forgery (the AID of an applet is
under the control of the TSFs) or re-use of identities (FIA_UID.2/AID, FIA_USB.1/AID).
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 92/130
EXECUTION
O.FIREWALL This objective is met by the FIREWALL access control policy
FDP_ACC.2/FIREWALL and FDP_ACF.1/FIREWALL, the JCVM information flow control
policy (FDP_IFF.1/JCVM, FDP_IFC.1/JCVM) and the functional requirement
FDP_ITC.2/Installer. The functional requirements of the class FMT (FMT_MTD.1/JCRE,
FMT_MTD.3/JCRE, FMT_SMR.1/Installer, FMT_SMR.1, FMT_SMF.1, FMT_SMR.1/ADEL,
FMT_SMF.1/ADEL, FMT_SMF.1/CM, FMT_MSA.1/CM, FMT_MSA.3/CM, FMT_SMR.1/CM,
FMT_MSA.2/FIREWALL_JCVM, FMT_MSA.3/FIREWALL, FMT_MSA.3/JCVM,
FMT_MSA.1/ADEL, FMT_MSA.3/ADEL, FMT_MSA.1/JCRE, FMT_MSA.1/JCVM) also
indirectly contribute to meet this objective.
O.GLOBAL_ARRAYS_CONFID Only arrays can be designated as global, and the only
global arrays required in the Java Card API are the APDU buffer and the global byte array
input parameter (bArray) to an applet's install method. The clearing requirement of these
arrays is met by (FDP_RIP.1/APDU and FDP_RIP.1/bArray respectively). The JCVM
information flow control policy (FDP_IFF.1/JCVM, FDP_IFC.1/JCVM) prevents an
application from keeping a pointer to a shared buffer, which could be used to read its
contents when the buffer is being used by another application.
O.GLOBAL_ARRAYS_INTEG This objective is met by the JCVM information flow control
policy (FDP_IFF.1/JCVM, FDP_IFC.1/JCVM), which prevents an application from keeping a
pointer to the APDU buffer of the card or to the global byte array of the applet's install
method. Such a pointer could be used to access and modify it when the buffer is being
used by another application.
O.NATIVE This security objective is covered by FDP_ACF.1/FIREWALL: the only means to
execute native code is the invocation of a Java Card API method. This objective mainly
relies on the environmental objective OE.APPLET, which uphold the assumption
A.APPLET.
O.OPERATE The TOE is protected in various ways against applets' actions (FPT_TDC.1), the
FIREWALL access control policy FDP_ACC.2/FIREWALL and FDP_ACF.1/FIREWALL, and is
able to detect and block various failures or security violations during usual working
(FPT_FLS.1/ADEL, FPT_FLS.1, FPT_FLS.1/ODEL, FPT_FLS.1/Installer, FAU_ARP.1). Its
security-critical parts and procedures are also protected: safe recovery from failure is
ensured (FPT_RCV.3/Installer), applets' installation may be cleanly aborted
(FDP_ROL.1/FIREWALL), communication with external users and their internal subjects is
well-controlled (FDP_ITC.2/Installer, FIA_ATD.1/AID, FIA_USB.1/AID) to prevent
alteration of TSF data (also protected by components of the FPT class).
Almost every objective and/or functional requirement indirectly contributes to this one
too.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 93/130
O.REALLOCATION This security objective is satisfied by the following SFRs:
FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS,
FDP_RIP.1/TRANSIENT, FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/ADEL, which
imposes that the contents of the re-allocated block shall always be cleared before
delivering the block.
O.RESOURCES The TSFs detects stack/memory overflows during execution of applications
(FAU_ARP.1, FPT_FLS.1/ADEL, FPT_FLS.1, FPT_FLS.1/ODEL, FPT_FLS.1/Installer). Failed
installations are not to create memory leaks (FDP_ROL.1/FIREWALL, FPT_RCV.3/Installer)
as well. Memory management is controlled by the TSF (FMT_MTD.1/JCRE,
FMT_MTD.3/JCRE, FMT_SMR.1/Installer, FMT_SMR.1, FMT_SMF.1 FMT_SMR.1/ADEL,
FMT_SMF.1/ADEL, FMT_SMF.1/CM and FMT_SMR.1/CM).
SERVICES
O.ALARM This security objective is met by FPT_FLS.1/Installer, FPT_FLS.1,
FPT_FLS.1/ADEL, FPT_FLS.1/ODEL which guarantee that a secure state is preserved by
the TSF when failures occur, and FAU_ARP.1 which defines TSF reaction upon detection
of a potential security violation.
O.CIPHER This security objective is directly covered by FCS_CKM.1, FCS_CKM.2,
FCS_CKM.3, FCS_CKM.4 and FCS_COP.1, FCS_CKM.2/PACE, FCS_CKM.3/PACE,
FCS_COP.1/PACE. The SFR FPR_UNO.1 contributes in covering this security objective and
controls the observation of the cryptographic operations which may be used to disclose
the keys.
O.KEY-MNGT This relies on the same security functional requirements as O.CIPHER, plus
FDP_RIP.1 and FDP_SDI.2 as well. Precisely it is met by the following components:
FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FCS_COP.1, FPR_UNO.1,
FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/APDU, FDP_RIP.1/bArray,
FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL and FDP_RIP.1/TRANSIENT,
FCS_CKM.2/PACE, FCS_CKM.3/PACE, FCS_COP.1/PACE.
O.PIN-MNGT This security objective is ensured by FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS,
FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS,
FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT, FPR_UNO.1, FDP_ROL.1/FIREWALL and
FDP_SDI.2 security functional requirements. The TSFs behind these are implemented by
API classes. The firewall security functions FDP_ACC.2/FIREWALL and
FDP_ACF.1/FIREWALL shall protect the access to private and internal data of the objects.
O.BIO-MNGT This objective is ensured by FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS,
FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FPR_UNO.1,
FDP_ROL.1/FIREWALL and FDP_SDI.2 security functional requirements. The applets that
manage biometric templates rely on the security functions that implement these SFRs.
The firewall security functions (FDP_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL) shall
protect the access to private and internal data of the templates. Note that the objective
applies only to configurations including the javacardx.biometry package defined in
[JCAPI].
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 94/130
O.TRANSACTION Directly met by FDP_ROL.1/FIREWALL, FDP_RIP.1/ABORT,
FDP_RIP.1/ODEL, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/KEYS,
FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT and FDP_RIP.1/OBJECTS (more precisely, by
the element FDP_RIP.1.1/ABORT).
OBJECT DELETION
O.OBJ-DELETION This security objective specifies that deletion of objects is secure. The
security objective is met by the security functional requirements FDP_RIP.1/ODEL and
FPT_FLS.1/ODEL.
APPLET MANAGEMENT
O.DELETION This security objective specifies that applet and package deletion must be
secure. The non-introduction of security holes is ensured by the ADEL access control
policy (FDP_ACC.2/ADEL, FDP_ACF.1/ADEL). The integrity and confidentiality of data that
does not belong to the deleted applet or package is a by-product of this policy as well.
Non-accessibility of deleted data is met by FDP_RIP.1/ADEL and the TSFs are protected
against possible failures of the deletion procedures (FPT_FLS.1/ADEL,
FPT_RCV.3/Installer). The security functional requirements of the class FMT
(FMT_MSA.1/ADEL, FMT_MSA.3/ADEL, FMT_SMR.1/ADEL) included in the group ADELG
also contribute to meet this objective.
O.LOAD This security objective specifies that the loading of a package into the card must be
secure. Evidence of the origin of the package is enforced (FCO_NRO.2/CM) and the
integrity of the corresponding data is under the control of the PACKAGE LOADING
information flow policy (FDP_IFC.2/CM, FDP_IFF.1/CM) and FDP_UIT.1/CM. Appropriate
identification (FIA_UID.1/CM) and transmission mechanisms are also enforced
(FTP_ITC.1/CM).
O.INSTALL This security objective specifies that installation of applets must be secure.
Security attributes of installed data are under the control of the FIREWALL access control
policy (FDP_ITC.2/Installer), and the TSFs are protected against possible failures of the
installer (FPT_FLS.1/Installer, FPT_RCV.3/Installer).
OPEN CONFIGURATION
O.SCP.IC This security objective is ensure by IC related requirements FPT_PHP.3/OS and
FPT_FLS.1/OS which refer to the general security of the underlying security IC to resist
physical manipulation and probing and reacting to induced failures. Furthermore, the
protection of key material as mandated by the objective is additionally enforced within the
implementation of the Java Card platform SFR FCS_COP.1 that offers cryptographic
services to the application layer.
O.SCP.RECOVERY This security objective is ensure by FPT_RCV.3/OS and FPT_RCV.4/OS.
O.SCP.SUPPORT This security objective is ensure by several SFRs:
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 95/130
o The general tamper resistance of the underlying security IC (FPT_PHP.3/OS)
contributes to the protection of Java Card system code and data. Furtermore,
sensitive data objects are additionally protected by the integrity protection
mechanisms provided by FDP_SDI.2. The enforcement of the domain separation
mechanisms is part of the protection of the implementation of
FMT_MSA.2/FIREWALL_JCVM and FMT_MSA.3/FIREWALL.
o The basic cryptographic support provided by the low-level parts of the system is
considered within the implementation of FCS_COP.1. The same services are also
used by other security implementation parts of the system like the secure channel
protocol implementation in the Card Management component.
o The objective to ensure the atomicity of updates on persistent data is covered by
the additonal requirements FPT_RCV.3/OS, FPT_RCV.4/OS.
o The security functional requirement FPT_FLS.1/OS which is related to the basic
memory protection mechanisms of the underlying IC establishes a first level of
protection. Additionally, the low-level basic operating system implements a
structured memory management offered as a service to the rest of the system.
CARD MANAGEMENT
O.CARD-MANAGEMENT This security objective shall control the access to the card and
implement the card issuers policy and is met by the components
FDP_ACC.1/CardLifeCycleManagement, FDP_ACF.1/CardLifeCycleManagement,
FMT_MSA.1/CardLifeCycleManagement, FMT_MSA.3/CardLifeCycleManagement, and
FTP_ITC.1/CardLifeCycleManagement.
8.3.2 Rationale tables of Security Objectives and SFRs
Security Objectives Security Functional Requirements Rationale
O.SID FIA_ATD.1/AID, FIA_UID.2/AID,
FMT_MSA.1/JCRE, FMT_MSA.1/ADEL,
FMT_MSA.3/ADEL, FMT_MSA.3/FIREWALL,
FMT_MSA.1/CM, FMT_MSA.3/CM,
FDP_ITC.2/Installer, FMT_SMF.1/CM,
FMT_SMF.1/ADEL, FMT_MTD.1/JCRE,
FMT_MTD.3/JCRE, FIA_USB.1/AID,
FMT_MSA.1/JCVM, FMT_MSA.3/JCVM
Section 8.3.1
O.FIREWALL FDP_IFC.1/JCVM, FDP_IFF.1/JCVM,
FMT_SMR.1/Installer, FMT_MSA.1/CM,
FMT_MSA.3/CM, FMT_SMR.1/CM,
FMT_MSA.3/FIREWALL, FMT_SMR.1,
FMT_MSA.1/ADEL, FMT_MSA.3/ADEL,
FMT_SMR.1/ADEL, FMT_MSA.1/JCRE,
FDP_ITC.2/Installer, FDP_ACC.2/FIREWALL,
FDP_ACF.1/FIREWALL, FMT_SMF.1/ADEL,
FMT_SMF.1/CM, FMT_SMF.1,
FMT_MSA.2/FIREWALL_JCVM,
FMT_MTD.1/JCRE, FMT_MTD.3/JCRE,
FMT_MSA.1/JCVM, FMT_MSA.3/JCVM
Section 8.3.1
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 96/130
O.GLOBAL_ARRAYS_CONFID FDP_IFC.1/JCVM, FDP_IFF.1/JCVM,
FDP_RIP.1/bArray, FDP_RIP.1/APDU
Section 8.3.1
O.GLOBAL_ARRAYS_INTEG FDP_IFC.1/JCVM, FDP_IFF.1/JCVM Section 8.3.1
O.NATIVE FDP_ACF.1/FIREWALL Section 8.3.1
O.OPERATE FAU_ARP.1, FDP_ROL.1/FIREWALL,
FIA_ATD.1/AID, FPT_FLS.1/ADEL,
FPT_FLS.1, FPT_FLS.1/ODEL,
FPT_FLS.1/Installer, FDP_ITC.2/Installer,
FPT_RCV.3/Installer, FDP_ACC.2/FIREWALL,
FDP_ACF.1/FIREWALL, FPT_TDC.1,
FIA_USB.1/AID
Section 8.3.1
O.REALLOCATION FDP_RIP.1/ABORT, FDP_RIP.1/APDU,
FDP_RIP.1/bArray, FDP_RIP.1/KEYS,
FDP_RIP.1/TRANSIENT, FDP_RIP.1/ADEL,
FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS
Section 8.3.1
O.RESOURCES FAU_ARP.1, FDP_ROL.1/FIREWALL,
FMT_SMR.1/Installer, FMT_SMR.1,
FMT_SMR.1/ADEL, FPT_FLS.1/Installer,
FPT_FLS.1/ODEL, FPT_FLS.1,
FPT_FLS.1/ADEL, FPT_RCV.3/Installer,
FMT_SMR.1/CM, FMT_SMF.1/ADEL,
FMT_SMF.1/CM, FMT_SMF.1,
FMT_MTD.1/JCRE, FMT_MTD.3/JCRE
Section 8.3.1
O.ALARM FPT_FLS.1/Installer, FPT_FLS.1,
FPT_FLS.1/ADEL, FPT_FLS.1/ODEL,
FAU_ARP.1
Section 8.3.1
O.CIPHER FCS_CKM.1, FCS_CKM.2, FCS_CKM.3,
FCS_CKM.4, FCS_COP.1, FPR_UNO.1,
FCS_CKM.2/PACE, FCS_CKM.3/PACE,
FCS_COP.1/PACE
Section 8.3.1
O.KEY-MNGT FCS_CKM.1, FCS_CKM.2, FCS_CKM.3,
FCS_CKM.4, FCS_COP.1, FPR_UNO.1,
FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS,
FDP_RIP.1/APDU, FDP_RIP.1/bArray,
FDP_RIP.1/ABORT, FDP_RIP.1/KEYS,
FDP_SDI.2, FDP_RIP.1/ADEL,
FDP_RIP.1/TRANSIENT, FCS_CKM.2/PACE,
FCS_CKM.3/PACE, FCS_COP.1/PACE
Section 8.3.1
O.PIN-MNGT FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS,
FDP_RIP.1/APDU, FDP_RIP.1/bArray,
FDP_RIP.1/ABORT, FDP_RIP.1/KEYS,
FPR_UNO.1, FDP_RIP.1/ADEL,
FDP_RIP.1/TRANSIENT,
FDP_ROL.1/FIREWALL, FDP_SDI.2,
FDP_ACC.2/FIREWALL,
FDP_ACF.1/FIREWALL
Section 8.3.1
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 97/130
O.BIO-MNGT FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS,
FDP_RIP.1/APDU, FDP_RIP.1/bArray,
FDP_RIP.1/ABORT, FDP_RIP.1/KEYS,
FPR_UNO.1, FDP_ROL.1/FIREWALL,
FDP_SDI.2, FDP_ACC.2/FIREWALL,
FDP_ACF.1/FIREWALL
Section 8.3.1
O.TRANSACTION FDP_ROL.1/FIREWALL, FDP_RIP.1/ABORT,
FDP_RIP.1/ODEL, FDP_RIP.1/APDU,
FDP_RIP.1/bArray, FDP_RIP.1/KEYS,
FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT,
FDP_RIP.1/OBJECTS
Section 8.3.1
O.OBJ-DELETION FDP_RIP.1/ODEL, FPT_FLS.1/ODEL Section 8.3.1
O.DELETION FDP_ACC.2/ADEL, FDP_ACF.1/ADEL,
FDP_RIP.1/ADEL, FPT_FLS.1/ADEL,
FPT_RCV.3/Installer, FMT_MSA.1/ADEL,
FMT_MSA.3/ADEL, FMT_SMR.1/ADEL
Section 8.3.1
O.LOAD FCO_NRO.2/CM, FDP_IFC.2/CM,
FDP_IFF.1/CM, FDP_UIT.1/CM,
FIA_UID.1/CM, FTP_ITC.1/CM
Section 8.3.1
O.INSTALL FDP_ITC.2/Installer, FPT_RCV.3/Installer,
FPT_FLS.1/Installer
Section 8.3.1
O.SCP.IC FPT_FLS.1/OS, FCS_COP.1, FPT_PHP.3/OS Section 8.3.1
O.SCP.RECOVERY FPT_RCV.4/OS, FPT_RCV.3/OS Section 8.3.1
O.SCP.SUPPORT FPT_FLS.1/OS, FPT_RCV.4/OS,
FPT_RCV.3/OS, FPT_PHP.3/OS, FDP_SDI.2,
FMT_MSA.3/FIREWALL,
FMT_MSA.2/FIREWALL_JCVM, FCS_COP.1
Section 8.3.1
O.CARD-MANAGEMENT FDP_ACC.1/CardLifeCycleManagement,
FDP_ACF.1/CardLifeCycleManagement,
FMT_MSA.1/CardLifeCycleManagement,
FMT_MSA.3/CardLifeCycleManagement,
FTP_ITC.1/CardLifeCycleManagement
Section 8.3.1
Table 8 Security Objectives and SFRs - Coverage
Security Functional Requirements Security Objectives Rationale
FDP_ACC.2/FIREWALL O.FIREWALL, O.OPERATE, O.PIN-
MNGT, O.BIO-MNGT
FDP_ACF.1/FIREWALL O.FIREWALL, O.NATIVE, O.OPERATE,
O.PIN-MNGT, O.BIO-MNGT
FDP_IFC.1/JCVM O.FIREWALL,
O.GLOBAL_ARRAYS_CONFID,
O.GLOBAL_ARRAYS_INTEG
FDP_IFF.1/JCVM O.FIREWALL,
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 98/130
O.GLOBAL_ARRAYS_CONFID,
O.GLOBAL_ARRAYS_INTEG
FDP_RIP.1/OBJECTS O.REALLOCATION, O.KEY-MNGT,
O.PIN-MNGT, O.BIO-MNGT,
O.TRANSACTION
FMT_MSA.1/JCRE O.SID, O.FIREWALL
FMT_MSA.1/JCVM O.SID, O.FIREWALL
FMT_MSA.2/FIREWALL_JCVM O.FIREWALL, O.SCP.SUPPORT
FMT_MSA.3/FIREWALL O.SID, O.FIREWALL, O.SCP.SUPPORT
FMT_MSA.3/JCVM O.SID, O.FIREWALL
FMT_SMF.1 O.FIREWALL, O.RESOURCES
FMT_SMR.1 O.FIREWALL, O.RESOURCES
FCS_CKM.1 O.CIPHER, O.KEY-MNGT
FCS_CKM.2 O.CIPHER, O.KEY-MNGT
FCS_CKM.3 O.CIPHER, O.KEY-MNGT
FCS_CKM.4 O.CIPHER, O.KEY-MNGT
FCS_COP.1 O.CIPHER, O.KEY-MNGT, O.SCP.IC,
O.SCP.SUPPORT
FDP_RIP.1/ABORT O.REALLOCATION, O.KEY-MNGT,
O.PIN-MNGT, O.BIO-MNGT,
O.TRANSACTION
FDP_RIP.1/APDU O.GLOBAL_ARRAYS_CONFID,
O.REALLOCATION, O.KEY-MNGT,
O.PIN-MNGT, O.BIO-MNGT,
O.TRANSACTION
FDP_RIP.1/bArray O.GLOBAL_ARRAYS_CONFID,
O.REALLOCATION, O.KEY-MNGT,
O.PIN-MNGT, O.BIO-MNGT,
O.TRANSACTION
FDP_RIP.1/KEYS O.REALLOCATION, O.KEY-MNGT,
O.PIN-MNGT, O.BIO-MNGT,
O.TRANSACTION
FDP_RIP.1/TRANSIENT O.REALLOCATION, O.KEY-MNGT,
O.PIN-MNGT, O.TRANSACTION
FDP_ROL.1/FIREWALL O.OPERATE, O.RESOURCES, O.PIN-
MNGT, O.BIO-MNGT,
O.TRANSACTION
FAU_ARP.1 O.OPERATE, O.RESOURCES, O.ALARM
FDP_SDI.2 O.KEY-MNGT, O.PIN-MNGT, O.BIO-
MNGT, O.SCP.SUPPORT
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 99/130
FPR_UNO.1 O.CIPHER, O.KEY-MNGT, O.PIN-
MNGT, O.BIO-MNGT
FPT_FLS.1 O.OPERATE, O.RESOURCES, O.ALARM
FPT_TDC.1 O.OPERATE
FIA_ATD.1/AID O.SID, O.OPERATE
FIA_UID.2/AID O.SID
FIA_USB.1/AID O.SID, O.OPERATE
FMT_MTD.1/JCRE O.SID, O.FIREWALL, O.RESOURCES
FMT_MTD.3/JCRE O.SID, O.FIREWALL, O.RESOURCES
FDP_ITC.2/Installer O.SID, O.FIREWALL, O.OPERATE,
O.INSTALL
FMT_SMR.1/Installer O.FIREWALL, O.RESOURCES
FPT_FLS.1/Installer O.OPERATE, O.RESOURCES,
O.ALARM, O.INSTALL
FPT_RCV.3/Installer O.OPERATE, O.RESOURCES,
O.DELETION, O.INSTALL
FDP_ACC.2/ADEL O.DELETION
FDP_ACF.1/ADEL O.DELETION
FDP_RIP.1/ADEL O.REALLOCATION, O.KEY-MNGT,
O.PIN-MNGT, O.TRANSACTION,
O.DELETION
FMT_MSA.1/ADEL O.SID, O.FIREWALL, O.DELETION
FMT_MSA.3/ADEL O.SID, O.FIREWALL, O.DELETION
FMT_SMF.1/ADEL O.SID, O.FIREWALL, O.RESOURCES
FMT_SMR.1/ADEL O.FIREWALL, O.RESOURCES,
O.DELETION
FPT_FLS.1/ADEL O.OPERATE, O.RESOURCES,
O.ALARM, O.DELETION
FDP_RIP.1/ODEL O.REALLOCATION, O.KEY-MNGT,
O.PIN-MNGT, O.BIO-MNGT,
O.TRANSACTION, O.OBJ-DELETION
FPT_FLS.1/ODEL O.OPERATE, O.RESOURCES,
O.ALARM, O.OBJ-DELETION
FCO_NRO.2/CM O.LOAD
FDP_IFC.2/CM O.LOAD
FDP_IFF.1/CM O.LOAD
FDP_UIT.1/CM O.LOAD
FIA_UID.1/CM O.LOAD
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 100/130
FMT_MSA.1/CM O.SID, O.FIREWALL
FMT_MSA.3/CM O.SID, O.FIREWALL
FMT_SMF.1/CM O.SID, O.FIREWALL, O.RESOURCES
FMT_SMR.1/CM O.FIREWALL, O.RESOURCES
FTP_ITC.1/CM O.LOAD
FPT_RCV.3/OS O.SCP.RECOVERY, O.SCP.SUPPORT
FPT_RCV.4/OS O.SCP.RECOVERY, O.SCP.SUPPORT
FPT_FLS.1/OS O.SCP.IC, O.SCP.SUPPORT
FPT_PHP.3/OS O.SCP.IC, O.SCP.SUPPORT
FDP_ACC.1/CardLifeCycleManagement O.CARD-MANAGEMENT
FDP_ACF.1/CardLifeCycleManagement O.CARD-MANAGEMENT
FMT_MSA.1/CardLifeCycleManagement O.CARD-MANAGEMENT
FMT_MSA.3/CardLifeCycleManagement O.CARD-MANAGEMENT
FTP_ITC.1/CardLifeCycleManagement O.CARD-MANAGEMENT
FCS_CKM.2/PACE O.CIPHER, O.KEY-MNGT
FCS_CKM.3/PACE O.CIPHER, O.KEY-MNGT
FCS_COP.1/PACE O.CIPHER, O.KEY-MNGT
Table 9 SFRs and Security Objectives
8.3.3 Dependencies
8.3.3.1 SFRs Dependencies
Requirements CC
Dependencie
s
Satisfied Dependencies
FDP_ACC.1/CardLifeCycleManagemen
t
(FDP_ACF.1) FDP_ACF.1/CardLifeCycleManagement
FDP_ACF.1/CardLifeCycleManagemen
t
(FDP_ACC.1)
and
(FMT_MSA.3)
FDP_ACC.1/CardLifeCycleManagement
,
FMT_MSA.3/CardLifeCycleManagemen
t
FMT_MSA.1/CardLifeCycleManageme
nt
(FDP_ACC.1
or
FDP_IFC.1)
and
(FMT_SMF.1)
and
(FMT_SMR.1)
FDP_ACC.1/CardLifeCycleManagement
, FMT_SMF.1/CM, FMT_SMR.1/CM
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 101/130
FMT_MSA.3/CardLifeCycleManageme
nt
(FMT_MSA.1)
and
(FMT_SMR.1)
FMT_MSA.1/CardLifeCycleManagemen
t, FMT_SMR.1/CM
FTP_ITC.1/CardLifeCycleManagement No
Dependencie
s
FCS_CKM.2/PACE (FCS_CKM.1
or FDP_ITC.1
or
FDP_ITC.2)
and
(FCS_CKM.4)
FCS_CKM.3/PACE (FCS_CKM.1
or FDP_ITC.1
or
FDP_ITC.2)
and
(FCS_CKM.4)
FCS_COP.1/PACE (FCS_CKM.1
or FDP_ITC.1
or
FDP_ITC.2)
and
(FCS_CKM.4)
FDP_ITC.2/Installer (FDP_ACC.1
or
FDP_IFC.1)
and
(FPT_TDC.1)
and
(FTP_ITC.1
or
FTP_TRP.1)
FDP_IFC.2/CM, FTP_ITC.1/CM,
FPT_TDC.1
FMT_SMR.1/Installer (FIA_UID.1)
FPT_FLS.1/Installer No
Dependencie
s
FPT_RCV.3/Installer (AGD_OPE.1) AGD_OPE.1
FDP_ACC.2/ADEL (FDP_ACF.1) FDP_ACF.1/ADEL
FDP_ACF.1/ADEL (FDP_ACC.1)
and
(FMT_MSA.3)
FDP_ACC.2/ADEL, FMT_MSA.3/ADEL
FDP_RIP.1/ADEL No
Dependencie
s
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 102/130
FMT_MSA.1/ADEL (FDP_ACC.1
or
FDP_IFC.1)
and
(FMT_SMF.1)
and
(FMT_SMR.1)
FDP_ACC.2/ADEL, FMT_SMF.1/ADEL,
FMT_SMR.1/ADEL
FMT_MSA.3/ADEL (FMT_MSA.1)
and
(FMT_SMR.1)
FMT_MSA.1/ADEL, FMT_SMR.1/ADEL
FMT_SMF.1/ADEL No
Dependencie
s
FMT_SMR.1/ADEL (FIA_UID.1)
FPT_FLS.1/ADEL No
Dependencie
s
FDP_RIP.1/ODEL No
Dependencie
s
FPT_FLS.1/ODEL No
Dependencie
s
FCO_NRO.2/CM (FIA_UID.1) FIA_UID.1/CM
FDP_IFC.2/CM (FDP_IFF.1) FDP_IFF.1/CM
FDP_IFF.1/CM (FDP_IFC.1)
and
(FMT_MSA.3)
FDP_IFC.2/CM, FMT_MSA.3/CM
FDP_UIT.1/CM (FDP_ACC.1
or
FDP_IFC.1)
and
(FTP_ITC.1
or
FTP_TRP.1)
FDP_IFC.2/CM, FTP_ITC.1/CM
FIA_UID.1/CM No
Dependencie
s
FMT_MSA.1/CM (FDP_ACC.1
or
FDP_IFC.1)
and
(FMT_SMF.1)
and
(FMT_SMR.1)
FDP_IFC.2/CM, FMT_SMF.1/CM,
FMT_SMR.1/CM
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 103/130
FMT_MSA.3/CM (FMT_MSA.1)
and
(FMT_SMR.1)
FMT_MSA.1/CM, FMT_SMR.1/CM
FMT_SMF.1/CM No
Dependencie
s
FMT_SMR.1/CM (FIA_UID.1) FIA_UID.1/CM
FTP_ITC.1/CM No
Dependencie
s
FPT_RCV.3/OS (AGD_OPE.1) AGD_OPE.1
FPT_RCV.4/OS No
Dependencie
s
FPT_FLS.1/OS No
Dependencie
s
FPT_PHP.3/OS No
Dependencie
s
FDP_ACC.2/FIREWALL (FDP_ACF.1) FDP_ACF.1/FIREWALL
FDP_ACF.1/FIREWALL (FDP_ACC.1)
and
(FMT_MSA.3)
FDP_ACC.2/FIREWALL,
FMT_MSA.3/FIREWALL
FDP_IFC.1/JCVM (FDP_IFF.1) FDP_IFF.1/JCVM
FDP_IFF.1/JCVM (FDP_IFC.1)
and
(FMT_MSA.3)
FDP_IFC.1/JCVM, FMT_MSA.3/JCVM
FDP_RIP.1/OBJECTS No
Dependencie
s
FMT_MSA.1/JCRE (FDP_ACC.1
or
FDP_IFC.1)
and
(FMT_SMF.1)
and
(FMT_SMR.1)
FDP_ACC.2/FIREWALL, FMT_SMR.1
FMT_MSA.1/JCVM (FDP_ACC.1
or
FDP_IFC.1)
and
(FMT_SMF.1)
and
FDP_ACC.2/FIREWALL,
FDP_IFC.1/JCVM, FMT_SMF.1,
FMT_SMR.1
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 104/130
(FMT_SMR.1)
FMT_MSA.2/FIREWALL_JCVM (FDP_ACC.1
or
FDP_IFC.1)
and
(FMT_MSA.1)
and
(FMT_SMR.1)
FDP_ACC.2/FIREWALL,
FDP_IFC.1/JCVM, FMT_MSA.1/JCRE,
FMT_MSA.1/JCVM, FMT_SMR.1
FMT_MSA.3/FIREWALL (FMT_MSA.1)
and
(FMT_SMR.1)
FMT_MSA.1/JCRE, FMT_MSA.1/JCVM,
FMT_SMR.1
FMT_MSA.3/JCVM (FMT_MSA.1)
and
(FMT_SMR.1)
FMT_MSA.1/JCVM, FMT_SMR.1
FMT_SMF.1 No
Dependencie
s
FMT_SMR.1 (FIA_UID.1) FIA_UID.2/AID
FCS_CKM.1 (FCS_CKM.2
or
FCS_COP.1)
and
(FCS_CKM.4)
FCS_CKM.2, FCS_CKM.4
FCS_CKM.2 (FCS_CKM.1
or FDP_ITC.1
or
FDP_ITC.2)
and
(FCS_CKM.4)
FCS_CKM.1, FCS_CKM.4
FCS_CKM.3 (FCS_CKM.1
or FDP_ITC.1
or
FDP_ITC.2)
and
(FCS_CKM.4)
FCS_CKM.1, FCS_CKM.4
FCS_CKM.4 (FCS_CKM.1
or FDP_ITC.1
or
FDP_ITC.2)
FCS_CKM.1
FCS_COP.1 (FCS_CKM.1
or FDP_ITC.1
or
FDP_ITC.2)
and
(FCS_CKM.4)
FCS_CKM.1, FCS_CKM.4
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 105/130
FDP_RIP.1/ABORT No
Dependencie
s
FDP_RIP.1/APDU No
Dependencie
s
FDP_RIP.1/bArray No
Dependencie
s
FDP_RIP.1/KEYS No
Dependencie
s
FDP_RIP.1/TRANSIENT No
Dependencie
s
FDP_ROL.1/FIREWALL (FDP_ACC.1
or
FDP_IFC.1)
FDP_ACC.2/FIREWALL,
FDP_IFC.1/JCVM
FAU_ARP.1 (FAU_SAA.1)
FDP_SDI.2 No
Dependencie
s
FPR_UNO.1 No
Dependencie
s
FPT_FLS.1 No
Dependencie
s
FPT_TDC.1 No
Dependencie
s
FIA_ATD.1/AID No
Dependencie
s
FIA_UID.2/AID No
Dependencie
s
FIA_USB.1/AID (FIA_ATD.1) FIA_ATD.1/AID
FMT_MTD.1/JCRE (FMT_SMF.1)
and
(FMT_SMR.1)
FMT_SMF.1, FMT_SMR.1
FMT_MTD.3/JCRE (FMT_MTD.1
)
FMT_MTD.1/JCRE
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 106/130
Table 10 SFRs Dependencies
Rationale for the exclusion of Dependencies
The dependency FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 of FCS_CKM.2/PACE is
discarded. The FCS_CKM.1 is implicit. Keys are generated with key distribution.
The dependency FCS_CKM.4 of FCS_CKM.2/PACE is discarded. The FCS_CKM.4 key
destruction is operated by the calling application.
The dependency FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 of FCS_CKM.3/PACE is
discarded. The FCS_CKM.1 is implicit. Keys are generated with key distribution.
The dependency FCS_CKM.4 of FCS_CKM.3/PACE is discarded. The FCS_CKM.4 key
destruction is operated by the calling application.
The dependency FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2 of FCS_COP.1/PACE is
discarded. The FCS_CKM.1 is implicit. Keys are generated with key distribution.
The dependency FCS_CKM.4 of FCS_COP.1/PACE is discarded. The FCS_CKM.4 key
destruction is operated by the calling application.
The dependency FIA_UID.1 of FMT_SMR.1/Installer is discarded. This ST does not
require the identification of the "installer" since it can be considered as part of the TSF.
The dependency FIA_UID.1 of FMT_SMR.1/ADEL is discarded. This ST does not
require the identification of the "deletion manager" since it can be considered as part of
the TSF.
The dependency FMT_SMF.1 of FMT_MSA.1/JCRE is discarded. The dependency
between FMT_MSA.1/JCRE and FMT_SMF.1 is not satisfied because no management
functions are required for the Java Card RE.
The dependency FAU_SAA.1 of FAU_ARP.1 is discarded. The dependency of
FAU_ARP.1 on FAU_SAA.1 assumes that a "potential security violation" generates an audit
event. On the contrary, the events listed in FAU_ARP.1 are self-contained (arithmetic
exception, ill-formed bytecodes, access failure) and ask for a straightforward reaction of
the TSFs on their occurrence at runtime. The JCVM or other components of the TOE
detect these events during their usual working order. Thus, there is no mandatory audit
recording in this ST.
8.3.3.2 SARs Dependencies
Requirements CC Dependencies Satisfied Dependencies
ADV_ARC.1 (ADV_FSP.1) and (ADV_TDS.1) ADV_FSP.5, ADV_TDS.4
ADV_FSP.5 (ADV_IMP.1) and (ADV_TDS.1) ADV_IMP.1, ADV_TDS.4
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 107/130
ADV_IMP.1 (ADV_TDS.3) and (ALC_TAT.1) ADV_TDS.4, ALC_TAT.2
ADV_INT.2 (ADV_IMP.1) and (ADV_TDS.3) and
(ALC_TAT.1)
ADV_IMP.1, ADV_TDS.4,
ALC_TAT.2
ADV_TDS.4 (ADV_FSP.5) ADV_FSP.5
AGD_OPE.1 (ADV_FSP.1) ADV_FSP.5
AGD_PRE.1 No Dependencies
ALC_CMC.4 (ALC_CMS.1) and (ALC_DVS.1) and
(ALC_LCD.1)
ALC_CMS.5, ALC_DVS.2,
ALC_LCD.1
ALC_CMS.5 No Dependencies
ALC_DEL.1 No Dependencies
ALC_DVS.2 No Dependencies
ALC_LCD.1 No Dependencies
ALC_TAT.2 (ADV_IMP.1) ADV_IMP.1
ASE_CCL.1 (ASE_ECD.1) and (ASE_INT.1) and
(ASE_REQ.1)
ASE_ECD.1, ASE_INT.1,
ASE_REQ.2
ASE_ECD.1 No Dependencies
ASE_INT.1 No Dependencies
ASE_OBJ.2 (ASE_SPD.1) ASE_SPD.1
ASE_REQ.2 (ASE_ECD.1) and (ASE_OBJ.2) ASE_ECD.1, ASE_OBJ.2
ASE_SPD.1 No Dependencies
ASE_TSS.1 (ADV_FSP.1) and (ASE_INT.1) and
(ASE_REQ.1)
ADV_FSP.5, ASE_INT.1,
ASE_REQ.2
ATE_COV.2 (ADV_FSP.2) and (ATE_FUN.1) ADV_FSP.5, ATE_FUN.1
ATE_DPT.3 (ADV_ARC.1) and (ADV_TDS.4) and
(ATE_FUN.1)
ADV_ARC.1, ADV_TDS.4,
ATE_FUN.1
ATE_FUN.1 (ATE_COV.1) ATE_COV.2
ATE_IND.2 (ADV_FSP.2) and (AGD_OPE.1) and
(AGD_PRE.1) and (ATE_COV.1) and
(ATE_FUN.1)
ADV_FSP.5, AGD_OPE.1,
AGD_PRE.1, ATE_COV.2,
ATE_FUN.1
AVA_VAN.5 (ADV_ARC.1) and (ADV_FSP.4) and
(ADV_IMP.1) and (ADV_TDS.3) and
(AGD_OPE.1) and (AGD_PRE.1) and
(ATE_DPT.1)
ADV_ARC.1, ADV_FSP.5,
ADV_IMP.1, ADV_TDS.4,
AGD_OPE.1, AGD_PRE.1,
ATE_DPT.3
Table 11 SARs Dependencies
8.3.4 Rationale for the Security Assurance Requirements
The chosen assurance level EAL5 and the augmentation with the requirements ALC_DVS.2
and AVA_VAN.5 were chosen in order to meet the assurance expectations for this type of
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 108/130
TOE since it is intended to defend against highly sophisticated attacks without protective
environment. This evaluation assurance package was selected to permit a developer to gain
maximum assurance from positive security engineering based on good commercial practices.
The augmentations are in compliance with the Protection Profile.
8.3.5 AVA_VAN.5 Advanced methodical vulnerability analysis
The TOE is intended to operate in hostile environments. AVA_VAN.5 is considered as the
expected level for Java Card technology-based products hosting sensitive applications, in
particular in our identity area. In fact, AVA_VAN.5 provides a higher assurance of the
security by vulnerability analysis to assess the resistance to penetration attacks performed by
an attacker possessing a high attack potential.
8.3.6 ALC_DVS.2 Sufficiency of security measures
Development security is concerned with physical, procedural, personnel and other technical
measures that may be used in the development environment to protect the TOE and the
embedding product. The standard ALC_DVS.1 requirement mandated by EAL5 is not enough.
Due to the nature of the TOE and embedding product, ALC_DVS.2 is the most adequate for
a manufacturing process in which several actors (Platform Developer, Operator, Application
Developers, IC Manufacturer, etc) exchange and store highly sensitive informations
(confidential code, cryptographic keys, personalisation data, etc).
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 109/130
9 TOE Summary Specification
9.1 TOE Summary Specification
9.1.1 Functionalities
The TOE includes the following functionalities:
F.OPEN
The F.OPEN subsystem provides the following functionalities:
o APDU dispatcher
o Application invocation
F.CARD_MANAGER
The F.CARD_MANAGER subsystem provides the following functionalities:
o Verification management
o Load management
o Install management
o Issuer Security Domain
o Supplementary Security Domain
F.JAVA_CARD_SYSTEM
The F.JAVA_CARD_SYSTEM subsystem provides the following functionalities:
o Virtual machine
o Runtime environment
o Loader Linker
o Garbage collector
F.JAVA_API
The F.JAVA_API subsystem provides the following functionalities:
o GlobalPlatform API
o Security and cryptography framework (javacard.security API)
o Java Card Framework (javacard.framework API)
o Biometric framework (javacardx.biometry API)
o Security and cryptography extension (javacardx.security API)
o External memory access (javacardx.external API)
o Extension framework (javacardx.framework API)
o SAC protocol (com.morpho.sac API)
o SM accelerator (com.morpho.sm API)
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 110/130
F.AUTHENTICATION
The F.AUTHENTICATION subsystem provides the following functionalities:
o Supplementary access control establishment
o Secure communication management
This sub-system comes in support to F.CARD_MANAGER
F.CRYPTOGRAPHY_SERVICES
The F.CRYPTOGRAPHY_SERVICES subsystem provides the following functionalities:
o Key protection (in non-volatile memory)
o Random number generation
o Hash computation
o Data ciphering and deciphering
o CRC computation
o Symmetric and asymmetric signature
o Elliptic curves diffe-hellman key agreement
o Key derivation and generation
o Secure channel protocol
o Crypto self-tests
This sub-system comes in support to F.JAVA_API
F.SECRET_DATA_MANAGER
The F.SECRET_DATA_MANAGER subsystem provides the following functionality:
o Biometric authentication algorithms
F.SECURE_DATA_MANAGER
The F.SECURE_DATA_MANAGER subsystem provides the following functionalities:
o PIN management
o Key management
This sub-system comes in support to F.JAVA_API
F.SYSTEM_MANAGER
The F.SYSTEM_MANAGER subsystem provides the following functionalities:
o System initialization
o Configuration dispatcher
o Configuration parameters
o Non volatile memory protection management
o Application registry
F.MEMORY_ACCESS
The F.MEMORY_ACCESS subsystem provides the following functionalities:
o Non volatile memory allocation
o Java objects access
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 111/130
F.MEMORY_WRITE_MANAGER
The F.MEMORY_WRITE_MANAGER subsystem provides the following functionalities:
o Transaction and atomicity management
o Dynamic RAM allocation
F.INPUT/OUTPUT_LAYER
The F.INPUT/OUTPUT_LAYER subsystem provides the following functionalities:
o Communication initialization
o Communication exchange
o I/O state management
o ATR management
o APDU buffer management
F.MEMORY_CONTROLLER
The F.MEMORY_CONTROLLER subsystem provides the following functionalities:
o NVM writing
o Memory copy and compare operations
F.TRANSPORT_LAYER
The F.TRANSPORT_LAYER subsystem provides the following functionalities:
o Interface availability control
o Time extension management
o Contact interface management
o Contactless interface management
F.CPU_MANAGER
The F.CPU_MANAGER subsystem provides the following functionalities:
o CPU serial number access
o CPU configuration access
F.SECURITY_CONFIGURATION
The F.SECURITY_CONFIGURATION subsystem provides the following functionalities:
o Card security configuration
o Card security operations
F.CRYPTOGRAPHIC_LIBRARY
The F.CRYPTOGRAPHIC_LIBRARY subsystem provides the following functionalities:
o DES algorithm operations
o AES algorithm operations
o SHA algorithm operations
o Modular exponentiation operations
o Elliptic curves operations
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 112/130
o Key protection (in volatile memory)
o Utilities
o Random number generation
o XRC operations
o Cryptographic routines
F.SECURITY_AUDIT
The F.SECURITY_AUDIT subsystem provides the following functionality:
o Security audit and reaction operation
F.SECURITY_AUDIT comes in support to all other subsystem. For simplification
purposes, they are not listed in the requirement rationale part.
F.INTEGRATED_CIRCUIT
The F.INTEGRATED_CIRCUIT subsystem provides the following functionality:
o Physical protection mechanisms
F.INTEGRATED_CIRCUIT comes in support to all other subsystem. For simplification
purposes, they are not listed in the requirement rationale part.
9.2 SFRs and TSS
9.2.1 SFRs and TSS - Rationale
Java Card System Protection Profile - Open Configuration
CoreG_LC Security Functional Requirements
Firewall Policy
FDP_ACC.2/FIREWALL :
The FDP_ACC.2/FIREWALL SFR is enforced by the F.JAVA_CARD_SYSTEM,
F.MEMORY_ACCESS and F.JAVA_API functionalities.
The operations listed in the FDP_ACC.2/FIREWALL SFR can only be performed by the
F.JAVA_CARD_SYSTEM and F.JAVA_API functionalities and thus the SFR cannot be
bypassed.
FDP_ACF.1/FIREWALL :
The FDP_ACF.1/FIREWALL SFR is enforced by the F.JAVA_CARD_SYSTEM,
F.MEMORY_ACCESS and F.JAVA_API.
The operations listed in the FDP_ACF.1/FIREWALL SFR can only be performed by the
F.JAVA_CARD_SYSTEM and F.JAVA_API functionalities and thus the SFR cannot be
bypassed.
FDP_IFC.1/JCVM :
The FDP_IFC.1/JCVM SFR is enforced by the F.JAVA_CARD_SYSTEM functionality. The
operations listed in the FDP_IFC.1/JCVM SFR can only be performed by the
F.JAVA_CARD_SYSTEM functionality and thus the SFR cannot be bypassed.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 113/130
FDP_IFF.1/JCVM :
The FDP_IFF.1/JCVM SFR is enforced by the F.JAVA_CARD_SYSTEM functionality.
The operations listed in the FDP_IFF.1/JCVM SFR can only be performed by the
F.JAVA_CARD_SYSTEM functionality and thus the SFR cannot be bypassed.
FDP_RIP.1/OBJECTS :
The FDP_RIP.1/Objects SFR is enforced by the F.MEMORY_ACCESS functionality.
The allocation of resource to class instances and arrays can only be performed by the
F.MEMORY_ACCESS and the F.MEMORY_CONTROLLER functionalities and thus the SFR
cannot be bypassed.
FMT_MSA.1/JCRE :
The FMT_MSA.1/JCRE SFR is enforced by the F.OPEN and the F.JAVA_API functionalities.
The modification of the Selected Applet Context can only be performed by the F.OPEN
and the F.JAVA_API functionalities and thus the SFR cannot be bypassed.
FMT_MSA.1/JCVM :
The FMT_MSA.1/JCVM SFR is enforced by the F.JAVA_CARD_SYSTEM functionality.
The modification of the Currently Active Context and Active Applets can only be
performed by the F.JAVA_CARD_SYSTEM functionality and thus the SFR cannot be
bypassed.
FMT_MSA.2/FIREWALL_JCVM :
The FMT_MSA.2/FIREWALL_JCVM is enforced by the F.JAVA_CARD_SYSTEM,
F.MEMORY_ACCESS and the F.JAVA_API functionalities.
The security attributes used in the FIREWALL access control SFP (see
FDP_ACF.1/FIREWALL) and the JCVM information flow control SFP (see FDP_IFF.1/JCVM)
are only used by functionalities listed above and thus the SFR cannot be bypassed.
FMT_MSA.3/FIREWALL :
The FMT_MSA.3/FIREWALL SFR is enforced by the F.JAVA_CARD_SYSTEM, the
F.MEMORY_ACCESS, the F.JAVA_API and the F.SECURE_DATA_MANAGER functionalities.
The security attributes used in the FIREWALL access control SFP are only initialised by the
functionalities listed above and thus the SFR cannot be bypassed.
FMT_MSA.3/JCVM :
The FMT_MSA.3/JCVM SFR is enforced by the F.JAVA_CARD_SYSTEM functionality.
The security attributes used in the JCVM information flow control SFP are only initialised
by the functionalities listed above and thus the SFR cannot be bypassed.
FMT_SMF.1 :
The FMT_SMF.1 SFR is enforced by the F.OPEN, F.JAVA_API and the
F.JAVA_CARD_SYSTEM functionalities.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 114/130
The modification of the Currently Active Context, the Selected Applet Context and the
Active Applets security attributes can only be performed by the functionalities listed above
and thus the SFR cannot be bypassed.
FMT_SMR.1 :
The FMT_SMR.1 SFR is enforced by the F.JAVA_CARD_SYSTEM functionality.
The Java Card RE and Java Card VM security roles are only maintained in the
F.JAVA_CARD_SYSTEM functionality and thus the SFR cannot be bypassed.
Application Programming Interface
FCS_CKM.1 :
The FCS_CKM.1 SFR is enforced by the F.JAVA_API and F.CRYPTOGRAPHY_SERVICES
functionalities.
The cryptographic key generation operation can only be performed by the F.JAVA_API
and F.CRYPTOGRAPHY_SERVICES functionalities and thus the SFR cannot be bypassed.
FCS_CKM.2 :
The FCS_CKM.2 SFR is enforced by the F.JAVA_API and F.CRYPTOGRAPHY_SERVICES
functionalities.
The cryptographic key distribution operation can only be performed by the F.JAVA_API
and F.CRYPTOGRAPHY_SERVICES functionalities and thus the SFR cannot be bypassed.
FCS_CKM.3 :
The FCS_CKM.3 SFR is enforced by the F.JAVA_API, the F.CARD_MANAGER and
F.CRYPTOGRAPHY_SERVICES functionalities.
The cryptographic key access operation can only be performed by the F.JAVA_API,
F.CARD_MANAGER and F.CRYPTOGRAPHY_SERVICES functionalities and thus the SFR
cannot be bypassed.
FCS_CKM.4 :
The FCS_CKM.4 SFR is enforced by the F.JAVA_API and the F.CRYPTOGRAPHY_SERVICES
functionalities.
The cryptographic key destruction operation can only be performed by the F.JAVA_API
and the F.CRYPTOGRAPHY_SERVICES functionalities and thus the SFR cannot be
bypassed.
FCS_COP.1 :
The FCS_COP.1 SFR is enforced by the F.CRYPTOGRAPHIC_LIBRARY and the
F.CRYPTOGRAPHY_SERVICES functionalities.
The cryptographic operations listed in the FCS_COP.1 SFR can only be performed by the
F.CRYPTOGRAPHIC_LIBRARY and the F.CRYPTOGRAPHY_SERVICES functionalities and
thus the SFR cannot be bypassed.
FDP_RIP.1/ABORT :
The FDP_RIP.1/ABORT SFR is enforced by the F.MEMORY_WRITE_MANAGER
functionality.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 115/130
The transactions are only managed by the F.MEMORY_WRITE_MANAGER functionality
and thus the SFR cannot be bypassed.
FDP_RIP.1/APDU :
The FDP_RIP.1/APDU SFR is enforced by the F.INPUT/OUTPUT_LAYER functionality.
The external communications are only managed by the F.INPUT/OUTPUT_LAYER
functionality and thus the SFR cannot be bypassed.
FDP_RIP.1/bArray :
The FDP_RIP.1/bArray SFR is enforced by the F.INPUT/OUTPUT_LAYER functionality.
The external communications are only managed by the F.INPUT/OUTPUT_LAYER
functionality and thus the SFR cannot be bypassed.
FDP_RIP.1/KEYS :
The FDP_RIP.1/KEYS SFR is enforced by the F.CRYPTOGRAPHY_SERVICES functionality
with support from the F.CRYPTOGRAPHIC_LIBRARY functionality.
The deallocation of the cryptographic buffer can only be performed by the
F.CRYPTOGRAPHY_SERVICES functionality and thus the SFR cannot be bypassed.
FDP_RIP.1/TRANSIENT :
The FDP_RIP.1/TRANSIENT SFR is enforced by the F.JAVA_API functionality.
The transient objects management is only performed by the F.JAVA_API functionality and
thus the SFR cannot be bypassed.
FDP_ROL.1/FIREWALL :
The FDP_ROL.1/FIREWALL SFR is enforced by the F.MEMORY_WRITE_MANAGER
functionality.
The transactions are only managed by the F.MEMORY_WRITE_MANAGER functionality
and thus the SFR cannot be bypassed.
Card Security Management
FAU_ARP.1 :
The FAU_ARP.1 SFR is enforced by the F.JAVA_CARD_SYSTEM,
F.SECURE_DATA_MANAGER, F.SECRET_DATA_MANAGER, F.JAVA_API,
F.SYSTEM_MANAGER and F.MEMORY_WRITE_MANAGER functionalities.
The potential security violations listed in the SFR can only be detected by the
functionalities listed above and thus the SFR cannot be bypassed.
FDP_SDI.2 :
The FDP_SDI.2 SFR is enforced by the F.JAVA_API, F.MEMORY_ACCESS functionality with
support from the F.JAVA_CARD_SYSTEM functionality.
The integrity-sensitive user data are managed only by the functionalities listed above and
thus the SFR cannot be bypassed.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 116/130
FPR_UNO.1 :
The FPR_UNO.1 SFR is enforced by the F.JAVA_API, F.SECURE_DATA_MANAGER and
F.CRYPTOGRAPHIC_LIBRARY functionalities with support from the
F.CRYPTOGRAPHY_SERVICES functionality.
The sensitive operations listed in the SFR can only be performed by the functionalities
listed above and thus the SFR cannot be bypassed.
FPT_FLS.1 :
The FPT_FLS.1 SFR is enforced by the F.JAVA_CARD_SYSTEM and
F.CRYPTOGRAPHIC_LIBRARY F.MEMORY_CONTROLLER, F.SECURITY_CONFIGURATION
and F.TRANSPORT_LAYER functionalities.
The secure state preservation for the operations listed in the FPT_FLS.1 SFR is always
performed by the functionality listed above and thus the SFR cannot be bypassed.
FPT_TDC.1 :
The FPT_TDC.1 SFR is enforced by the F.JAVA_CARD_SYSTEM functionality.
The CAP file can only be interpreted by the F.JAVA_CARD_SYSTEM functionality and the
bytecode and its data arguments can only be interpreted by the F.JAVA_CARD_SYSTEM
functionality and thus the SFR cannot be bypassed.
AID Management
FIA_ATD.1/AID :
The FIA_ATD.1/AID SFR is enforced by the F.JAVA_CARD_SYSTEM functionality.
The security attributes listed in the SFR are only maintained by the
F.JAVA_CARD_SYSTEM functionality and thus the SFR cannot be bypassed.
FIA_UID.2/AID :
The FIA_UID.2/AID SFR is enforced by the F.OPEN and the F.JAVA_CARD_SYSTEM
functionalities.
The user (i.e. applet) identification can only be performed by the F.OPEN and the
F.JAVA_CARD_SYSTEM functionalities and thus the SFR cannot be bypassed.
FIA_USB.1/AID :
The FIA_USB.1/AID SFR is enforced by the F.JAVA_CARD_SYSTEM functionality.
The user - Package AID association can only be performed by the F.JAVA_CARD_SYSTEM
functionality and thus the SFR cannot be bypassed.
FMT_MTD.1/JCRE :
The FMT_MTD.1/JCRE SFR is enforced by the F.JAVA_API and F.SYSTEM_MANAGER
functionalities.
The list of registered applets' AID can only be modified by the functionalities listed above
and thus the SFR cannot be bypassed.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 117/130
FMT_MTD.3/JCRE :
The FMT_MTD.3/JCRE SFR is enforced by the F.JAVA_CARD_SYSTEM and
F.SYSTEM_MANAGER functionalities.
The registered applets' AID update can only be performed by the functionalities listed
above and thus the SFR cannot be bypassed.
InstG Security Functional Requirements
FDP_ITC.2/Installer :
The FDP_ITC.2/Installer SFR is enforced by the F.CARD_MANAGER and
F.JAVA_CARD_SYSTEM functionalities.
The package loading and processing can only be performed by the functionalities listed
above and thus the SFR cannot be bypassed.
FMT_SMR.1/Installer :
The FMT_SMR.1/Installer SFR is enforced by the F.CARD_MANAGER functionality.
The Installer role can only be assumed by the F.CARD_MANAGER functionality and thus
the SFR cannot be bypassed.
FPT_FLS.1/Installer :
The FPT_FLS.1/Installer SFR is enforced by the F.CARD_MANAGER and
F.JAVA_CARD_SYSTEM functionalities.
The installer failure detection and management can only be performed by the
functionality listed above and thus the SFR cannot be bypassed.
FPT_RCV.3/Installer :
The FPT_RCV.3/Installer SFR is enforced by the F.JAVA_CARD_SYSTEM functionality with
support from the F.JAVA_API functionality.
An installer failure detection is always processed by F.JAVA_CARD_SYSTEM functionality
and thus the SFR cannot be bypassed.
ADELG Security Functional Requirements
FDP_ACC.2/ADEL :
The FDP_ACC.2/ADEL SFR is enforced by the F.CARD_MANAGER functionality.
The applet deletion can only be performed by the F.CARD_MANAGER functionality and
thus the SFR cannot be bypassed.
FDP_ACF.1/ADEL :
The FDP_ACF.1/ADEL SFR is enforced by the F.CARD_MANAGER, F.JAVA_API and
F.JAVA_CARD_SYSTEM functionalities.
The applet deletion can only be performed by the F.CARD_MANAGER, F.JAVA_API and
F.JAVA_CARD_SYSTEM functionalities and thus the SFR cannot be bypassed.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 118/130
FDP_RIP.1/ADEL :
The FDP_RIP.1/ADEL SFR is enforced by the F.JAVA_CARD_SYSTEM functionality.
The deallocation of resources from applet instances and/or packages can only be
performed by the F.JAVA_CARD_SYSTEM functionality and thus the SFR cannot be
bypassed.
FMT_MSA.1/ADEL :
The FMT_MSA.1/ADEL SFR is enforced by the F.JAVA_API and F.SYSTEM_MANAGER
functionalities with the support of the F.JAVA_CARD_SYSTEM functionality.
The modification of the security attributes Registered Applets and Resident Packages can
only be performed by the F.JAVA_API and F.SYSTEM_MANAGER functionalities and thus
the SFR cannot be bypassed.
FMT_MSA.3/ADEL :
The FMT_MSA.3/ADEL SFR is enforced by the F.CARD_MANAGER and the
F.JAVA_CARD_SYSTEM functionalities.
The default values of the security attributes used by the F.CARD_MANAGER and the
F.JAVA_CARD_SYSTEM cannot be changed and thus the SFR cannot be bypassed.
FMT_SMF.1/ADEL :
The FMT_SMF.1/ADEL SFR is enforced by the F.CARD_MANAGER functionality.
The modification of the list of registered applet's AIDs and the Resident Packages can
only be performed by the F.CARD_MANAGER functionality and thus the SFR cannot be
bypassed.
FMT_SMR.1/ADEL :
The FMT_SMR.1/ADEL SFR is enforced by the F.CARD_MANAGER functionality.
The applet deletion operation can only be performed by the F.CARD_MANAGER
functionality and thus the SFR cannot be bypassed.
FPT_FLS.1/ADEL :
The FPT_FLS.1/ADEL SFR is enforced by the F.JAVA_API and the F.JAVA_CARD_SYSTEM
functionalities.
The applet deletion failure management operation can only be performed by the
F.JAVA_API and the F.JAVA_CARD_SYSTEM functionalities and thus the SFR cannot be
bypassed.
ODELG Security Functional Requirements
FDP_RIP.1/ODEL :
The FDP_RIP.1/ODEL SFR is enforced by the F.JAVA_CARD_SYSTEM functionality.
The object deletion can only be performed by the F.JAVA_CARD_SYSTEM functionality
and thus the SFR cannot be bypassed.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 119/130
FPT_FLS.1/ODEL :
The FPT_FLS.1/ODEL SFR is enforced by the F.JAVA_CARD_SYSTEM and the F.OPEN
functionalities.
The object deletion failure detection and recovery can only be performed by the
F.JAVA_CARD_SYSTEM and the F.OPEN functionalities and thus the SFR cannot be
bypassed
CarG Security Functional Requirements
FCO_NRO.2/CM :
The FCO_NRO.2/CM SFR is enforced by the F.CARD_MANAGER functionality.
The loading of an application package can only be performed by the F.CARD_MANAGER
functionality and thus the SFR cannot be bypassed.
FDP_IFC.2/CM :
The FDP_IFC.2/CM SFR is enforced by the F.CARD_MANAGER functionality.
The loading of an application package can only be performed by the F.CARD_MANAGER
functionality and thus the SFR cannot be bypassed.
FDP_IFF.1/CM :
The FDP_IFF.1/CM SFR is enforced by the F.CARD_MANAGER functionality.
The loading of an application package can only be performed by the F.CARD_MANAGER
functionalityand thus the SFR cannot be bypassed.
FDP_UIT.1/CM :
The FDP_UIT.1/CM SFR is enforced by the F.CARD_MANAGER functionality.
The user data reception can only be performed by the F.CARD_MANAGER functionality
and thus the SFR cannot be bypassed.
FIA_UID.1/CM :
The FIA_UID.1/CM SFR is enforced by the F.CARD_MANAGER and the F.OPEN
functionalities.
The user identification can only be performed by the F.CARD_MANAGER and the F.OPEN
functionalities and thus the SFR cannot be bypassed.
FMT_MSA.1/CM :
The FMT_MSA.1/CM SFR is enforced by the F.CARD_MANAGER functionality.
The key loading can only be performed by the F.CARD_MANAGER functionality and thus
the SFR cannot be bypassed.
FMT_MSA.3/CM :
The FMT_MSA.3/CM SFR is enforced by the F.CARD_MANAGER functionality.
The default values can only be changed by the F.CARD_MANAGER functionality and thus
the SFR cannot be bypassed.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 120/130
FMT_SMF.1/CM :
The FMT_SMF.1/CM SFR is enforced by the F.CARD_MANAGER functionality.
The management functions specified in FMT_SMF.1/CM can only be performed by the
F.CARD_MANAGER functionality and thus the SFR cannot be bypassed.
FMT_SMR.1/CM :
The FMT_SMR.1/CM SFR is enforced by the F.CARD_MANAGER functionality.
The card administrator role can only be played by the F.CARD_MANAGER functionality
and thus the SFR cannot be bypassed.
FTP_ITC.1/CM :
The FTP_ITC.1/CM SFR is enforced by the F.CARD_MANAGER functionality.
The package loading and applet installation operations can only be performed by the
F.CARD_MANAGER functionality and thus the SFR cannot be bypassed.
Operating System
OSG Security Functional Requirements
FPT_RCV.3/OS :
The FPT_RCV.3/OS SFR is enforced by the F.JAVA_CARD_SYSTEM functionality with the
support of the F.MEMORY_WRITE_MANAGER functionality.
The reception of all security policy violations listed in FPT_RCV.3/OS can only be
performed by the F.JAVA_CARD_SYSTEM functionality and thus the SFR cannot be
bypassed.
FPT_RCV.4/OS :
The FPT_RCV.4/OS SFR is enforced by the F.MEMORY_WRITE_MANAGER functionality.
The management of a power loss during the reading from and writing to static and
objects fields can only be performed by the F.MEMORY_WRITE_MANAGER functionality
and thus the SFR cannot be bypassed.
FPT_FLS.1/OS :
The FPT_FLS.1/OS SFR is enforced by the F.JAVA_CARD_SYSTEM, F.MEMORY_ACCESS
and F.SECURE_DATA_MANAGER functionalities.
The reference check, code integrity verification, data integrity verification, power loss
management and NVM programmation management can only be performed by the
functionalities listed above and thus the SFR cannot be bypassed.
FPT_PHP.3/OS :
The FPT_PHP.3/OS SFR is enforced by the F.CPU_MANAGER,
F.CRYPTOGRAPHIC_LIBRARY, F.SECURITY_CONFIGURATION and
F.MEMORY_CONTROLLER functionalities.
The physical manipulation and physical probing detection and management can only be
performed by the functionalities listed above and thus the SFR cannot be bypassed.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 121/130
Card Life Cycle Management SFRs
FDP_ACC.1/CardLifeCycleManagement :
The FDP_ACC.1/CardLifeCycleManagement SFR is enforced by the F.CARD_MANAGER
functionality.
FDP_ACF.1/CardLifeCycleManagement :
The FDP_ACF.1/CardLifeCycleManagement SFR is enforced by the F.CARD_MANAGER and
F.SYSTEM_MANAGER functionalities.
FMT_MSA.1/CardLifeCycleManagement :
The FMT_MSA.1/CardLifeCycleManagement SFR is enforced by the F.CARD_MANAGER
functionality.
FMT_MSA.3/CardLifeCycleManagement :
The FMT_MSA.3/CardLifeCycleManagement SFR is enforced by the F.CARD_MANAGER
functionality.
FTP_ITC.1/CardLifeCycleManagement :
The FTP_ITC.1/CardLifeCycleManagement SFR is enforced by the F.CARD_MANAGER
functionality.
SFRs for PACE API
FCS_CKM.2/PACE :
The FCS_CKM.2/PACE SFR is enforced by the F.AUTHENTICATION functionality.
FCS_CKM.3/PACE :
The FCS_CKM.3/PACE SFR is enforced by the F.JAVA_API functionality.
FCS_COP.1/PACE :
The FCS_COP.1/PACE SFR is enforced by the F.AUTHENTICATION functionality with
support from the F.CRYPTOGRAPHIC_LIBRARY functionality.
9.2.2 Association tables of SFRs and TSS
Security Functional Requirements TOE Summary Specification
FDP_ACC.2/FIREWALL F.JAVA_CARD_SYSTEM, F.JAVA_API,
F.MEMORY_ACCESS
FDP_ACF.1/FIREWALL F.JAVA_CARD_SYSTEM, F.JAVA_API,
F.MEMORY_ACCESS
FDP_IFC.1/JCVM F.JAVA_CARD_SYSTEM
FDP_IFF.1/JCVM F.JAVA_CARD_SYSTEM
FDP_RIP.1/OBJECTS F.MEMORY_ACCESS, F.MEMORY_CONTROLLER
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 122/130
FMT_MSA.1/JCRE F.OPEN, F.JAVA_API
FMT_MSA.1/JCVM F.JAVA_CARD_SYSTEM
FMT_MSA.2/FIREWALL_JCVM F.JAVA_CARD_SYSTEM, F.JAVA_API,
F.MEMORY_ACCESS
FMT_MSA.3/FIREWALL F.JAVA_CARD_SYSTEM, F.JAVA_API,
F.MEMORY_ACCESS,
F.SECURE_DATA_MANAGER
FMT_MSA.3/JCVM F.JAVA_CARD_SYSTEM
FMT_SMF.1 F.OPEN, F.JAVA_CARD_SYSTEM, F.JAVA_API
FMT_SMR.1 F.JAVA_CARD_SYSTEM
FCS_CKM.1 F.JAVA_API, F.CRYPTOGRAPHY_SERVICES
FCS_CKM.2 F.JAVA_API, F.CRYPTOGRAPHY_SERVICES
FCS_CKM.3 F.CARD_MANAGER, F.JAVA_API,
F.CRYPTOGRAPHY_SERVICES
FCS_CKM.4 F.JAVA_API, F.CRYPTOGRAPHY_SERVICES
FCS_COP.1 F.CRYPTOGRAPHIC_LIBRARY,
F.CRYPTOGRAPHY_SERVICES
FDP_RIP.1/ABORT F.MEMORY_WRITE_MANAGER
FDP_RIP.1/APDU F.INPUT/OUTPUT_LAYER
FDP_RIP.1/bArray F.INPUT/OUTPUT_LAYER
FDP_RIP.1/KEYS F.CRYPTOGRAPHY_SERVICES,
F.CRYPTOGRAPHIC_LIBRARY
FDP_RIP.1/TRANSIENT F.JAVA_API
FDP_ROL.1/FIREWALL F.MEMORY_WRITE_MANAGER
FAU_ARP.1 F.JAVA_CARD_SYSTEM, F.JAVA_API,
F.MEMORY_WRITE_MANAGER,
F.SECURE_DATA_MANAGER,
F.SECRET_DATA_MANAGER,
F.SYSTEM_MANAGER
FDP_SDI.2 F.JAVA_API, F.JAVA_CARD_SYSTEM,
F.MEMORY_ACCESS,
F.CRYPTOGRAPHY_SERVICES
FPR_UNO.1 F.JAVA_API, F.SECURE_DATA_MANAGER,
F.CRYPTOGRAPHY_SERVICES,
F.CRYPTOGRAPHIC_LIBRARY
FPT_FLS.1 F.JAVA_CARD_SYSTEM,
F.SECURITY_CONFIGURATION,
F.MEMORY_CONTROLLER,
F.TRANSPORT_LAYER,
F.CRYPTOGRAPHIC_LIBRARY
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 123/130
FPT_TDC.1 F.JAVA_CARD_SYSTEM
FIA_ATD.1/AID F.JAVA_CARD_SYSTEM
FIA_UID.2/AID F.OPEN, F.JAVA_CARD_SYSTEM
FIA_USB.1/AID F.JAVA_CARD_SYSTEM
FMT_MTD.1/JCRE F.JAVA_API, F.SYSTEM_MANAGER
FMT_MTD.3/JCRE F.JAVA_CARD_SYSTEM, F.SYSTEM_MANAGER
FDP_ITC.2/Installer F.CARD_MANAGER, F.JAVA_CARD_SYSTEM
FMT_SMR.1/Installer F.CARD_MANAGER
FPT_FLS.1/Installer F.CARD_MANAGER, F.JAVA_CARD_SYSTEM
FPT_RCV.3/Installer F.JAVA_CARD_SYSTEM, F.JAVA_API
FDP_ACC.2/ADEL F.CARD_MANAGER
FDP_ACF.1/ADEL F.CARD_MANAGER, F.JAVA_CARD_SYSTEM,
F.JAVA_API
FDP_RIP.1/ADEL F.JAVA_CARD_SYSTEM
FMT_MSA.1/ADEL F.JAVA_API, F.JAVA_CARD_SYSTEM,
F.SYSTEM_MANAGER
FMT_MSA.3/ADEL F.CARD_MANAGER, F.JAVA_CARD_SYSTEM
FMT_SMF.1/ADEL F.CARD_MANAGER
FMT_SMR.1/ADEL F.CARD_MANAGER
FPT_FLS.1/ADEL F.JAVA_API, F.JAVA_CARD_SYSTEM
FDP_RIP.1/ODEL F.JAVA_CARD_SYSTEM
FPT_FLS.1/ODEL F.OPEN, F.JAVA_CARD_SYSTEM
FCO_NRO.2/CM F.CARD_MANAGER
FDP_IFC.2/CM F.CARD_MANAGER
FDP_IFF.1/CM F.CARD_MANAGER
FDP_UIT.1/CM F.CARD_MANAGER
FIA_UID.1/CM F.OPEN, F.CARD_MANAGER
FMT_MSA.1/CM F.CARD_MANAGER
FMT_MSA.3/CM F.CARD_MANAGER
FMT_SMF.1/CM F.CARD_MANAGER
FMT_SMR.1/CM F.CARD_MANAGER
FTP_ITC.1/CM F.CARD_MANAGER
FPT_RCV.3/OS F.MEMORY_WRITE_MANAGER,
F.JAVA_CARD_SYSTEM
FPT_RCV.4/OS F.MEMORY_WRITE_MANAGER
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 124/130
FPT_FLS.1/OS F.JAVA_CARD_SYSTEM,
F.SECURE_DATA_MANAGER,
F.MEMORY_ACCESS
FPT_PHP.3/OS F.MEMORY_CONTROLLER,
F.SECURITY_CONFIGURATION,
F.CPU_MANAGER, F.CRYPTOGRAPHIC_LIBRARY
FDP_ACC.1/CardLifeCycleManagement F.CARD_MANAGER
FDP_ACF.1/CardLifeCycleManagement F.CARD_MANAGER, F.SYSTEM_MANAGER
FMT_MSA.1/CardLifeCycleManagement F.CARD_MANAGER
FMT_MSA.3/CardLifeCycleManagement F.CARD_MANAGER
FTP_ITC.1/CardLifeCycleManagement F.CARD_MANAGER
FCS_CKM.2/PACE F.AUTHENTICATION
FCS_CKM.3/PACE F.JAVA_API
FCS_COP.1/PACE F.AUTHENTICATION,
F.CRYPTOGRAPHIC_LIBRARY
Table 12 SFRs and TSS - Coverage
TOE Summary Specification Security Functional Requirements
F.OPEN FPT_FLS.1/ODEL, FIA_UID.1/CM, FMT_MSA.1/JCRE,
FMT_SMF.1, FIA_UID.2/AID
F.CARD_MANAGER FDP_ACC.1/CardLifeCycleManagement,
FDP_ACF.1/CardLifeCycleManagement,
FMT_MSA.1/CardLifeCycleManagement,
FMT_MSA.3/CardLifeCycleManagement,
FTP_ITC.1/CardLifeCycleManagement,
FDP_ITC.2/Installer, FMT_SMR.1/Installer,
FPT_FLS.1/Installer, FDP_ACC.2/ADEL, FDP_ACF.1/ADEL,
FMT_MSA.3/ADEL, FMT_SMF.1/ADEL, FMT_SMR.1/ADEL,
FCO_NRO.2/CM, FDP_IFC.2/CM, FDP_IFF.1/CM,
FDP_UIT.1/CM, FIA_UID.1/CM, FMT_MSA.1/CM,
FMT_MSA.3/CM, FMT_SMF.1/CM, FMT_SMR.1/CM,
FTP_ITC.1/CM, FCS_CKM.3
F.JAVA_CARD_SYSTEM FDP_ITC.2/Installer, FPT_FLS.1/Installer,
FPT_RCV.3/Installer, FDP_ACF.1/ADEL, FDP_RIP.1/ADEL,
FMT_MSA.1/ADEL, FMT_MSA.3/ADEL, FPT_FLS.1/ADEL,
FDP_RIP.1/ODEL, FPT_FLS.1/ODEL, FPT_RCV.3/OS,
FPT_FLS.1/OS, FDP_ACC.2/FIREWALL,
FDP_ACF.1/FIREWALL, FDP_IFC.1/JCVM,
FDP_IFF.1/JCVM, FMT_MSA.1/JCVM,
FMT_MSA.2/FIREWALL_JCVM, FMT_MSA.3/FIREWALL,
FMT_MSA.3/JCVM, FMT_SMF.1, FMT_SMR.1, FAU_ARP.1,
FDP_SDI.2, FPT_FLS.1, FPT_TDC.1, FIA_ATD.1/AID,
FIA_UID.2/AID, FIA_USB.1/AID, FMT_MTD.3/JCRE
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 125/130
F.JAVA_API FCS_CKM.3/PACE, FPT_RCV.3/Installer,
FDP_ACF.1/ADEL, FMT_MSA.1/ADEL, FPT_FLS.1/ADEL,
FDP_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL,
FMT_MSA.1/JCRE, FMT_MSA.2/FIREWALL_JCVM,
FMT_MSA.3/FIREWALL, FMT_SMF.1, FCS_CKM.1,
FCS_CKM.2, FCS_CKM.3, FCS_CKM.4,
FDP_RIP.1/TRANSIENT, FAU_ARP.1, FDP_SDI.2,
FPR_UNO.1, FMT_MTD.1/JCRE
F.AUTHENTICATION FCS_CKM.2/PACE, FCS_COP.1/PACE
F.CRYPTOGRAPHY_SERVICES FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4,
FCS_COP.1, FDP_RIP.1/KEYS, FDP_SDI.2, FPR_UNO.1
F.SECRET_DATA_MANAGER FAU_ARP.1
F.SECURE_DATA_MANAGER FPT_FLS.1/OS, FMT_MSA.3/FIREWALL, FAU_ARP.1,
FPR_UNO.1
F.SYSTEM_MANAGER FDP_ACF.1/CardLifeCycleManagement,
FMT_MSA.1/ADEL, FAU_ARP.1, FMT_MTD.1/JCRE,
FMT_MTD.3/JCRE
F.MEMORY_ACCESS FPT_FLS.1/OS, FDP_ACC.2/FIREWALL,
FDP_ACF.1/FIREWALL, FDP_RIP.1/OBJECTS,
FMT_MSA.2/FIREWALL_JCVM, FMT_MSA.3/FIREWALL,
FDP_SDI.2
F.MEMORY_WRITE_MANAGER FPT_RCV.3/OS, FPT_RCV.4/OS, FDP_RIP.1/ABORT,
FDP_ROL.1/FIREWALL, FAU_ARP.1
F.INPUT/OUTPUT_LAYER FDP_RIP.1/APDU, FDP_RIP.1/bArray
F.MEMORY_CONTROLLER FPT_PHP.3/OS, FDP_RIP.1/OBJECTS, FPT_FLS.1
F.TRANSPORT_LAYER FPT_FLS.1
F.CPU_MANAGER FPT_PHP.3/OS
F.SECURITY_CONFIGURATION FPT_PHP.3/OS, FPT_FLS.1
F.CRYPTOGRAPHIC_LIBRARY FCS_COP.1/PACE, FPT_PHP.3/OS, FCS_COP.1,
FDP_RIP.1/KEYS, FPR_UNO.1, FPT_FLS.1
F.SECURITY_AUDIT
F.INTEGRATED_CIRCUIT
Table 13 TSS and SFRs - Coverage
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 126/130
10 Statement of compatibility
The statement of compatibility addresses the specific requirements for composite evaluation as stated
in the document “Composite product evaluation for Smartcards and similar devices” [CCDB_COMP].
The rational explaining how these specific requirements are addressed is presented in the same logical
order than the work item stated in [CCDB_COMP].
10.1Separation of the Platform-TSF
This section describes the separation of relevant SFRs described in the Security Target of the chip
M7892 [ST_IC] being used by this Security Target.
In the following table those SFRs of the IC platform are designated as “relevant” or “used by this
composite ST”. The table also lists irrelevant Platform-SFRs not being used by the Composite-ST.
IC Platform SFRs Usage by TOE, TOE-SFR
FRU_FLT.2
Limited fault tolerance
Not contributing to an SFR of the composite product
FPT_FLS.1
Failure with preservation of
secure state
Contributing to FPT_FLS.1/OS
FMT_LIM.1
Limited capabilities
Not contributing to an SFR of the composite product
FMT_LIM.2
Limited availability
Not contributing to an SFR of the composite product
FAU_SAS.1
Audit storage
Not contributing to an SFR of the composite product
FPT_PHP.3
Resistance to physical attack
The active shielding provides countermeasures against
physical probing and as such provides baseline protection
for the embedded software.
It contributes to :
 FPT_PHP.3 by offering resistance to physical
attacks
FDP_ITT.1
Basic internal transfer
protection
Not contributing to an SFR of the composite product
FPT_ITT.1
Basic internal TSF data transfer
protection
FDP_IFC.1
Subset information flow control
FCS_RNG.1
Random Number Generation
The random number generator of the IC is used for seeding
the software random number generator in the embedded
software. The random numbers contribute to:
 FCS_COP.1: by offering strong random numbers
to the application layer via the Java API
Furthermore, randomization is a key technique to counter
side channel analysis and as such the random number
generator contributes to internal security services.
The composite TOE uses the true random number
generator for seeding the software random number
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 127/130
IC Platform SFRs Usage by TOE, TOE-SFR
generation services.
FPT_TST.2
Subset TOE testing
Not contributing to an SFR of the composite product
FDP_ACC.1
Subset access control
Not contributing to an SFR of the composite product
FDP_ACF.1
Security attribute based access
control
FMT_MSA.3
Static attribute initialisation
The security architecture of the composite product uses the
memory protection unit for protecting sensitive memory
areas from perturbation attacks.
This contribute to : FPT_FLS.1/OS
FMT_MSA.1
Management of security
attributes
The composite product uses the one time programmable
area for irreversible state transiations (like mute card)
which contribute to the preservation of a secure state
The memory protection unit is used by the composite
product to protect sensitive memory segments.
This contribute to : FPT_FLS.1/OS
FMT_SMF.1
Specification of management
functions
The composite product uses the one time programmable
area for irreversible state transiations (like mute card)
which contribute to the preservation of a secure state.
This contribute to : FPT_FLS.1/OS
FCS_COP.1/DES Cryptographic
operation
The cryptographic co-processor is used for the
implementation of high-secure Triple DES computations in
the composite product. Thus, it contributes to:
FCS_COP.1 which offers Triple DES computation
services to the application layer
FCS_COP.1/AES Cryptographic
operation
The cryptographic co-processor is used for the
implementation of high-secure AES computations in the
composite product. Thus, it contributes to:
 FCS_COP.1 which offers AES computation services
to the application layer
FCS_COP.1/RSA Cryptographic
operation
The cryptographic co-processor is used for the
implementation of RSA computations in the composite
product. Thus, it contributes to:
 FCS_COP.1 which offers RSA computation services
to the application layer
FCS_CKM.1/RSA Cryptographic
key generation
The cryptographic co-processor is used for the
implementation of RSA key generation in the composite
product. Thus, it contributes to:
 FCS_CKM.1 which offers RSA key generation
services to the application layer
FCS_COP.1/ECDSA
Cryptographic operation
The cryptographic co-processor is used for the
implementation of ECDSA computations in the composite
product. Thus, it contributes to:
 FCS_COP.1 which offers ECDSA computation
services to the application layer
FCS_CKM.1/EC
Cryptographic key generation
The cryptographic co-processor is used for the
implementation of EC key generation in the composite
product. Thus, it contributes to:
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 128/130
IC Platform SFRs Usage by TOE, TOE-SFR
 FCS_CKM.1 which offers EC key generation
services to the application layer
FCS_COP.1/ECDH Cryptographic
operation
The cryptographic co-processor is used for the
implementation of ECDH computations in the composite
product. Thus, it contributes to:
 FCS_COP.1 which offers ECDH computation
services to the application layer
FCS_COP.1/SHA Cryptographic
operation
The cryptographic co-processor is used for the
implementation of SHA computations in the composite
product. Thus, it contributes to:
 FCS_COP.1 which offers SHA computation services
to the application layer
FDP_SDI.1
Stored data integrity monitoring
The composite TOE uses the automatic and continuous
memory integrity checks: Thus, it contributes to
 FDP_SDI.2 which offers integrity monitoring and
action
FDP_SDI.2
Stored data integrity monitoring
and action
The composite TOE uses the automatic and continuous
memory integrity checks : Thus, it contributes to
 FDP_SDI.2 which offers integrity monitoring and
action
Table 14 Coverage of IC platform SFRs
10.2Statement of compatibility for the security assurance
requirements
This statement of compatibility address the requirement specified in [CCDB_COMP] for the
security assurance requirements.
The security requirement for the underlying IC family specified in the security target [ST_IC] is
EAL6 augmented with the components ALC_FLR.1 where the security assurance requirement for
the composite TOE is EAL5 augmented with the following components: ALC_DVS.2 and
AVA_VAN.5.
Therefore, the security assurance requirements for the composite TOE represent a subset of the
security assurance requirements of the underlying platform.
10.3Statement of compatibility for the security environment and the
objectives
10.3.1 Objectives
There is no conflict between security objectives of the Composite Security Target and the IC
Security Target. Firstly, the composite security target claims conformance to the [PP_JC] wich
in turn claims:
“This Protection Profile does not claim conformance to any other Protection Profile.”
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 129/130
Thus, all security objectives of the IC security target related to [PP_IC] do not introduce a
conflict.
The new security objectives added to the composite security target: O.SCP.IC,
O.SCP.RECOVERY, O.SCP.SUPPORT, O.CARD-MANAGEMENT directly match the corresponding
objectives for the environment defined in [PP_JC] so that also no conflict arises.
The additional of the IC and dedicated software:
 O.Add-Functions Additional Specific Security Functionality;
 O.Mem-Access Area based Memory Access Control.
contribute to the security implementation of the composite product by offering additional security
services.
The additional IC objectives
 OE.Plat-Appl Usage of hardware platform;
 OE.Resp-Appl Treatment of user data;
 OE.Process-Sec-IC Production during composite product manufacturing.
contribute to the security implementation of the composite product by offering additional security
services during the production phases.
To summarise there is no conflict between the security objectives of the composite product and
the underlying platform.
10.3.2 Threats
The threats in the IC security target taken over from the [PP_IC] do not conflict the threats of
the composite product due to the implied protection profile compatibility.
The additional threat of the IC security target “T.Mem-Access” is taken into account the
embedded software by adhering the guidance documentation of the IC.
10.3.3 Organizational security policies
There is no conflict between OSPs of the Composite Security Target and the IC Security Target.
Most of the OSPs of the IC security target define supporting procedures for the embedded
software or the production process of the composite TOE. In detail:
 P.Process-TOE: the precise identification of each TOE instance during IC manufacturing is
a prerequisite for the secure handling in the subsequent production processes.
SECURITY TARGET LITE OF
IDEAL CITIZ V2.16I ON INFINEON M7892 B11
-JAVA CARD OPEN PLATFORM-
Ref.: 2017_2000025699
Page: 130/130
 P.Add-Functions: refers to the implementation of additional security services (like AES,
3DES, SHA-2 etc) for supporting the embedded software, so there is no contradiction
To summarise the organizational security policies of the IC are consistent to the composite
security target.
10.3.4 Assumptions
There is no conflict between assumption of the Composite Security Target and the IC Security
Target. In detail:
 A.Process-Sec-IC: refers to the assumed protection of the IC during packaging and
production. This aspect is covered by A.PRODUCTION in the composite ST (which covers
the handling of the IC during Personaliation) and the life-cycle assessment of ALC_DVS.2
in the composite evaluation (which covers the handling of the IC during OS Flashing and
Pre-Personalisation as well as during Personalisation if the personalization is conducted
in an audited Idemia site);
 A.Plat-Appl: directly linked to the corresponding OE-Plat-Appl;
 A.Resp-Appl: directly linked to the corresponding OE.Resp-Appl;
 A.Key-Function: directly linked to the corresponding OE.Plat-Appl and OE.Resp-Apl.