SECURITY TARGET LITE IDEAL CITIZ V2.1 STC OPEN PLATFORM Reference: 2017_2000031680 Version: 1.0 Issue Date: 06/11/2017 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 2/108 Table of Contents TABLE OF CONTENTS........................................................................................................ 2 TABLE OF FIGURES........................................................................................................... 4 1 TOE REFERENCE.................................................................................................... 5 1.1 TOE IDENTIFICATION ........................................................................................................5 1.2 SECURITY TARGET IDENTIFICATION .......................................................................................5 1.3 TOE DOCUMENTATION .......................................................................................................6 1.4 REFERENCES....................................................................................................................6 1.5 ABBREVIATIONS................................................................................................................7 2 TOE OVERVIEW..................................................................................................... 9 2.1 TOE TYPE.......................................................................................................................9 2.2 USAGE AND MAJOR SECURITY FEATURES OF THE TOE .................................................................9 2.3 REQUIRED NON-TOE HARDWARE/SOFTWARE/FIRMWARE...........................................................10 2.3.1 Off-Card Bytecode Verifier.....................................................................................10 2.3.2 Contact Based Communication ..............................................................................10 2.3.3 Contactless Communication...................................................................................10 2.3.4 Software Components out of TOE Scope ................................................................10 2.4 ACTORS OF THE TOE.......................................................................................................11 3 TOE DESCRIPTION.............................................................................................. 12 3.1 PHYSICAL SCOPE OF THE TOE ............................................................................................12 3.2 LOGICAL SCOPE OF THE TOE .............................................................................................12 3.2.1 IC........................................................................................................................13 3.2.2 Common Operating System...................................................................................13 3.2.3 Java Card System .................................................................................................14 3.2.4 Card Management ................................................................................................14 3.2.5 Cryptographic Library............................................................................................14 3.2.6 PACE API .............................................................................................................15 3.3 LIFE CYCLE....................................................................................................................15 3.3.1 Life Cycle 1 ..........................................................................................................16 3.3.2 Life Cycle 2 ..........................................................................................................17 3.3.3 Life Cycle 3 ..........................................................................................................18 3.3.4 Life Cycle 4 ..........................................................................................................19 3.3.5 Actors ..................................................................................................................20 3.3.6 Description of the TOE environment ......................................................................21 4 COMMON CRITERIA CONFORMANCE CLAIM...................................................... 22 4.1 COMMON CRITERIA CONFORMANCE .....................................................................................22 4.2 CONFORMANCE WITH AN ASSURANCE PACKAGE........................................................................22 4.2.1 AVA_VAN.5 and Industrial Key Length Requirements ..............................................22 4.3 CONFORMANCE WITH A PROTECTION PROFILE ........................................................................23 4.4 CONFORMANCE RATIONALE................................................................................................23 4.4.1 TOE type consistency............................................................................................23 4.4.2 SPD statement consistency....................................................................................23 4.4.3 Security Objectives Consistency.............................................................................23 4.4.4 Consistency of the Security Objectives for the environment.....................................24 4.4.5 Security Requirements Consistency........................................................................24 5 SECURITY ASPECTS ............................................................................................ 25 5.1 CONFIDENTIALITY ......................................................................................................25 5.2 INTEGRITY .................................................................................................................25 5.3 UNAUTHORIZED EXECUTIONS .....................................................................................25 5.4 BYTECODE VERIFICATION...........................................................................................26 5.4.1 CAP FILE VERIFICATION.......................................................................................26 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 3/108 5.4.2 INTEGRITY AND AUTHENTICATION.......................................................................26 5.4.3 LINKING AND VERIFICATION................................................................................26 5.5 CARD MANAGEMENT ...................................................................................................27 5.6 SERVICES ...................................................................................................................27 6 SECURITY PROBLEM DEFINITION...................................................................... 29 6.1 ASSETS ........................................................................................................................29 6.1.1 Java Card System Protection Profile - Open Configuration .......................................29 6.1.2 Card Management ................................................................................................30 6.2 THREATS ......................................................................................................................31 6.2.1 Java Card System Protection Profile - Open Configuration .......................................31 6.2.2 Card Management ................................................................................................33 6.3 ORGANISATIONAL SECURITY POLICIES..................................................................................34 6.3.1 Java Card System Protection Profile - Open Configuration .......................................34 6.3.2 TOE .....................................................................................................................34 6.4 ASSUMPTIONS................................................................................................................35 6.4.1 Java Card System Protection Profile - Open Configuration .......................................35 6.4.2 TOE .....................................................................................................................35 7 SECURITY OBJECTIVES ...................................................................................... 36 7.1 SECURITY OBJECTIVES FOR THE TOE...................................................................................36 7.1.1 Java Card System Protection Profile - Open Configuration .......................................36 7.2 SECURITY OBJECTIVES FOR THE OPERATIONAL ENVIRONMENT ....................................................39 7.2.1 Java Card System Protection Profile - Open Configuration .......................................39 7.2.2 TOE .....................................................................................................................39 7.3 SECURITY OBJECTIVES RATIONALE ......................................................................................40 7.3.1 Threats ................................................................................................................40 7.3.2 Organisational Security Policies..............................................................................45 7.3.3 Assumptions.........................................................................................................45 7.3.4 SPD and Security Objectives..................................................................................46 8 SECURITY REQUIREMENTS ................................................................................ 52 8.1 SECURITY FUNCTIONAL REQUIREMENTS ................................................................................52 8.1.1 TOE .....................................................................................................................52 8.1.2 Java Card System Protection Profile - Open Configuration .......................................52 8.1.3 Operating System .................................................................................................74 8.1.4 Card Life Cycle Management SFRs .........................................................................75 8.1.5 SFRs for PACE API ................................................................................................77 8.2 SECURITY ASSURANCE REQUIREMENTS .................................................................................78 8.3 SECURITY REQUIREMENTS RATIONALE..................................................................................78 8.3.1 Objectives ............................................................................................................78 8.3.2 Rationale tables of Security Objectives and SFRs ....................................................81 8.3.3 Dependencies.......................................................................................................87 8.3.4 Rationale for the Security Assurance Requirements.................................................92 8.3.5 AVA_VAN.5 Advanced methodical vulnerability analysis...........................................92 8.3.6 ALC_DVS.2 Sufficiency of security measures...........................................................92 9 TOE SUMMARY SPECIFICATION......................................................................... 93 9.1 OVERVIEW ....................................................................................................................93 9.2 FUNCTIONALITIES ...........................................................................................................93 9.3 SFRS AND FUNCTIONALITIES .............................................................................................96 9.3.1 SFRs and Functionalities – Rationale ......................................................................96 9.3.2 Association tables of SFRs and TSS...................................................................... 103 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 4/108 Table of figures Figure 1 View of the smartcard and pins............................................................................................................... 12 Figure 2 Product architecture and TOE boundaries................................................................................................ 13 Figure 3 Flashing and generic BlackBox loading at founder site on wafer; pre-personalization on card...................... 17 Figure 4 Flashing and generic BlackBox loading at founder site on wafer; pre-personalization on module ................. 18 Figure 5 Flashing and dedicated BlackBox loading at IDEMIA factory on card; pre-personalization on card ............... 19 Figure 6 Flashing, generic BlackBox loading and pre-personalization at founder site on wafer.................................. 20 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 5/108 1 TOE reference The Target Of Evaluation (TOE) is an open smartcard platform developed by IDEMIA, identified as “IDeal Citiz v2.1 STC 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 STC open platform) is embedded in a smartcard on top of the chip SCR400L manufactured by Starchip. The aim of this security target is to describe:  The Target of Evaluation (TOE), its scope and its security features,  The assets to be protected and the threats to be countered by the TOE and by its operational environment during the product life cycle,  The security objectives of the TOE and its supporting environment in terms of integrity and confidentiality of sensitive informations,  The security requirements which includes the TOE security functional requirements, the TOE security assurance requirements and the security requirements for the environment,  The TOE summary specification. 1.1 TOE Identification The following table summarises the identification of the TOE: TOE Reference Product: IDeal Citiz v2.1 STC open platform TOE Reference OFFICIEL_IDealCitiz_SCR400L_2_1_0_0 _04 Version number: 2.1.0 Date of release 18/10/2017 TOE Identification Method See [AGD_PRE] Origin: IDEMIA Chip Identifier: Starchip SCR400L Chip Ref. Certificate ANSSI-CC-2017/14 1.2 Security Target Identification Security Target identification is described in the table below: ST Identification Title: Security target LITE Ideal Citiz v2.1 STC open platform Version: 1.0 Reference: 2017_2000031680 Origin: IDEMIA Product Identification: IDeal Citiz v2.1 STC open platform Chip Identifier: Starchip SCR400L Chip Ref. Certificate ANSSI-CC-2017/14 Assurance Level: EAL5 augmented with ALC_DVS.2 and AVA_VAN.5 CC Version: 3.1 Release 4 Compliant Protection Profile [PP_JC] Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 6/108 1.3 TOE documentation TOE documentation is described in the table below: TOE documentation Document Title [AGD_PRE] 2015_2000012677 - Preparative Procedure For IDeal Citiz V2.1 STC [AGD_OPE] 2016_2000022279 - Operational User Guidance IDeal Citiz_V2.1 STC 1.4 References Ref. Document title [CC_Part1] Common Criteria for information Technology Security Evaluation, Part 1: Introduction and general model, CCMB-2012-09-001, Version 3.1 – Revision 4, September 2012 [CC_Part2] Common Criteria for information Technology Security Evaluation, Part 2: Security Functional Requirements, CCMB-2012-09-002, Version 3.1 – Revision 4, September 2012 [CC_Part3] Common Criteria for information Technology Security Evaluation, Part 3: Security Assurance Requirements, CCMB-2012-09-003, Version 3.1 – Revision 4, September 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 [JCAPI] Java Card Platform, Application Programming Interface, Classic Edition, Version 3.0.4, 2011. Published by ORACLE. [JCVM] Java Card Platform, Virtual Machine Specification, Classic Edition, Version 3.0.4, September 2011. Published by ORACLE. [JCRE] Java Card Platform, Runtime Environment Specification, Classic Edition, Version 3.0.4, September 2011. Published by ORACLE. [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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 7/108 Ref. Document title [NIST_SP800-90A] Recommendation for Random Number Generation Using Deterministic Random Bit Generators, NIST Special Publication 800-90A, Rev 1, 2015 [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 [RGS_B1] Référentiel Général de sécurité version 2 Annexe B1 Mécanismes cryptographiques, règles et recommandations concernant le choix et le dimensionnement des mécanismes cryptographiques ; version 2.0.3 du 21 février 2014 [ST_IC] SCR400L REV G – Public Security Target - SEC123 v3 – 22/05/2017, Starchip [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 1.5 Abbreviations 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 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 Envrironment JCVM Java Card Virtual Machine OSP Organizational Security Policy PACE Password Authenticated Connection Establishment PM Project Manager PP Protection Profile RNG Random Number Generator RSA Rivest Shamir Adleman Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 8/108 Acronym Definition 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 SPD Security Problem Definition ST Security Target TOE Target Of Evaluation TSF TOE Security Functions VA Verification Authority Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 9/108 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 applet developed by customer or 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 Starchip (STC) SCR400L 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.4 classic edition, September 2011. IDeal Citiz v2.1 STC open platform is an identity document product suitable to the identity market worldwide thanks to its Common Criteria certifications. IDeal Citiz v2.1 STC is a cost effective product, state of the art security 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 cityhall, 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.4 (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  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 assymetric cryptographic algorithm support including Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 10/108 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). 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”. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 11/108 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 12/108 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...) and loaded applications 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 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 STC SCR400L Smartcard integrated circuit. The Figure 2 below shows the different elements that compose the card. The hardware platform is the SCR400L security IC manufactured by Starchip. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 13/108 Figure 2 Product architecture and TOE boundaries The MOSID operating system is a full operating system implementing an open Java Card platform and GP card management. With respect to the TOE scope, the following aspects have to be considered:  the product evaluation is a composite evaluation which re-uses the results of a baseline certification conducted by the IC manufacturer. This baseline evaluation covers the dark-orange-coloured component in the product, namely the integrated circuit IC.  the security functionality implementing core of the system consist of the common operating system, the cryptographic library, the Java Card system and the secured card content management functions as specified by GlobalPlatform. Additionally, the security domain hierarchy which is part of a customer profile has to be taken into account. 3.2.1 IC The SCR400L is a powerful, low-power 32-bit microcontroller, based on APS3sf-ARX core, and SST SuperFlash technology [ST_IC]. SCR400L embeds the state of the art security peripherals and global architecture, StarChip® technology. SCR400L is a contact and/or RF Interface smartcard, communicating through ISO/IEC 7816 or ISO/IEC 14443 protocols. 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 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 14/108  Transaction management  Exception management  Timer management  Interface to cryptographic library 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.4 classic edition; see [JCVM], [JCRE] and [JCAPI]. 3.2.4 Card Management The Card Management (CM) 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  SCP03  Delegated Management (without blacklist support)  DAP Verification and Mandated DAP  RSA key support  CVM  Global Services Management  GET STATUS, completely supported (including tag list) 3.2.5 Cryptographic Library A dedicated cryptographic library has been developed and designed by IDEMIA to provide the highest security level and best tuned performances. It provides the following algorithms:  3DES (56, 112 and 168 bits key length) for en-/decryption (CBC and ECB) and MAC generation and verification (Retail-MAC, CMAC and CBC-MAC) Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 15/108  AES (Advanced Encryption Standard) with key length of 128, 192, and 256 bits for en-/decryption (CBC and ECB) and MAC generation and verification (CMAC, CBC-MAC)  RSA CRT (up to 3072 bits key length) that can be used for: (i) en-/decryption and signature generation and verification; (ii) key pair generation.  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 (see [ST_IC]) that fulfils the requirements of RGS [RGS_B1]. 3.2.6 PACE API The PACE API is part of the TOE and provides the following services:  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.3 Life cycle The following description introduces generics but fine-grained 4 models for the life-cycle of secure smartcard products. The 4 models are compliant to standard smartcard life-cycle models as defined e.g. in [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 4 life-cycles supported for this product (LC1 to LC4). 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 [PP_IC]. 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 16/108 generic blackbox contains only authentication keys. The dedicated blackbox contains keys and specific initialization and personalization values. Moreover, this step includes the configuration (CNF) stage, which is a IDEMIA proprietary card life cycle stage. 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 step 5, since the entire TOE is built and embedded in the Security IC. 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 manufacturer, the inlay manufacturer (for contactless interface) and the embedder. IDEMIA is responsible for the pre-personalization of the card. Finally, the product 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 product is protected by a diversified key derived from a Personalizer dedicated master key. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 17/108 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 IC Configurator Embedder Module manufacturer Personalizer User Module manufacturing Inlay manufacturing Personalization Inlay manufacturer Flashing + Black Box Pre-personalizer CT / DIC CL Figure 3 Flashing and generic BlackBox loading at founder site on wafer; pre-personalization on card 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 is responsible for pre-personalization of the module prior being sent successively to the inlay manufacturer and the embedder. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 18/108 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 ICConfigurator Embedder Module manufacturer Personalizer User Module manufacturing Inlay manufacturing Personalization Inlay manufacturer Pre-personalizer Flashing + Black Box CT / DIC CL Figure 4 Flashing and generic BlackBox loading at founder site on wafer; pre-personalization on module 3.3.3 Life Cycle 3 For this Life Cycle “LC3”, the wafer is manufactured at the founder site. It is then shipped to IDEMIA through the module manufacturer, the inlay manufacturer (for contactless interface) and the embedder in order for IDEMIA to initialize and pre-personalize the card. Finally, the product is shipped to the Personalizer. During the shipment from IDEMIA to the Personalizer, the chip is protected by a diversified key derived from Personalizer dedicated master key. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 19/108 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 Embedding process Card pre-personalization Step 5 Phase 3 Personalization Card initialization 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 Personalization Updating + Black Box Card Configurator Pre-personalizer Erase TOE for future re- use of module / card. Inlay manufacturing Inlay manufacturer CT / DIC CL Flashing + Black Box Figure 5 Flashing and dedicated BlackBox loading at IDEMIA factory on card; pre-personalization on card 3.3.4 Life Cycle 4 For this Life Cycle “LC4”, a custom image is prepared at IDEMIA R&D. The wafer is manufactured and initialized at the founder site. It is then shipped to the Personalizer, successively through the module manufacturer, the inlay manufacturer (for contactless interface) and the embedder. During the shipment from IC manufacturer to the Personalizer, the product is protected by a diversified key derived from a Personalizer dedicated master key. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 20/108 Phase 1 Development Step 1 Embedded software development (custom image) Step 2 IC design and dedicated software development Step 3 Integration Photomask fabrication IC manufacturing Phase 2 Manufacturing Steps 4 & 5 IC initialization Phase 3 Personalization Embedding process Step 6 Phase 4 Usage Usage Step 7 End of life Development sites IC manufacturer IC Configurator Pre-personalizer Embedder Module manufacturer Personalizer User Module manufacturing Inlay manufacturing Personalization Inlay manufacturer Flashing + Black Box + Pre- personalization CT / DIC CL Figure 6 Flashing, generic BlackBox loading and pre-personalization at founder site on wafer 3.3.5 Actors The actors of the smart card product life-cycle are listed on the table below. Actors Identification Covered by Embedded software developer IDEMIA (Osny R&D, Meyreuil R&D and Noida R&D) ALC (R&D sites audit) Integrated Circuit (IC) developer Starchip (Meyreuil R&D) ALC (IC certification) Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 21/108 Actors Identification Covered by Integrated Circuit (IC) manufacturer L-Foundry (Avezzano -Italy-) ALC (IC certification) Integrated Circuit (IC) configurator Nanium (Porto -Portugal-) ALC (IC certification) Card configurator ALC (Ostrava site audit) ALC (Ostrava site audit) Pre-personalizer IDEMIA (Ostrava) ALC (Ostrava site audit) Nanium (Porto -Portugal-) ALC (IC certification) Module manufacturer Nedcard or another CC partner No CC requirement Inlay manufacturer customer defined No CC requirement Embedder IDEMIA (Ostrava) , SELP or an another partner No CC requirement Personalizer 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. AGD_PRE Card Holder / User / Issuer The rightful holder of the card for whom the issuing State or Organization personalizes the card. AGD_OPE Table 1: Actors of the smart card product 3.3.6 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 22/108 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 fulfill 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. In particular, this 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 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 23/108 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.4 conformant to GlobalPlatform 2.1.1, implemented on a chip Starchip of the SCR400L 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, 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. OSP.KEY_GENERATION has been included to control the generated keys. OSP.SHARE-CONTROL has been included to control the shareable interface functionality. 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 is a TOE feature. The assumption A.PRODUCTION has been added because of the TOE life cycle (the TOE can be delivered before step 6). This added assumption does not mitigate any threat and does not 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 24/108 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, 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;  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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 25/108 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. #.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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 26/108 #.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.4.1 CAP FILE VERIFICATION Bytecode verification includes checking at least the following properties: (3) bytecode instructions represent a legal set of instructions used on the Java Card platform; (4) adequacy of bytecode operands to bytecode semantics; (5) absence of operand stack overflow/underflow; (6) control flow confinement to the current method (that is, no control jumps to outside the method); (7) absence of illegal data conversion and reference forging; (8) enforcement of the private/public access modifiers for class and class members; (9) validity of any kind of reference used in the bytecodes (that is, any pointer to a bytecode, class, method, object, local variable, etc actually points to the beginning of piece of data of the expected kind); (10) enforcement of rules for binary compatibility. The actual set of checks performed by the verifier is implementation-dependent, but shall at least enforce all the “must clauses” imposed in [JCVM] on the bytecodes and the correctness of the CAP files’ format. As most of the actual Java Card VMs do not perform all the required checks at runtime, mainly because smart cards lack memory and CPU resources, CAP file verification prior to execution is mandatory. On the other hand, there is no requirement on the precise moment when the verification shall actually take place, as far as it can be ensured that the verified file is not modified thereafter. Therefore, the bytecodes can be verified either before the loading of the file on to the card or before the installation of the file in the card or before the execution, depending on the card capabilities, in order to ensure that each bytecode is valid at execution time. The Security Target assumes bytecode verification is performed off-card. Another important aspect to be considered about bytecode verification and application downloading is, first, the assurance that every package required by the loaded applet is indeed on the card, in a binary-compatible version (binary compatibility is explained in [JCVM]), second, that the export files used to check and link the loaded applet have the corresponding correct counterpart on the card. 5.4.2 INTEGRITY AND AUTHENTICATION Verification off-card is useless if the application package is modified afterwards. The usage of cryptographic certifications coupled with the verifier in a secure module is a simple means to prevent any attempt of modification between package verification and package installation. Once a verification authority has verified the package, it signs it and sends it to the card. Prior to the installation of the package, the card verifies the signature of the package, which authenticates the fact that it has been successfully verified. In addition to this, a secured communication channel is used to communicate it to the card, ensuring that no modification has been performed on it. Alternatively, the card itself may include a verifier and perform the checks prior to the effective installation of the applet or provide means for the bytecodes to be verified dynamically. On-card bytecode verifier is out of the scope of this Security Target. 5.4.3 LINKING AND VERIFICATION Beyond functional issues, the installer ensures at least a property that matters for security: the loading order shall guarantee that each newly loaded package references only packages that have been already loaded on the card. The linker can ensure this property because the Java Card platform does not support dynamic downloading of classes. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 27/108 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 not 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 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 28/108 #.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 (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 [PP_IC]), 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 29/108 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 30/108 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 31/108 6.2 Threats This section describes the threats that concerned the TOE. Only the threat concerning IDeal Citiz v2.1 STC 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 32/108 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 33/108 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. 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 34/108 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 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 35/108 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 36/108 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 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 37/108 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 38/108 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 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). Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 39/108 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. 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. Additionally, the applet shall follow all the recommendations, if any, mandated in the platform guidance for maintaining the isolation property of the platform. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 40/108 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. 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 41/108 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. 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 42/108 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 43/108 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. 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 point (8) of 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 44/108 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 45/108 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 46/108 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.BIO-MNGT, O.REALLOCATION, O.CARD- MANAGEMENT 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, O.FIREWALL, O.GLOBAL_ARRAYS_INTEG, O.ALARM, O.TRANSACTION, O.CIPHER, O.PIN-MNGT, O.KEY- MNGT, O.BIO-MNGT, O.REALLOCATION, O.CARD- MANAGEMENT, OE.CODE- EVIDENCE Section 7.3.1 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 47/108 Threats Security Objectives Rationale 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, O.SCP.RECOVERY, OE.VERIFICATION, O.SID, O.OPERATE, O.FIREWALL, O.GLOBAL_ARRAYS_INTEG, O.ALARM, O.TRANSACTION, O.CIPHER, O.PIN-MNGT, O.KEY- MNGT, O.BIO-MNGT, O.REALLOCATION, O.CARD- MANAGEMENT, OE.CODE- EVIDENCE 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 1- Threats and Security Objectives – Coverage Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 48/108 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, T.APP_DATA_INTEGRITY 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, T.APP_DATA_INTEGRITY O.GLOBAL_ARRAYS_CONFID T.CONFID-APPLI-DATA, T.SID.1 O.GLOBAL_ARRAYS_INTEG T.INTEG-APPLI-DATA, T.SID.1, T.APP_DATA_INTEGRITY 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, T.APP_DATA_INTEGRITY O.REALLOCATION T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA, T.APP_DATA_INTEGRITY O.RESOURCES T.RESOURCES O.ALARM T.CONFID-APPLI-DATA, T.CONFID-JCS- DATA, T.INTEG-APPLI-DATA, T.INTEG- JCS-DATA, T.APP_DATA_INTEGRITY O.CIPHER T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA, T.APP_DATA_INTEGRITY O.KEY-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA, T.APP_DATA_INTEGRITY O.PIN-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA, T.APP_DATA_INTEGRITY O.BIO-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA, T.APP_DATA_INTEGRITY O.TRANSACTION T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA, T.APP_DATA_INTEGRITY 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 49/108 Security Objectives Threats Rationale O.SCP.RECOVERY T.CONFID-APPLI-DATA, T.CONFID-JCS- DATA, T.INTEG-APPLI-DATA, T.INTEG- JCS-DATA, T.SID.2, T.RESOURCES, T.APP_DATA_INTEGRITY 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, T.APP_DATA_INTEGRITY 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, T.INTEG-JCS-DATA, T.EXE-CODE.1, T.EXE-CODE.2, T.NATIVE, T.APP_DATA_INTEGRITY 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, T.APP_DATA_INTEGRITY OE.SECURITY-DOMAINS OE.QUOTAS OE.SHARE-CONTROL T.UNAUTH_ACCESS OE.KEY_GENERATION OE.PRODUCTION Table 2 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 50/108 Organisational Security Policies Security Objectives Rationale OSP.SHARE-CONTROL OE.SHARE-CONTROL Section 7.3.2 Table 3 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 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 51/108 Table 4 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 5 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 6 Security Objectives for the Operational Environment and Assumptions - Coverage Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 52/108 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 STC open platform and a chip SCR400L. The following lists of SFRs are those from the security target [ST_IC] of the Starchip 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 53/108 Group Description Core with Logical Channels (CoreG_LC) The CoreG_LC contains the requirements concerning the runtime environment of the Java Card System implementing logical channels. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 54/108 Subject Description 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 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 55/108 Security attribute Description/Value 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, 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). 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 56/108 Security attribute Description/Value 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. 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). Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 57/108 Operation Description 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 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 58/108 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. 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 59/108 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. 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). Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 60/108 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 61/108 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 3072 bits Proprietary Algorithm 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] 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 62/108 FCS_COP.1 Cryptographic operation FCS_COP.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] 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] 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] Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 63/108 Iteration Operation Algorithm Key Size Standard 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] 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 64/108 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. 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:  CAP file inconsistency,  typing error in the operands of a bytecode,  applet life cycle inconsistency,  card tearing (unexpected removal of the Card out of the CAD) and power failure,  abort of a transaction in an unexpected context, (see abortTransaction(), [JCAPI] and ([JCRE], §7.6.2)  violation of the Firewall or JCVM SFPs,  unavailability of resources,  array overflow, Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 65/108  hidden alarm signalled by the application layer,  failure of explicit integrity checks triggered by the application layer. 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 66/108 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. 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 67/108 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). 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 68/108 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. 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 69/108 Subject/Object Attributes 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 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 70/108 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 71/108 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(). 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 72/108 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 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 73/108 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. 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: Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 74/108 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 application acting inside the smart card on behalf of the Card Issuer from the Card Administrator. 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. FPT_RCV.3.4/OS The TSF shall provide the capability to determine the objects that were or were not capable of being recovered. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 75/108 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 : Subjects: S.CM, S.APPLET, S.CAD; Operations: OP.SET_CARD_STATE. Objects: O.CARD_LC. 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 security attributes of O.CARD_LC: State as defined in [GP_CS] Section 5.1: OP_READY, INITIALIZED, SECURED, CARD_LOCKED, TERMINATED. 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: 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. S.APPLET is allowed to set the Card Life Cycle to CARD_LOCKED if S.APPLET has the Privilege Card Lock Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 76/108 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 authorize 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: If the O.CARD_LC State=TERMINATED, the TOE is disabled, and the access of subjects is no more allowed. 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]. FMT_MSA.3/CardLifeCycleManagement Static Attribute Initialization 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 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 77/108 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 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 FCS_CKM.3/PACE 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 ENC Key for encryption/ decryption getSessionKeyEnc none MAC Key for authentication getSessionKeyMac none FCS_COP.1/PACE 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 Operation Algorithm Key Size Standard Generates and encrypts the nonce, which is used to perform the following operations of a PACE establishment 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 establishment 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] Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 78/108 8.2 Security Assurance Requirements The Evaluation Assurance Level is EAL5 augmented with AVA_VAN.5 and ALC_DVS.2. 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). 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 79/108 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]. 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 80/108 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: 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 81/108 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 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 82/108 Security Objectives Security Functional Requirements Rationale 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 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 83/108 Security Objectives Security Functional Requirements Rationale 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 7 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 84/108 Security Functional Requirements Security Objectives Rationale FDP_IFC.1/JCVM O.FIREWALL, O.GLOBAL_ARRAYS_CONFID, O.GLOBAL_ARRAYS_INTEG FDP_IFF.1/JCVM O.FIREWALL, 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 85/108 Security Functional Requirements Security Objectives Rationale 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 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 86/108 Security Functional Requirements Security Objectives Rationale 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 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/CardLifeCycleManage ment O.CARD-MANAGEMENT FDP_ACF.1/CardLifeCycleManage ment O.CARD-MANAGEMENT FMT_MSA.1/CardLifeCycleManage ment O.CARD-MANAGEMENT FMT_MSA.3/CardLifeCycleManage ment O.CARD-MANAGEMENT FTP_ITC.1/CardLifeCycleManage ment O.CARD-MANAGEMENT FCS_CKM.2/PACE O.CIPHER, O.KEY-MNGT Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 87/108 Security Functional Requirements Security Objectives Rationale FCS_CKM.3/PACE O.CIPHER, O.KEY-MNGT FCS_COP.1/PACE O.CIPHER, O.KEY-MNGT Table 8 SFRs and Security Objectives - Coverage 8.3.3 Dependencies 8.3.3.1 SFRs Dependencies Requirements CC Dependencies Satisfied Dependencies 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 Dependencies 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 Dependencies 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 Dependencies FMT_SMR.1/ADEL (FIA_UID.1) FPT_FLS.1/ADEL No Dependencies FDP_RIP.1/ODEL No Dependencies FPT_FLS.1/ODEL No Dependencies 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 88/108 Requirements CC Dependencies Satisfied Dependencies 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 Dependencies 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 FMT_MSA.3/CM (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/CM, FMT_SMR.1/CM FMT_SMF.1/CM No Dependencies FMT_SMR.1/CM (FIA_UID.1) FIA_UID.1/CM FTP_ITC.1/CM No Dependencies FPT_RCV.3/OS (AGD_OPE.1) AGD_OPE.1 FPT_RCV.4/OS No Dependencies FPT_FLS.1/OS No Dependencies FPT_PHP.3/OS No Dependencies 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 Dependencies 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 (FMT_SMR.1) FDP_ACC.2/FIREWALL, FDP_IFC.1/JCVM, FMT_SMF.1, FMT_SMR.1 FMT_MSA.2/FIREWAL L_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/FIREWAL L (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/JCRE, FMT_MSA.1/JCVM, FMT_SMR.1 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 89/108 Requirements CC Dependencies Satisfied Dependencies FMT_MSA.3/JCVM (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/JCVM, FMT_SMR.1 FMT_SMF.1 No Dependencies 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 FDP_RIP.1/ABORT No Dependencies FDP_RIP.1/APDU No Dependencies FDP_RIP.1/bArray No Dependencies FDP_RIP.1/KEYS No Dependencies FDP_RIP.1/TRANSIEN T No Dependencies 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 Dependencies FPR_UNO.1 No Dependencies FPT_FLS.1 No Dependencies FPT_TDC.1 No Dependencies FIA_ATD.1/AID No Dependencies FIA_UID.2/AID No Dependencies FIA_USB.1/AID (FIA_ATD.1) FIA_ATD.1/AID Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 90/108 Requirements CC Dependencies Satisfied Dependencies 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 FDP_ACC.1/CardLifeC ycleManagement (FDP_ACF.1) FDP_ACF.1/CardLifeCycleMana gement FDP_ACF.1/CardLifeC ycleManagement (FDP_ACC.1) and (FMT_MSA.3) FDP_ACC.1/CardLifeCycleMana gement, FMT_MSA.3/CardLifeCycleMana gement FMT_MSA.1/CardLifeC ycleManagement (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FDP_ACC.1/CardLifeCycleMana gement, FMT_SMF.1/CM, FMT_SMR.1/CM FMT_MSA.3/CardLifeC ycleManagement (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/CardLifeCycleMana gement, FMT_SMR.1/CM FTP_ITC.1/CardLifeCy cleManagement No Dependencies 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) Table 9 SFRs Dependencies Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 91/108 Rationale for the exclusion of Dependencies 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. The dependency FCS_CKM.1 of FCS_CKM.2/PACE, FCS_CKM.3/PACE and 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_CKM.2/PACE, FCS_CKM.3/PACE and FCS_COP.1/PACE is discarded. The FCS_CKM.4 key destruction is operated by the calling application. 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 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 92/108 Requirements CC Dependencies Satisfied 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 10 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 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 93/108 9 TOE Summary Specification 9.1 Overview The TOE includes the following functionalities: F.OPEN F.CARD_MANAGER F.JAVA_CARD_SYSTEM F.JAVA_API F.AUTHENTICAT ION F.CRYPTOGRAPHY_SERV ICES F.SECRET_DATA_MAN AGER F.SECURE_DATA_MAN AGER F.SYSTEM_MANAGER F.MEMORY_ACCESS F.MEMOR Y_ WRITE_M ANAGER F.INPUT/OUTPUT_LAYER F.SECURITY_AU DIT F.MEMORY_CONTROLLER F.TRANSPORT_LAYER F.CPU_MANAGER F.SECURITY_CONFIGURATION F.CRYPTOGRAPHIC_LIBRARY F.INTEGRATED_CIRCUIT 9.2 Functionalities F.OPEN The F.OPEN subsystem provides the following functionalities:  APDU dispatcher  Application invocation F.CARD_MANAGER The F.CARD_MANAGER subsystem provides the following functionalities:  Verification management  Load management  Install management  Issuer Security Domain  Supplementary Security Domain F.JAVA_CARD_SYSTEM The F.JAVA_CARD_SYSTEM subsystem provides the following functionalities: Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 94/108  Virtual machine  Runtime environment  Loader Linker  Garbage collector F.JAVA_API The F.JAVA_API subsystem provides the following functionalities:  GlobalPlatform API  Security and cryptography framework (javacard.security API)  Java Card Framework (javacard.framework API)  Biometric framework (javacardx.biometry API)  Security and cryptography extension (javacardx.security API)  External memory access (javacardx.external API)  Extension framework (javacardx.framework API)  SAC protocol (com.morpho.sac API)  SM accelerator (com.morpho.sm API) F.AUTHENTICATION The F.AUTHENTICATION subsystem provides the following functionalities:  Supplementary access control establishment  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:  Key protection (in non-volatile memory)  Random number generation  Hash computation  Data ciphering and deciphering  CRC computation  Symmetric and asymmetric signature  Elliptic curves diffe-hellman key agreement  Key derivation and generation  Secure channel protocol  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 functionalities:  Biometric authentication algorithms F.SECURE_DATA_MANAGER The F.SECURE_DATA_MANAGER subsystem provides the following functionalities:  PIN management  Key management This sub-system comes in support to F.JAVA_API F.SYSTEM_MANAGER The F.SYSTEM_MANAGER subsystem provides the following functionalities: Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 95/108  System initialization  Configuration dispatcher  Configuration parameters  Non volatile memory protection management  Application registry F.MEMORY_ACCESS The F.MEMORY_ACCESS subsystem provides the following functionalities:  Non volatile memory allocation  Java objects access F.MEMORY_WRITE_MANAGER The F.MEMORY_WRITE_MANAGER subsystem provides the following functionalities:  Transaction and atomicity management  Dynamic RAM allocation F.INPUT/OUTPUT_LAYER The F.INPUT/OUTPUT_LAYER subsystem provides the following functionalities:  Communication initialization  Communication exchange  I/O state management  ATR management  APDU buffer management F.MEMORY_CONTROLLER The F.MEMORY_CONTROLLER subsystem provides the following functionalities:  NVM writing  Memory copy and compare operations F.TRANSPORT_LAYER The F.TRANSPORT_LAYER subsystem provides the following functionalities:  Interface availability control  Time extension management  Contact interface management  Contactless interface management F.CPU_MANAGER The F.CPU_MANAGER subsystem provides the following functionalities:  CPU serial number access  CPU configuration access F.SECURITY_CONFIGURATION The F.SECURITY_CONFIGURATION subsystem provides the following functionalities:  Card security configuration  Card security operations F.CRYPTOGRAPHIC_LIBRARY The F.CRYPTOGRAPHIC_LIBRARY subsystem provides the following functionalities:  DES algorithm operations  AES algorithm operations  SHA algorithm operations Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 96/108  Modular exponentiation operations  Elliptic curves operations  Key protection (in volatile memory)  Utilities  Random number generation  XRC operations  Cryptographic routines F.SECURITY_AUDIT The F.SECURITY_AUDIT subsystem provides the following functionalities:  Security audit and reaction operation F.INTEGRATED_CIRCUIT The F.INTEGRATED_CIRCUIT subsystem provides the following functionalities:  Physical protection mechanisms 9.3 SFRs and Functionalities 9.3.1 SFRs and Functionalities – Rationale F.SECURITY_AUDIT and F.INTEGRATED_CIRCUIT come in support to all other subsystems. Hence, these two functionalities enforce all SFRs. For simplification purposes, they are not listed in this rationale. 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 97/108 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. 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 98/108 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. 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. FAU_ARP.1: Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 99/108 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. 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. 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. FMT_MTD.3/JCRE: Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 100/108 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. 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. 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. 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: Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 101/108 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. 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. 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. 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. Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 102/108 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. 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. 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 IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 103/108 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. 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. 9.3.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 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 104/108 Security Functional Requirements TOE Summary Specification 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.CRYPTOGRAPHIC_LIBRARY, F.SECURITY_CONFIGURATION, F.MEMORY_CONTROLLER, F.TRANSPORT_LAYER 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 Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 105/108 Security Functional Requirements TOE Summary Specification 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 FPT_FLS.1/OS F.JAVA_CARD_SYSTEM, F.SECURE_DATA_MANAGER, F.MEMORY_ACCESS FPT_PHP.3/OS F.MEMORY_CONTROLLER, F.CRYPTOGRAPHIC_LIBRARY, F.SECURITY_CONFIGURATION, F.CPU_MANAGER FDP_ACC.1/CardLifeCycleManagement F.CARD_MANAGER Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 106/108 Security Functional Requirements TOE Summary Specification 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 11 SFRs and TSS – Coverage TOE Summary Specification Security Functional Requirements F.OPEN FMT_MSA.1/JCRE, FMT_SMF.1, FIA_UID.2/AID, FPT_FLS.1/ODEL, FIA_UID.1/CM F.CARD_MANAGER FCS_CKM.3, FMT_SMR.1/Installer, FIA_UID.1/CM, FMT_MSA.3/CM, FMT_SMF.1/CM, FMT_SMR.1/CM, FDP_ITC.2/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, FMT_MSA.1/CM, FTP_ITC.1/CM, FDP_ACC.1/CardLifeCycleManagement, FDP_ACF.1/CardLifeCycleManagement, FMT_MSA.1/CardLifeCycleManagement, FMT_MSA.3/CardLifeCycleManagement, FTP_ITC.1/CardLifeCycleManagement Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 107/108 TOE Summary Specification Security Functional Requirements F.JAVA_CARD_SYSTEM 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_SMR.1, FAU_ARP.1, FPT_FLS.1, FPT_TDC.1, FPT_FLS.1/Installer, FMT_MTD.3/JCRE, FPT_FLS.1/OS, FMT_SMF.1, FIA_USB.1/AID, FPT_RCV.3/Installer, FIA_UID.2/AID, 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, FDP_SDI.2, FIA_ATD.1/AID, FDP_ITC.2/Installer, FPT_RCV.3/OS F.JAVA_API FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FAU_ARP.1, FDP_SDI.2, FPR_UNO.1, FMT_MTD.1/JCRE, FDP_RIP.1/TRANSIENT, FMT_MSA.1/ADEL, FPT_FLS.1/ADEL, FDP_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL, FMT_MSA.2/FIREWALL_JCVM, FMT_MSA.3/FIREWALL, FMT_MSA.1/JCRE, FPT_RCV.3/Installer, FDP_ACF.1/ADEL, FMT_SMF.1, FCS_CKM.3/PACE F.AUTHENTICATION FCS_CKM.2/PACE, FCS_COP.1/PACE F.MEMORY_WRITE_MANAGER FDP_RIP.1/ABORT, FDP_ROL.1/FIREWALL, FAU_ARP.1, FPT_RCV.3/OS , FPT_RCV.4/OS, F.SECURE_DATA_MANAGER FPR_UNO.1, FMT_MSA.3/FIREWALL, FAU_ARP.1, FPT_FLS.1/OS F.SECRET_DATA_MANAGER FAU_ARP.1 F.SYSTEM_MANAGER FAU_ARP.1, FMT_MSA.1/ADEL, FMT_MTD.1/JCRE, FMT_MTD.3/JCRE, FDP_ACF.1/CardLifeCycleManagement F.MEMORY_ACCESS FDP_RIP.1/Objects, FMT_MSA.2/FIREWALL_JCVM, FMT_MSA.3/FIREWALL, FPT_FLS.1/OS, FDP_SDI.2, FDP_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL F.MEMORY_CONTROLLER FDP_RIP.1/OBJECTS, FPT_FLS.1, FPT_PHP.3/OS Security Target LITE IDeal Citiz v2.1 STC open platform Ref.: 2017_2000031680 Page: 108/108 TOE Summary Specification Security Functional Requirements F.INPUT/OUTPUT_LAYER FDP_RIP.1/APDU, FDP_RIP.1/bArray F.TRANSPORT_LAYER FPT_FLS.1 F.CRYPTOGRAPHY_SERVICES FDP_RIP.1/KEYS , FCS_COP.1, FPR_UNO.1, FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4 F.SECURITY_CONFIGURATION FPT_FLS.1, FPT_PHP.3/OS F.CPU_MANAGER FPT_PHP.3/OS F.CRYPTOGRAPHIC_LIBRARY FCS_COP.1, FDP_RIP.1/KEYS, FPR_UNO.1, FPT_PHP.3/OS, FCS_COP.1/PACE, FPT_FLS.1 Table 12 TSS and SFRs – Coverage