FT-JCOS v1.0/0.106.13 Security Target v1.0.12 FEITIAN Technologies Co. Ltd. Website: www.FTsafe.com FT-JCOS v1.0/0.106.13 Security Target Document History Version Date Comments v1.0.0 2015-06-30 First release v1.0.1 2015-11-2 Modify descriptions about TOE and some SFRs v1.0.2 2015-11-16 Correct some errors v1.0.3 2015-11-20 Fix errors for FAU_ARP.1.1, FPR_UNO.1.1, FPT_TDC.1.2 and so on v1.0.4 2015-11-23 Correct descriptions of FCS_RNG and FPT_EMSEC v1.0.5 2015-11-23 Update version number of user guidances v1.0.6 2015-11-25 Correct the conformance to demonstrable conformance in section 3.2 v1.0.7 2016-1-6 Update version number of user manual v1.0.8 2016-1-31 Update version number of administrator manual and add a table for TOE physical scope v1.0.9 2016-2-22 Update version numbers of TOE and administrator manual v1.0.10 2016-3-1 Add real version numbers for TOE identification v1.0.11 2016-3-4 Add OS version in the title v1.0.12 2016-4-8 Replace EAL 4 with EAL 5 for TOE assurance level Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com II FT-JCOS v1.0/0.106.13 Security Target Contents 1 Introduction 1 1.1 ST Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 TOE Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2 TOE Overview 2 2.1 TOE TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 Usage and Major Security Features of the TOE . . . . . . . . . . . . . . . . . . . . . . 3 2.3 Required non-TOE Hardware/Software/Firmware . . . . . . . . . . . . . . . . . . . . . 3 2.3.1 The Bytecode Verifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.4 TOE Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4.1 Java Card Platform components . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4.2 TOE Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4.3 Modularization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.5 Phases and Roles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.6 TOE Life Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.7 TOE Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3 Conformance Claims 14 3.1 CC Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2 PP Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3 PP Conformance Claim Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4 Security Aspects 16 4.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3 Unauthorized Executions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4 Bytecode Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4.1 CAP File Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.4.2 Integrity and Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.4.3 Linking and Verification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5 Card Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.6 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com III FT-JCOS v1.0/0.106.13 Security Target 5 Security Problem Definition 21 5.1 Assets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.1 User Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1.2 TSF Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.2.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.3 Identity Usurpation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.4 Unauthorized Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.5 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.6 Card Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2.7 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2.8 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.3 Organization Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6 Security Objectives 27 6.1 TOE Security Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.1 Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.2 Execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1.4 Object deletion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.1.5 Applet management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.2 Security Objectives For The Operational Environment . . . . . . . . . . . . . . . . . . 30 6.3 Security Objectives Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.3.1 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.3.1.1 Confidentiality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.3.1.2 Integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.3.1.3 Identity Usurpation . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.3.1.4 Unauthorized Execution . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3.1.5 Denial Of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3.1.6 Card Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3.1.7 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3.1.8 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3.1.9 Threats Composite Platform . . . . . . . . . . . . . . . . . . . . . . . 35 6.3.2 Organizational Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.3.3 Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.3.4 SPD and Security Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 7 Security Requirements 40 7.1 TOE Security Functional Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com IV FT-JCOS v1.0/0.106.13 Security Target 7.1.1 Coreg_LC Security Functional Requirements . . . . . . . . . . . . . . . . . . . 43 7.1.1.1 FIREWALL POLICY . . . . . . . . . . . . . . . . . . . . . . . . . . 43 7.1.1.2 Application Programming Interface . . . . . . . . . . . . . . . . . . . 49 7.1.1.3 Card Security Management . . . . . . . . . . . . . . . . . . . . . . . 53 7.1.1.4 AID Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 7.1.2 InstG Security Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 56 7.1.3 ADELG Security Functional Requirements . . . . . . . . . . . . . . . . . . . . 59 7.1.4 ODELG Security Functional Requirements . . . . . . . . . . . . . . . . . . . . 62 7.1.5 CarG Security Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 62 7.1.6 GPG Security Functional Requirements . . . . . . . . . . . . . . . . . . . . . . 66 7.1.7 SCPG Security Functional Requirements . . . . . . . . . . . . . . . . . . . . . 67 7.2 TOE Security Assurance Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.3 Security Requirements Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.1.1 Security Objectives for the TOE . . . . . . . . . . . . . . . . . . . . 68 7.3.2 Rationale tables of Security Objectives and SFRs . . . . . . . . . . . . . . . . . 71 7.3.3 Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.3.3.1 SFRs dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.3.3.2 SARs Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 7.3.4 Rationale for the Security Assurance Requirement . . . . . . . . . . . . . . . . 77 7.3.5 ALC_DVS.2 Sufficiency of security measures . . . . . . . . . . . . . . . . . . 77 7.3.6 AVA_VAN.5 Advanced methodical vulnerability analysis . . . . . . . . . . . . 78 7.4 Extended Components Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.4.1 Definition of the Family FCS_RNG . . . . . . . . . . . . . . . . . . . . . . . . 78 7.4.2 Definition of the Family FPT_EMSEC . . . . . . . . . . . . . . . . . . . . . . 78 8 TOE Summary Specification 80 8.1 Security Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 8.1.1 GLOBALPLATFORM’s TOE Security Functionality . . . . . . . . . . . . . . . 82 8.1.1.1 SF.Card Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 8.1.1.2 SF.Secure Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 8.1.1.3 SF.Secure Channel Key Management . . . . . . . . . . . . . . . . . . 83 8.1.1.4 SF.Global PIN Management . . . . . . . . . . . . . . . . . . . . . . . 84 8.1.2 Java Card TOE Security Functionality . . . . . . . . . . . . . . . . . . . . . 84 8.1.2.1 SF.Java Card Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.1.2.2 SF.End User Authentication . . . . . . . . . . . . . . . . . . . . . . . 84 8.1.2.3 SF.Sensitive Data Cleaner . . . . . . . . . . . . . . . . . . . . . . . . 84 8.1.2.4 SF.Atomic_Transactions . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.1.2.5 SF.Security Violation . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.1.2.6 SF.PIN integrity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com V FT-JCOS v1.0/0.106.13 Security Target 8.1.2.7 SF.Key Management . . . . . . . . . . . . . . . . . . . . . . . . . . 85 8.1.2.8 SF.Cryptographic Operations . . . . . . . . . . . . . . . . . . . . . . 85 8.2 Statement of Compatibility Concerning Composite Security Target . . . . . . . . . . . . 86 8.3 Assumptions and OSP of the Platform for its Operational Environment . . . . . . . . . . 87 8.4 Threats of the Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 8.5 Security Objectives Mapping of the Platform . . . . . . . . . . . . . . . . . . . . . . . 88 8.6 Separation of the Platform-TSF by TOE SFR . . . . . . . . . . . . . . . . . . . . . . . 88 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com VI FT-JCOS v1.0/0.106.13 Security Target List of Figures 2.1 Java Card Platform Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 TOE Physical Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 TOE components within the Java Card Platform . . . . . . . . . . . . . . . . . . . . . . 5 2.4 Java Card Platform and applet installation environment . . . . . . . . . . . . . . . . . . 8 2.5 TOE life Cycle within Smart Card Life Cycle . . . . . . . . . . . . . . . . . . . . . . . 11 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com VII FT-JCOS v1.0/0.106.13 Security Target List of Tables 2.1 Major Security Features of the JCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 TOE Physical Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6.1 Threats and Security Objectives — Coverage . . . . . . . . . . . . . . . . . . . . . . . 36 6.2 Security Objectives and Threats — Coverage . . . . . . . . . . . . . . . . . . . . . . . 37 6.3 OSPs and Security Objectives — Coverage . . . . . . . . . . . . . . . . . . . . . . . . 38 6.4 Security Objectives and OSPs — Coverage . . . . . . . . . . . . . . . . . . . . . . . . 38 6.5 Assumptions and Security Objectives for the Operational Environment — Coverage . . . 38 6.6 Security Objectives for the Operational Environment and Assumptions — Coverage . . . 39 7.1 Security Functional Requirements overview . . . . . . . . . . . . . . . . . . . . . . . . 40 7.2 Subjects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.3 Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.4 Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 7.5 Security attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.6 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.7 Security Objectives and SFRs — Coverage . . . . . . . . . . . . . . . . . . . . . . . . 72 7.8 SFRs and Security Objectives Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 73 7.9 SFRs dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.10 SARs dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 8.1 SFRs dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com VIII FT-JCOS v1.0/0.106.13 Security Target Chapter 1 Introduction This chapter provides the identification of the Security Target presents its general structure and introduces key notions used in the following chapters. 1.1 ST Reference Title: FT-JCOS v1.0/0.106.13 Security Target Version: 1.0.12 Publication data: April, 2016 Sponsor: Feitian Technologies Co., Ltd, Floor 17th, Tower B, Huizhi Mansion, No.9 Xue- qing Road Haidian District, Beijing, P.R China Editor: Feitian Technologies Co., Ltd 1.2 TOE Reference TOE identification/version: FT-JCOS v1.0/0.106.13 TOE Hardware ID: M7892 B11 (Smart Card IC) TOE Platform Commercial ID: SLE78CLFX4000PM with the cryptographic library RSA-EC- SHA-2-Toolbox(Platform. Certification ID: BSI-DSZ-CC-0782- 2012) TOE Documents: FT-JCOS v1.0/0.106.13 Administrator Manual v 1.0.5 FT-JCOS v1.0/0.106.13 User Manual v 1.0.4 Editor: Feitian Technologies Co., Ltd Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 1 FT-JCOS v1.0/0.106.13 Security Target Chapter 2 TOE Overview This chapter defines the Target of Evaluation (TOE) type and describes the main security features of the TOE, the components of the TOE environment, the TOE life-cycle and TOE intended usage. The TOE is an open Java Card Platforms (JCP), that is, smart cards or similar devices enabled with Java Card technology that support post-issuance downloading of applications. Figure 1 shows the TOE, composed of a Smart Card Platform (SCP) and an embedded software (JCS 1 + non-TSF parts 2 ). The JCP is compliant with Java Card Specification v2.2.2 and GlobalPlatform Specification v.2.1.1. As the TOE allows for the loading of applets before or after the issuance of the card, these applets should have been previously verified by an off-card trusted IT component. The JCP is managed by Card Manager that is a part of the TOE. The Card Manager(ISD) is a pre-issuance applet. The JCP is fully compliant with the Java Card Specification v2.2.2 excluding the optional part JCRMI which is not implemented by the TOE. There is another pre-issuance applet which is named rootapplet installed. The rootapplet is used for getting/setting JCP information. e.g ATR and so on. The SCP is a certified hardware platform – the SLE78CLFX4000PM with RSA2048 v1.02.013, EC v1.02.013, and Toolbox v1.02.013 libraries and with specific IC dedicated software (firmware). The hardware platform is certified by the BSI under the certification ID: BSI-DSZ-CC-0782-2012 the corresponding Security Target Lite is [ST_IC]. Not all functionality of the hardware is used by the “com- posite TOE”3 . Therefore some parts of the IC platform are not part of the “composite TOE”. Figure 2.1: Java Card Platform Overview This TOE provides the security of an EAL5+ evaluated card with the flexibility of an open platform. 1The JCS covers the software TOE part developed by Feitian Technologies Co., Ltd the Java Card RE, JC VM, JC API, Card Manager, GP API, Native code to be embedded on the SLE 78 chip. 2The non-TSF parts represent the modules which are out of the TOE Security Functionality scope but are part of the TOE. 3A “composite TOE” includes the SCP which has been already evaluated and the Embedded Software under evaluation. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 2 FT-JCOS v1.0/0.106.13 Security Target 2.1 TOE TYPE The TOE is a Java Card Platform compliant with Java Card Specification v.2.2.2 and GlobalPlatform Specification v.2.1.1. The TOE allows post-issuance downloading of applications that have been previ- ously verified by an off-card trusted IT component. It constitutes a secure generic platform that supports multi-application runtime environment and provides facilities for secure loading and interoperability be- tween different applications. The TOE does not implement JCRMI and does not include any software on the application layer. 2.2 Usage and Major Security Features of the TOE The TOE is a generic, secure platform that implements Java Card Specification v.2.2.2 and GlobalPlatform Specification v.2.1.1, and it allows post-issuance downloading of applications that have been previously verified by an off-card trusted IT component. But not all functionality provided by JCP are included in the TOE. The table below lists major parts of the TOE dividing them into TSF and non-TSF parts. Components TSF parts Non-TSF parts SCP Micro Controller ISO 7816 Interface Mifare- compatible interface ISO 14443 A/B Interface Crypto2304T SCP(AES and TDES) TRNG Crypro Library IC dedicated software RSA Toolbox EC(prime and binary) Firmware parts Embedded Software Protocol SCP02, SCP03 SCP01 Cryptographic Algorithms ECDSA(prime and binary) MD5 SHA-2 SHA-1 ECDH(prime and binary) RSA TDES AES RSA Key generation onboard EC Key generation onboard Table 2.1: Major Security Features of the JCP For a detailed description of the cryptographic algorithms implemented by the TOE please refer to defi- nition of the FCS_COP elements in 7.1.1.2. 2.3 Required non-TOE Hardware/Software/Firmware The security of TOE relies on the following the required non-TOE hardware/software/firmware. 2.3.1 The Bytecode Verifier The bytecode verifier is a program that performs static checks on the bytecodes of the methods of a CAP file prior to the execution of the file on the card. 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 3 FT-JCOS v1.0/0.106.13 Security Target The TOE does not implement a bytecode verifier and fully relies on the off-card bytecode verification that has to be performed before a file is loaded on the card. Different approaches have been proposed for the implementation of bytecode verifiers, most notably data flow analysis, model checking and lightweight bytecode verification, this latter being an instance of what is known as proof carrying code. The actual set of checks performed by the verifier is implementation dependent, but it is required that it should at least enforce all the “must clauses” imposed of [JCVM222, 7] on the bytecode and the correctness of the CAP files’ format. 2.4 TOE Description The Java Card System (Java Card RE, Java Card VM, Java Card API, Card Manager, GlobalPlatform and the additional native code) is embedded in a Smart Card Platform. The Java Card RE, Java Card VM and Java Card API are compliant with Java Card specifications version 2.2.2, including post-issuance downloading of applications verified off-card. All functionalities provided by the JCS are included in the TOE. The figure below shows the physical scope of the TOE outlined in red rectangle, which is referred from [SLE78-DATASHEET]. All JCP embeded software is run on this certified hardware. Figure 2.2: TOE Physical Scope The hardware platform is mainly consisted of those component shown in above figure: • Core The core houses the dual CPU the cache, a memory management unit (MMU), an error de- tection unit (EDU) and a memory encryption/decryption unit (MED). • Memories The memory types used are RAM (random access memory) and NVM (nonvolatile memory), which used to store the code and persistent data of FT-JCOS. • Coprocessors The controller provides coprocessors to support cryptographic operations, includ- ing Symmetric Crypto Processor (SCP) for DES, AES and Crypto@2304T for public key crypto algorithms, e.g. RSA, ECC. • Security Peripherals It consists of sophisticated features, including error detection units, a set Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 4 FT-JCOS v1.0/0.106.13 Security Target of sensors, regulators and filters along with an enhanced signal shield to detect faults as well as electrical and physical conditions, and initiate alarms to indicate security breaches • Peripherals It consists of timers, random generators, RF(contactless communication inter- face),UART(contact communication interface). • Control The control unit houses the ITP (interrupt controller including peripheral event channels), an interface management module (IMM), the clock unit and the power management. All hardware components mentioned above are in the physical scope of the TOE,and the following doc- uments are also in the TOE physical scope: • FT-JCOS v1.0/0.106.13 Administrator Manual v1.0.5, it is for card issuer to maintain TOE security functionalities during card prepersonalization. • FT-JCOS v1.0/0.106.13 User Manual v1.0.4, it is the security guidance for Java card application developer to ensure that the developed applet has sufficient ability to counter attacks In summary, the items in TOE physical scope are listed in following table. Table 2.2: TOE Physical Scope Component Name Version Hardware M7892 B11 Embedded Software FT-JCOS v1.0 0.106.13 Document FT-JCOS v1.0/0.106.13 Administrator Manual v 1.0.5 Document FT-JCOS v1.0/0.106.13 User Manual v 1.0.4 The figure below shows the design of TOE outlining the TSF parts and non-TSF parts. Figure 2.3: TOE components within the Java Card Platform All components of JCP are core components, clearly illustrated in the figure above. Core components implement core functionality of the JCP and are required for all possible configurations. The core compo- nent group is made up of modules from the Java Card Platform, version 2.2.2 (green) the GlobalPlatform 2.1.1 (blue), and also the Secure Smart Card Controller (purple). In the figure’s legend “TSF” indicates the component is part of the TOE Security Functionality. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 5 FT-JCOS v1.0/0.106.13 Security Target 2.4.1 Java Card Platform components In the following sections the core components that belong to the TOE Security Functionality are indicated with (TSF) and the core components that are not part of the TOE Security Functionality are indicated with (non-TSF). Secure Smart Card Controller The IC consists of a core system, co-processors, memories, security modules, peripherals and analogue peripherals. The major components of the core system are the two CPUs (Central Processing Units), the MMU (Memory Management Unit) and MED (Memory Encryption/Decryption Unit). The co-processor block contains the processors for RSA/EC and DES/AES processing, while the peripheral block contains the random number generation (True Random Number Generator) and the external interfaces service. This dual interface controller is able to communicate using either the contact based or the contactless interface. Hardware Abstraction Layer The implemented dual interface provides a maximum flexibility in using following communication pro- tocols: • ISO 7816 (I/O Library)(TSF), • ISO 14443 Type A and Type B (RF Library) (TSF), As well as further communication modes (non-TSF), allowing also the implementation of user defined concepts for contact based or contactless communication. This package provides a framework for efficiently accessing the TOE’s chip functionality. • (Crypto Library): this module covers the low-level cryptographic operations mostly using crypto- graphic hardware accelerators. • (HAL): this module covers the low-level basic memory operations and other system level operation for the SLE78 chip. Provided service abstracts operations from underlying hardware service. Smart Card Kernel The Smart Card Kernel relies on the Smart Card Platform providing memory management, cryptography engine and input/output. Java Card Layer Java Card technology combines a subset of the Java programming language with a runtime environment optimized for smart cards and related small-memory embedded devices. Java Card technology brings many of the benefits of the Java programming language to the resource-constrained world of smart cards. The following are components of the Java Card Layer: • Java Card 2.2.2 APIs (there are APIs that are not included in the TSF scope, that are the API which implement the functionality listed in the third column of Table 2.1) The application programming interface for Java Card. • Java Card 2.2.2 Virtual Machine (TSF) The Java Card virtual machine is a subset of the Java virtual machine, and is designed to be run on smart cards and other resource-constrained devices. The Java Card virtual machine acts as an engine that loads Java class files and executes them with a particular set of semantics. • Java Card 2.2.2 Runtime Environment (TSF) A framework for running Java programs on the card. GlobalPlatform Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 6 FT-JCOS v1.0/0.106.13 Security Target GlobalPlatform Card Specification 2.1.1 is an industry standard add-on layer that consists of a set of packages and APIs that standardize smart card functionality and provide a standardized infrastructure for the development, deployment and management of smart cards. The following are components of the GlobalPlatform: • Card Manager (TSF) The card manager is an application with specific rights, which defined in the GlobalPlatform speci- fication to enable the secure downloading of applications. The card manager implements the Glob- alPlatform Environment (OPEN), the Issuer Security Domain and Cardholder verification Method Services. The card manager is in charge of the life cycle of the whole card, as well as the installed applications (applets). It is the controller of the card, but relies on the TOE to manage the runtime of client applets. • Additional Security Domains (TSF) Security Domains are privileged Applications as specified in the GlobalPlatform specification and it is implemented by Feitian. Security Domains are responsible for their own key management. An Application can use the cryptographic security services of its associated Security Domain. Cryp- tographic security provided by the security domains frees the applications from having to directly use Java Card platform functionality to implement security themselves. The card supports multiple, dynamically configured Security Domains whose number is limited only by the available NVM. The card manager usually functions as a security domain called the Issuer Security Domain (ISD). The ISD is often the sole security domain, although the card can contain additional security domains called Supplementary Security Domains (SSDs). • Secure Channels(SCP02) (TSF) A Secure channel is a communication mechanism between an off-card entity and a card that pro- vides a level of assurance to one or both entities. The TOE supports Secure Channel Protocols SCP02 as defined in the GlobalPlatform specification. • GlobalPlatform API (GPv2.1.1 APIs)(TSF) The GlobalPlatform API provides services to applications. It also provides card content manage- ment services such as card locking and provides application life cycle state updates to applications. • Card Content Management (TSF) The card content management component governs loading, installation, extradition, registry update and removal of card content. • GlobalPlatform Runtime Environment(GP v2.1.1 Runtime)(TSF) The runtime environment provides an API for applications as well as a secure storage and execution space for applications that ensures that each application’s code and data can remain separate and secure from other applications on the card. The card’s runtime environment is also responsible for providing communication services between the card and off-card entities. • GlobalPlatform Life Cycle (GP lifecycle) (TSF) The life cycle component is responsible for maintaining the overall security and administration of the card and its contents throughout its life cycle. 2.4.2 TOE Security Features The TOE implements the Java Card Specifications versions 2.2.2 as specified by the Java Card Protection Profile - Open Configuration ([PP]). Since the TOE does not implement an on-card bytecode verifier, only application verified by an off-card verifier may be downloaded to the card. In the post-issuance stage where the applications may be loaded to the TOE in an adversary environment, the authenticity and the integrity of the files to be loaded are secured by means of mechanisms defined in [GP211]. The next figure illustrates the process of integration of a new applet into TOE. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 7 FT-JCOS v1.0/0.106.13 Security Target 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ava Ca d Sy em On Ca d Loade Sma Ca d P a o m Ca d Manage On Ca d n a e CRE CAP CVM N a v e C o d e App e New App e OFF CARD ON CARD cap O Ca d Ce e O Ca d Loade Expo F e Load ng w hou ce ca on au ho y Load ng w h ce ca on au ho y App e TOE F gure 2 4 Java Card P a form and app e ns a a on env ronmen The deve opmen of he app e s s carr ed on n a Java programm ng env ronmen The comp a on of he code produces he correspond ng c ass f e Then h s a er f e s processed by he conver er 4 wh ch va da es he code and genera es a conver ed app e (CAP) f e he equ va en of a Java c ass f e for he Java Card p a form A CAP f e con a ns an execu ab e b nary represen a on of he c asses of a package A package s a namespace w h n he Java programm ng anguage ha may con a n c asses and n erfaces and n he con ex of Java Card echno ogy def nes e her a user brary or one or severa app e s Then he off-card by ecode ver f er checks he CAP f e Af er he va da on s carr ed ou he CAP f e has o be oaded n o he card by means of a safe oad ng mechan sm The secure oad ng mechan sm prov ded by he TOE s mp emen ed accord ng o G oba P a form spec f ca on I prov des means for preserv ng of au hen c y and n egr y of he f es ver f ed pr or by he off-card ver f er The oad ng of a f e n o he card embod es wo ma n s eps F rs an au hen ca on s ep by wh ch he card ssuer and he card recogn ze each o her as spec f ed n [GP211] Once he den f ca on s ep s accomp shed he CAP f e s ransm ed o he card Due o resource m a ons usua y he f e s sp by he card ssuer n o a s of App ca on Pro oco Da a Un s (APDUs) wh ch are n urn sen o he card Each of hese APDUs can be guaran eed he r au hen c y and n egr y Once oaded n o he card he f e s nked wha makes poss b e n urn o ns a f def ned ns ances of any of he app e s def ned n he f e Dur ng he ns a a on process he app e s reg s ered on he card by us ng an app ca on den f er (AID) Th s AID w a ow he den f ca on of un que app e ns ances w h n he card In par cu ar he AID s used for se ec ng he app e ns ance for execu on In some cases he ac ua ns a a on (and reg s ra on) of app e s s pos poned n he same ve n a package may con a n severa app e s and some of hem m gh never be ns a ed Ins a a on s hen usua y separa ed from he process of oad ng and nk ng a CAP The conve e s de ned n he spec ca ons JCVM222 as he o ca d componen o he Java Ca d v ua mach ne Copy gh © 2016 Fe an Techno og es Co L d Webs e www FTsa e com 8 FT-JCOS v1.0/0.106.13 Security Target file on the card. The installer is the Java Card Layer component dealing with loading, linking and installation of new packages, as described in [JCRE222]. Once selected, it receives the CAP file, stores the classes of the package on the card, initializes static data, if any, and installs any applets contained in the package. The installer is also in charge of applet deletion as specified in [JCRE222, 11.3.4]. The Java Card VM is the bytecode interpreter as specified in [JCVM222]. The Java Card RE is responsible for card resource management, communication, applet execution, on-card system and applet security. The Java Card API 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. While the Java Card VM is responsible for ensuring language-level security, the Java Card RE provides additional security features for Java Card technology-enabled devices. Applets from different vendors can coexist in a single card, and they can even share information. An applet, however, is usually intended to store highly sensitive information, so the sharing of that information must be carefully limited. In the Java Card platform, applet isolation is achieved through the applet firewall mechanism [JCRE222, 6.1]. That mechanism confines an applet to its own designated memory area, thus each applet is prevented from accessing fields and operations of objects owned by other applets, unless a “shareable interface” is explicitly provided (by the applet who owns it) for allowing access to that information. The Java Card RE allows sharing using the concept of “shareable interface objects” (SIO) and static public variables. Java Card VM dynamically enforces the firewall, that is, at runtime. However applet isolation cannot be entirely granted by the firewall mechanism if certain integrity conditions are not satisfied by the ap- plications loaded on the card. Those conditions can be statically verified to hold by a bytecode verifier [JCRE222, 6.2.6]. The Java Card VM ensures that the only way for applets to access any resources are either through the Java Card RE or through the Java Card API (or other vendor-specific APIs). This objective can only be guaranteed if applets are correctly typed (all the “must clauses” imposed in chapter 7 of [JCVM222] on the bytecodes and the correctness of the CAP file format are satisfied). The TOE does not implement an on-card verifier and fully relays on the off-card verifier. Each file must be verified by means of a trustful off-card verifier before loading into the card. The TOE provides security means according to [GP211] with which the Issuer can preserve authenticity and integrity of the files to be loaded in an adversary environment. JCRMI is optional in version 2.2.2 and it is not included in this Security Target and out of the scope of this TOE. Logical channels allow a terminal to open multiple sessions into the smart card, one session per logical channel [JCRE222, 4]. Commands may be issued on a logical channel to instruct the card either to open or to close a logical channel. An applet instance that is selected to be active on a channel shall process all the commands issued to that channel. The platform also introduces the possibility for an applet instance to be selected on multiple logical channels at the same time, or accepting other applets belonging to the same package to be selected simultaneously. These applets are referred to as multiselectable. A non- multiselectable applet can be active at most on one channel. Applets within a package are either all multiselectable or all non-multiselectable. The TOE implements the Card Manager (CM). 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 Java Card RE. The card manager is in charge of the life cycle of the whole card, as well as the installed applications (applets). It is conformant to the GlobalPlatform Card Specification [GP211] and is the management of security domains and enforcement of the card issuer security policies. The card manager’s role is also to manage and control the communication between the card and the card acceptance device (CAD) or the proximity-coupling device (PCD) 5 . It is the controller of the card, but relies on the TOE to manage the runtime of client applets. 5The acronym CAD is used here and throughout this specification to refer to both types of card readers - the conventional Card Acceptance Device (CAD) for contacted I/O interfaces and the Proximity Coupling Device (PCD) for contactless interfaces. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 9 FT-JCOS v1.0/0.106.13 Security Target 2.4.3 Modularization The JCP can be configured with a dedicated set of complete modules. Please refer to 2.3 for an overview of the TSF and non-TSF of the TOE. 2.5 Phases and Roles • Platform Developer (Feitian Technologies Co., Ltd, Phase 1): Designs and implements the Em- bedded Software (JCS + non-TSF parts) to be embedded on the IC. • Chip/IC Manufacturer (Infineon, Phases 2-5): Designs and implements the IC (SLE 78 chip) and prepares the packaging. The Chip Manufacturer prepares the smart card for platform initializa- tion, modularizes the platform, modifies the Static Configuration parameters in the configuration table, merges the template image received by the Composite Product Integrator and may load the embedded software to the IC during wafer testing. • Composite Product Integrator (Infineon, Phase 5): Pre-personalizes the smart card content by storing personalization data such as the SD keys or the public DAP verification key and install new Java Card Applets (pre-issuance). He can configure the TOE and do flashing. Configuration includes setting or changing the dynamic parameters of the card configuration table. He can run system tests to validate a template image candidate, load template or create a card template image (template dump) and send it back to the Chip Manufacturer for merging. The Composite Product Integrator integrates the Embedded Software within the IC (SLE78 chip) in order to produce a final smart card product ready for delivery to the Card Issuer. Note that Pre-issuance applet loading is enabled technically nevertheless no identified applets are to be loaded in pre-issuance in the scope of this evaluation. Otherwise, this will fall into the composite evaluation (Application upon Platform). • Card Issuer (Phases 6-7): Issues smart cards to the Application Providers and the Cardholders. The Card Issuer controls the smart card’s content and life cycle management during and after the platform being initialized, he personalizes the card by storing application user data. • Cardholder (Phase 7): is the holder of the final smart card product (IC + Embedded Software + Application(s)). • Application Provider/Developer (Phases 6-7): Develops Java Card applications providing ser- vices to the Cardholder requested by the Card Issuer. Application Providers are represented on the card by Supplementary Security Domains and depending on their privileges they can for instance download and install new Java Card Applets, modify the SSD keys, etc. • Verification Authority (Phases 6-7): Is mainly responsible for the bytecode verification of the Java Card Applets loaded onto the TOE in post-issuance and checks that the Application Provider followed the operational security guidance documentation. 2.6 TOE Life Cycle The TOE life cycle is part of the product life cycle, reaching from the first development steps to the final delivery to the end user. The TOE is delivered at the end of phase 5. The TOE life cycle phases are those detailed in Figure 4. We refer to [PP0084] for a thorough description of Phases 1 to 7 of the Smart Card but the current scenario modifies the owner roles and places where the phases take place: • Phases 1 and 2 compose the product development: Embedded Software (JCS + non-TSF parts development) and IC development. • Phase 3 and Phase 4 correspond to IC manufacturing and packaging, respectively. Some IC initialisation/pre-personalisation steps may occur in Phase 3. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 10 FT-JCOS v1.0/0.106.13 Security Target • Phase 5 concerns the embedding of software components within the IC. The Embedded Software flash image is securely stored, pre-personalized and tested on the TOE at the composite product integrator premises. • Phase 6 is dedicated to the product personalisation prior final use. • Phase 7 is the product operational phase. The Embedded Software (JCS + non-TSF parts) life cycle is composed of four stages: • Embedded Software Development • Embedded Software Storage, pre-personalisation and testing • Embedded Software Personalisation • Embedded Software Final usage. Embedded Software storage is not necessarily a single step in the life cycle since it can be stored in parts. These stages map to the typical smart card life cycle phases as shown in the following figure. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 11 FT-JCOS v1.0/0.106.13 Security Target Figure 2.5: TOE life Cycle within Smart Card Life Cycle The Embedded Software (JCS + non-TSF parts) Development is performed during Phase 1 by the Plat- form Developer (Feitian Technologies Co., Ltd). This includes Embedded Software conception, design, implementation, testing and documentation. The Embedded Software development fulfils requirements of the final TOE, including conformance to Java Card Specifications, and recommendations of the SCP user guidance. The Embedded Software development occurs in a secure audited environment maintaining the confidentiality of source code, data and any critical documentation and preserving the integrity of these elements. The evaluation of this product includes the Embedded Software development environment. Phase 2 covers the Secure IC Development of Infineon and is out of scope of the TOE evaluation as that is part of the IC platform evaluation. In Phase 3, the Chip Manufacturer (Infineon) stores and pre-personalizes the Embedded Software. The delivery from Feitian Technologies Co., Ltd to Infineon of the Embedded Software (as a flash image) occurs at the beginning of Phase 3 (before the Chip Manufacturer performs his tasks). Delivery and ac- ceptance procedures maintain the authenticity, the confidentiality and integrity of the exchanged delivery. The Embedded Software flash image delivery is done encrypted and signed. It requires therefore a pre- vious secure exchange of public keys. The evaluation of this TOE includes the delivery process of the Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 12 FT-JCOS v1.0/0.106.13 Security Target Embedded Software flash image to the Chip Manufacturer. The Chip Manufacturer configures the TOE and applies the modularization (removal of optional code modules, integration of sandbox code, and configuration of the Embedded Software runtime switches) and can optionally merge the data template image received by the Composite Product Integrator (template merge). The Security IC Manufacturing environment protects the integrity and confidentiality of the Em- bedded Software and of any related material, for instance test suites. The evaluation of this TOE includes the whole Secure IC Manufacturing environment, in particular those locations where the Embedded Soft- ware is accessible for installation and testing. This certification process is based on the Common Criteria hardware certificate BSI-DSZ-CC-0782-2012-MA-01 and reuses the hardware evaluation testing results accordingly. At the end of Phase 3, the Chip Manufacturer • delivers a flash image of the Embedded Software to the Composite Product Integrator through an encrypted APDU sequence (for “flashing”) • sends masked chips (IC with Embedded Software configured and/or merged, loaded via Wafer- Testing @ IFX) Phase 4, is the IC packaging in Infineon and is part of the evaluation of the underlying platform. The process steps dealing with the hardware as such at the involved production sites were subject of hardware related site audits and are covered by the above mentioned hardware certificate. Nevertheless, the audit and evaluation of the templating processes at Infineon was not covered by the BSI-DSZ-CC-0782-MA01. During Phase 5, The Composite Product Integrator securely pre-personalizes the TOE (Key exchange, Security Domains management, Applet Loading). Then, the TOE is delivered to the Card Issuer for final personalization. A Composite Product Integrator can perform one of the following options: 1. Pre-personalize the TOE by template loading on the configured Embedded Software. 2. Perform a template dump and use it for further production steps: • template merge done by the IC manufacturer or • template load done by the Composite Product Integrator). 3. If applicable, Pre-personalize the TOE by flashing 6 the encrypted flash image of the configured Embedded Software 7 . The pre-personalization steps in Phase 5 are done on the Composite Product Integrator’s production sites. TOE pre-personalization covers the TOE configuration tuning (changes to the configuration table stat- ic/dynamic parameters), storing pre-perso data (e.g. IFX card info) in the CPLC audit records following GP specs, storing Keys, etc. Note that pre-personalization could also happen in Phase 3 where Static Configuration Parameters could be changed whereas in phase 5, only Dynamic Configuration Parameters could be changed. The delivery of the TOE (in the sense of the CC) to the Card Issuer is performed at the end of Phase 5 by the role Composite Product Integrator, i.e. Infineon. Besides, the Flash Loader 8 could be used if needed during phase 5 but is finally locked before the TOE delivery to Phase 6. Note that the complete phase 5 with all its production steps is performed by the role Composite Product Integrator and that for the scope of this evaluation this role is exclusively filled out by Infineon (and its specific template dump, load and merge production steps as well as flash loading). The Embedded Software is personalized in Phase 6. Note that this evaluation covers the Embedded Software development phase and all the TOE production phases where the Embedded Software is involved. 6“Flashing” is storing code and data in the Solid Flash ®NVM using the IFX Flash Loader Mechanism. 7An Embedded Software is considered configured once it has been initialized by the configuration data (via the configuration tool) and modularization was done. 8The Flash Loader is a firmware allowing the composite product integrator to download his code, or just parts of it, to the empty flash memory of the TOE. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 13 FT-JCOS v1.0/0.106.13 Security Target The Security Functional Requirements of the TOE are available only in the TOE Operational Phase of the smart card life cycle from the Personalization step in Phase 6 (once the card has been initialized) to the final operational usage in Phase 7. The preparation and personalization phases of the Embedded Software are covered by dedicated Preparation Guidance documents for the Composite Product Integrator and the IC Manufacturer. 2.7 TOE Usage Smart cards are used as data carriers that are secure against forgery and tampering as well as personal, highly reliable, small size devices capable of replacing paper transactions by electronic data processing. Data processing is performed by a piece of software embedded in the smart card chip, called an applica- tion. The Java Card System is intended to transform a smart card into a platform capable of executing appli- cations written in a subset of the Java programming language. The intended use of a Java Card platform is to provide a framework for implementing IC independent applications conceived to safely coexist and interact with other applications into a single smart card. Applications installed on a Java Card platform can be selected for execution when the card communicates with a card reader. Notice that these applications may contain other confidentiality (or integrity) sensitive data than usual cryptographic keys and PINs; for instance, passwords or pass-phrases are as confidential as the PIN, or the balance of an electronic purse. Typical applications are: • Financial applications, like Credit/Debit ones, stored value purse, or electronic commerce, among others. • Transport and ticketing, granting pre-paid access to a transport system like the metro and bus lines of a city. • Telephony, through the subscriber identification module (SIM) or the NFC chip for mobile phones. • Personal identification, for granting access to secured sites or providing identification credentials to participants of an event. • Electronic passports and identity cards. • Secure information storage, like health records, or health insurance cards. • Loyalty programs, like the “Frequent Flyer” points awarded by airlines. Points are added and deleted from the card memory in accordance with program rules. The total value of these points may be quite high and they must be protected against improper alteration in the same way that currency value is protected. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 14 FT-JCOS v1.0/0.106.13 Security Target Chapter 3 Conformance Claims 3.1 CC Conformance This Security Target claims to be conformant to version 3.1 of Common Criteria for Information Tech- nology Security Evaluation according to • [CC1] • [CC2] • [CC3] The following methodology will be used for the evaluation. • [CEM] Conformance of this ST is claimed for: Common Criteria part 2 extended by FPT_EMSEC.1, and FC- S_RNG.1 and Common Criteria part 3 conformant. All assurance components are taken from part 3. The Evaluation Assurance Level is EAL 5 augmented by AVA_VAN.5 “Advanced methodical vulnerability analysis” and ALC_DVS.2 “Sufficiency of security measures”. 3.2 PP Conformance This Security Target is in demonstrable conformance to [PP]. 3.3 PP Conformance Claim Rationale The differences between this ST and the claimed Protection Profile are described below: • This ST includes the SCP and the GlobalPlatform card manager to the composite product scope. • The following security objectives for the operational environment have been moved to se- curity objectives for the TOE in this ST: OE.CARD-MANAGEMENT (now: O.CARD- MANAGEMENT), OE.SCP.IC (now O.IC_SUPPORT), OE.SCP.RECOVERY (now O.RECOVERY), OE.SCP.SUPPORT (now O.OS_SUPPORT). • The SFRs of the new group GPG were included to map the functionality of the SCP; the group SCPG contains the functionality to support the hardware platform. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 15 FT-JCOS v1.0/0.106.13 Security Target • The following security objectives for the TOE were introduced: O.COMMUNICATION and O.RND. • The JCRMI functionality is not part of the TOE, so the related objective O.REMOTE is not includ- ed. This is intended by the [PP]. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 16 FT-JCOS v1.0/0.106.13 Security Target Chapter 4 Security Aspects This section is partly taken from [PP]. This chapter describes the main security issues of the Java Card System and its environment addressed in this Protection Profile, 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. 4.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 disclo- sure. 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 disclo- sure. 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. 4.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 appli- cation 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 17 FT-JCOS v1.0/0.106.13 Security Target #.INTEG-JCS-CODE Java Card System code must be protected against unauthorized modi- fication. 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 modifi- cation. 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. 4.3 Unauthorized Executions #.EXE-APPLI-CODE Application (byte)code must be protected against unauthorized execu- tion. This concerns (1) invoking a method outside the scope of the accessibility rules provided by the access modifiers of the Java pro- gramming language ([JAVASPEC, 6.6]); (2) jumping inside a method fragment or interpreting the contents of a data memory area as if it was executable code; (3) unauthorized execution of a remote method from the CAD (if the TOE provides JCRMI functionality). #.EXE-JCS-CODE Java Card System bytecode must be protected against unauthorized ex- ecution. 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 pro- gramming language ([JAVASPEC, 6.6]); (2) jumping inside a method fragment or interpreting the contents of a data memory area as if it was executable code. Note that execute access to native code of the Java Card System and applications is the concern of #.NATIVE. #.FIREWALL The Firewall shall ensure controlled sharing of class instances1 , 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 privi- leged in this respect, exceptions to the policies must include a rationale for the new security framework they introduce. 4.4 Bytecode Verification #.VERIFICATION Bytecode must be verified prior to being executed. Bytecode verifica- tion includes how well-formed CAP file is and the verification of the typing constraints on the bytecode, 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. 4.4.1 CAP File Verification Bytecode verification includes checking at least the following properties: (3) bytecode instructions rep- resent a legal set of instructions used on the Java Card platform; (4) adequacy of bytecode operands to 1This concerns in particular the arrays, which are considered as instances of the Object class in the Java programming language. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 18 FT-JCOS v1.0/0.106.13 Security Target 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 mem- bers; (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 (full details are given in [JCVM222], [JVM], [JCBV]). The actual set of checks performed by the verifier is implementation-dependent, but shall at least enforce all the “must clauses” imposed in [JCVM222] 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. This Protection Profile 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 [JCVM222, 4.4]), second, that the export files used to check and link the loaded applet have the corresponding correct counterpart on the card. 4.4.2 Integrity and Authentication Verification off-card is useless if the application package is modified afterwards. The usage of crypto- graphic 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. 4.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. 4.5 Card Management #.CARD- MANAGEMENT (1) The card manager (CM) shall control the access to card manage- ment functions such as the installation, update or deletion of applets. (2) The card manager shall implement the card issuer’s policy on the card. #.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 (what- ever 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 oper- ation, 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 19 FT-JCOS v1.0/0.106.13 Security Target #.SID (1) Users and subjects of the TOE must be identified. (2) The iden- tity of sensitive users and subjects associated with administrative and privileged roles must be particularly protected; this concerns the JCRE, 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). A change of identity, especially standing for an administra- tive role (like an applet impersonating the JCRE), is a severe violation of the TOE Security Policy (TSP). 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) Era- sure, 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 se- curity 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 by- pass 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. Dele- tion of installed applets (or packages) is implemented by erasure its reference of table. (3) Power failure or other failures during the pro- cess 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 ei- ther 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). 4.6 Services #.ALARM The TOE shall provide appropriate feedback upon detection of a po- tential security violation. This particularly concerns the type errors de- tected by the bytecode verifier, the security exceptions thrown by the JCVM, or any other security-related event occurring during the execu- tion 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 20 FT-JCOS v1.0/0.106.13 Security Target #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 alloca- tion) of applications and packages. #.CIPHER The TOE shall provide a means to the applications for ciphering sensi- tive data, for instance, through a programming interface to low-level, highly secure cryptographic services. In particular, those services must support cryptographic algorithms consistent with cryptographic usage policies and standards. #.KEY-MNGT The TOE shall provide a means to securely manage cryptographic keys. This includes: (1) Keys shall be generated in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes, (2) Keys must be distributed in accordance with specified cryptographic key distribution methods, (3) Keys must be initialized before being used, (4) Keys shall be destroyed in accordance with spec- ified cryptographic key destruction methods. #.PIN-MNGT The TOE shall provide a means to securely manage PIN objects. This includes: Atomic update of PIN value and try counter, (2) No rollback on the PIN-checking function,(3) Keeping the PIN value (once initialized) se- cret (for instance, no clear-PIN-reading function), (4) Enhanced protec- tion of PIN’s security attributes (state, try counter...) in confidentiality and integrity. #.SCP The smart card platform must be secure with respect to the TSP. Then: (1) 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 se- cure state. (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 process- ing 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 memo- ry, 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 ex- ceptions, checksum errors), when applicable. We finally require that (7) the IC is designed in accordance with a well-defined set of poli- cies 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 common- ly employed techniques (physical probing and sophisticated analysis of the chip). This especially matters to the management (storage and operation) of cryptographic keys. Note: For this TOE a certified hardware platform is used (see 2). #.TRANSACTION The TOE must provide a means to execute a set of operations atom- ically. This mechanism must not endanger the execution of the user applications. The transaction status at the beginning of an applet ses- sion must be closed (no pending updates). Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 21 FT-JCOS v1.0/0.106.13 Security Target Chapter 5 Security Problem Definition This chapter describes the security problem to be addressed by the TOE and the operational environment of the TOE. The description is based on [PP] additional details of [PP0084]. 5.1 Assets Assets are security-relevant elements to be directly protected by the TOE. Confidentiality of assets is always intended with respect to untrusted 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. 5.1.1 User Data D.APP_CODE The code of the applets and libraries loaded on the card. To be protected from unauthorized modification. Note: This asset includes the code of the GlobalPlatform Framework on the card. 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 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 22 FT-JCOS v1.0/0.106.13 Security Target Any end-user’s PIN. To be protected from unauthorized disclosure and modification. D.CM_APDUs The APDU commands addressed to the Issuer Security Domain triggering a card management service. To be protected from unauthorized modification. In the case where an APDU contains a confidential asset such as the CM_KEYS value, this asset must be protected from unauthorized disclosure. 5.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. D.JCS_KEYS The cryptographic keys used when loading an executable file on the card. To be protected from unauthorized disclosure and modification. D.SEC_ATTRIBUTES The remaining security attributes related to the different security functionalities such as the number of remaining tries used during the cardholder authentication, the data contained in the GP registry (AID, privileges, lifecycle state, ...), etc. To be protected from unauthorized modification. 5.2 Threats 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 23 FT-JCOS v1.0/0.106.13 Security Target 5.2.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 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, D.JCS_KEYS and D.CRYPTO. 5.2.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 trans- mitted to the card for installation. See #.INTEG-APPLI-CODE for details. Directly threatened asset(s): D.APP_CODE T.INTEG-APPLI-DATA The attacker executes an application to alter (part of) another application’s data. See #.INTEG-APPLI-DATA for details. Directly threatened asset(s): D.APP_I_DATA, D.PIN and D.APP_KEYs. T.INTEG-APPLI-DATA.LOAD The attacker modifies (part of) the initialization data contained in an application package when the pack- age is transmitted to the card for installation. See #.INTEG-APPLI-DATA for details. Directly threatened asset(s): D.CM_APDU, 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.SEC_ATTRIBUTES, 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 24 FT-JCOS v1.0/0.106.13 Security Target 5.2.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 D.APP_KEYs and D.JCS_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). 5.2.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-JCSCODE and #.EXE-APPLI-CODE for details. Directly threatened asset(s): D.APP_CODE. T.NATIVE An applet executes a native method to bypass a TOE Security Function such as the firewall. See #.NA- TIVE for details. Directly threatened asset(s): D.JCS_DATA. 5.2.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. 5.2.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 instal- lation 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 suc- ceed, depending on the virulence of the installed application). Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 25 FT-JCOS v1.0/0.106.13 Security Target T.COMMUNICATION The attacker exploits the communication channel established between the TOE and CAD to modify or disclose confidential data. Directly threatened asset(s): D.CM_APDUs, D.SEC_DATA and D.APP_CODE (DATA (any other asset may be threatened). 5.2.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. 5.2.8 Miscellaneous T.PHYSICAL The attacker discloses or modifies the design of the TOE, its sensitive data or application code by phys- ical (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. 5.3 Organization Security Policies This section describes the organizational security policies to be enforced with respect to the TOE envi- ronment. 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 recommendations related to the isolation property of the platform, this policy shall also ensure that the verification authority checks that these recommendations are applied in the application code. 5.4 Assumptions 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” ([JCVM222, 3.3]) outside the API. A.DELETION Deletion of applets through the card manager is secure. Refer to #.DELETION for details on this assump- tion. A.VERIFICATION All the bytecodes are verified at least once, before the loading, before the installation or before the ex- ecution, depending on the card capabilities, in order to ensure that each bytecode is valid at execution Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 26 FT-JCOS v1.0/0.106.13 Security Target 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 ver- ification. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 27 FT-JCOS v1.0/0.106.13 Security Target Chapter 6 Security Objectives 6.1 TOE Security Objectives This section defines the security objectives to be achieved by the TOE. 6.1.1 Identification O.SID The TOE shall uniquely identify every subject (applet, or package) before granting it access to any service. 6.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. 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. Application note: To be made unavailable means to be physically erased with a default value. Except for local variables that do not correspond to method parameters, the default values to be used are specified in [JCVM222]. O.RESOURCES Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 28 FT-JCOS v1.0/0.106.13 Security Target The TOE shall control the availability of resources for the applications. See #.RESOURCES for details. 6.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#.KEYMNGT. O.PIN-MNGT The TOE shall provide a means to securely manage PIN objects. See#.PIN-MNGT for details. Application note: PIN objects may play key roles in the security architecture of client applications. The way they are stored and managed in the memory of the smart card must be carefully considered, and this applies to the whole object rather than the sole value of the PIN. For instance, the try counter’s value is as sensitive as that of the PIN. O.TRANSACTION The TOE must provide a means to execute a set of operations atomically. See#.TRANSACTION for details. Application note: O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION and O.CIPHER are actually pro- vided 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. 6.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. 6.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. Application note: Usurpation of identity resulting from a malicious installation of an applet on the card may also be the result of perturbing the communication channel linking the CAD and the card. Even if the CAD is placed in a secure environment, the attacker may try to capture, duplicate, permute or modify Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 29 FT-JCOS v1.0/0.106.13 Security Target the packages sent to the card. He may also try to send one of its own applications as if it came from the card issuer. Thus, this objective is intended to ensure the integrity and authenticity of loaded CAP files. 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. O.COMMUNICATION The TOE shall authenticate the origin of the card management requests that the card receives, and au- thenticate itself to the remote actor. It shall verify the integrity of the card management requests that it receives and be able, when it’s needed, to process card management requests containing encrypted data. O.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): 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 com- munication 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.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 appli- cations (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. Application note: The actor performing the card management operation must beforehand authenticate with the Security Domain. In the case of Delegated Management privilege, the card management command will be associated with an electronic signature (Verification token) verified by the ISD before execution. O.IC_SUPPORT The SCP shall provide all IC security features against physical attacks. This security objective refers to the point (7) of the security aspect#.SCP: It is required that the IC is designed in accordance with a well-defined set of policies and Standards (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.OS_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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 30 FT-JCOS v1.0/0.106.13 Security Target (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). O.RND Random Numbers. The TOE will ensure the cryptographic quality of random number generation. For instance random numbers shall not be predictable and shall have sufficient entropy. The TOE will ensure that no information about the produced random numbers is available to an attacker since they might be used for instance to generate cryptographic keys 6.2 Security Objectives For The Operational Environment 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. Application Note: Constraints to maintain the isolation property of the platform are provided by the platform developer in application development guidance. The constraints apply to all application code loaded in the platform. OE.CODE-EVIDENCE For application code loaded pre-issuance, evaluated technical measures implemented by the TOE or au- dited 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 ap- plication 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 ver- ifier is out of the scope of this Protection Profile. Application Note: For application code loaded post-issuance and verified off-card, the integrity and au- thenticity evidence can be achieved by electronic signature of the application code, after code verification, by the actor who performed verification. 6.3 Security Objectives Rationale The following parts in comparison with the [PP] have been changed: The objective of the environment in the PP OE.CARD-MANAGEMENT is changed to the ob- jective O.CARD- MANAGEMENT of the TOE. The objective of the environment in the PP OE.SCP.IC is changed to O.IC_SUPPORT. OE.SCP.RECOVERY is replaced by O.RECOVERY and OE.SCP.SUPPORT is replaced by O.OS_SUPPORT. O.RND is also included, as the hardware platform provides the TRNG. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 31 FT-JCOS v1.0/0.106.13 Security Target 6.3.1 Threats 6.3.1.1 Confidentiality T.CONFID-APPLI-DATA This threat is countered by the security objective for the operational environment regarding byte- code 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.RECOVERY and O.OS_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, 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.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 re- source shared by all applications. The disclosure of such data is prevented by the security objective O.GLOBAL_ARRAYS_CONFID. Finally, any attempt to read a piece of information that was previously used by an application but has been logically deleted is countered by the O.REALLOCATION objective. That objective states that any information that was formerly stored in a memory block shall be cleared before the block is reused. T.CONFID-JCS-CODE This threat is countered by the list of properties described in the (#.VERIFICATION) security aspect. Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. As none of those instructions enables reading a piece of code, no Java Card applet can therefore be executed to disclose a piece of code. Native applications are also harmless because of the objective O.NATIVE, so no application can be run to disclose a piece of code. The (#.VERIFICATION) security aspect is addressed in this ST by the objective for the environment OE.VERIFICATION. The objectives O.CARD-MANAGEMENT and OE.VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode, respectively. 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.RECOVERY and O.OS_SUPPORT are intended to support the O.OPERATE and Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 32 FT-JCOS v1.0/0.106.13 Security Target O.ALARM objectives of the TOE, so they are indirectly related to the threats that these latter objectives contribute to counter. 6.3.1.2 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 envi- ronment 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 au- thenticity 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 identifi- cation 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 au- thenticity. The objectives O.RECOVERY and O.OS_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 objec- tives 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 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.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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 33 FT-JCOS v1.0/0.106.13 Security Target 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 envi- ronment 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 identifi- cation 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 integri- ty and authenticity. The objectives O.RECOVERY and O.OS_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. 6.3.1.3 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 34 FT-JCOS v1.0/0.106.13 Security Target 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.RECOVERY and O.OS_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. 6.3.1.4 Unauthorized Execution T.EXE-CODE.1 Unauthorized execution of a method is prevented by the objective OE.VERIFICATION. This threat par- ticularly 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 con- trol 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). 6.3.1.5 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.RECOVERY and O.OS_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. 6.3.1.6 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 35 FT-JCOS v1.0/0.106.13 Security Target 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. T.COMMUNICATION This threat is covered by the security objective O.COMMUNICATION security objective which authen- ticates the origin of the card management. The objective O.CARD-MANAGEMENT controls the access to card management functions and thus contributes to cover this threat. 6.3.1.7 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. 6.3.1.8 Miscellaneous T.PHYSICAL Covered by O.IC_SUPPORT. Physical protections rely on the underlying platform. The objective O.RND controls the cryptographic quality of random number generation which covers together with O.IC_SUPPORT the point (7) of the security aspect#.SCP, extracting cryptographic keys. 6.3.1.9 Threats Composite Platform T.LEAKAGE An attacker may exploit information which is leaked from the TOE during usage of the Smart Card in order to disclose the confidential assets (TSF data or User data). No direct contact with the Smart Card Internals is required here. Leakage may occur through emanations, variations in power consumption, I/O characteristics, clock frequency, or by changes in processing time requirements. One example is the Differential Power Analysis (DPA). O.RND ensures the cryptographic quality of random number generation, which counters the threat. O.IC_SUPPORT covers the threat as the IC is tamper resistant. T.FAULT An attacker may cause a malfunction of TSF by applying environmental stress in order to (1) deactivate or modify security features or functions of the TOE or (2) deactivate or modify security functions of the Smart Card. This may be achieved by operating the Smart Card outside the normal operating conditions. O.IC_SUPPORT covers the threat with the IC security features against physical attacks. O.RND ensures the cryptographic quality of random number generation, which counters the threat. The following threat is copied from [PP0084]: T.RND Deficiency of Random Numbers. An attacker may predict or obtain information about random numbers generated by the TOE for instance because of a lack of entropy of the random numbers provided. An attacker may gather information about the produced random numbers which might be a problem because they may be used for instance to generate cryptographic keys. Here the attacker is expected to take advantage of statistical properties of the random numbers generated Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 36 FT-JCOS v1.0/0.106.13 Security Target by the TOE without specific knowledge about the TOE’s generator. Malfunctions or premature ageing are also considered which may assist in getting information about random numbers. This is directly covered by O.RND and O.IC_SUPPORT covers the threat with the IC security features against physical attacks. 6.3.2 Organizational Security Policies 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. 6.3.3 Assumptions 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 ver- ification. 6.3.4 SPD and Security Objectives Table 6.1: Threats and Security Objectives — Coverage Threats Security Objectives Rationale T.CONFID-APPLI- DATA O.RECOVERY, O.OS_SUPPORT, O.CARD- MANAGEMENT, OE.VERIFICATION, O.SID, O.OPERATE, O.FIREWALL, O.GLOBAL_ARRAYS_CONFID, O.ALARM, O.TRANSACTION, O.CIPHER, O.PIN-MNGT, O.KEY- MNGT, O.REALLOCATION, Section 6.3.1 T.CONFID-JCS-CODE OE.VERIFICATION, O.CARD-MANAGEMENT, O.NATIVE, Section 6.3.1 T.CONFID-JCS-DATA O.RECOVERY, O.OS_SUPPORT, O.CARD- MAN- AGEMENT, OE.VERIFICATION, O.SID, O.OPERATE, O.FIREWALL, O.ALARM, Section 6.3.1 T.INTEG-APPLI-CODE O.CARD-MANAGEMENT, OE.VERIFICATION, O.NATIVE, OE.CODE-EVIDENCE, Section 6.3.1 T.INTEG-APPLI- CODE.LOAD O.LOAD, O.CARD-MANAGEMENT, OE.CODE- EVIDENCE Section 6.3.1 T.INTEG-APPLI-DATA O.RECOVERY, O.OS_SUPPORT, O.CARD- MANAGEMENT, 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.REALLOCATION, OE.CODE-EVIDENCE Section 6.3.1 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 37 FT-JCOS v1.0/0.106.13 Security Target T.INTEG-APPLI- DATA.LOAD O.LOAD, O.CARD-MANAGEMENT, OE.CODE- EVIDENCE Section 6.3.1 T.INTEG-JCS-CODE O.CARD-MANAGEMENT, OE.VERIFICATION, O.NATIVE, OE.CODE- EVIDENCE, Section 6.3.1 T.INTEG-JCS-DATA O.RECOVERY, O.OS_SUPPORT, O.CARD- MANAGEMENT, OE.VERIFICATION, O.SID, O.OPERATE, O.FIREWALL, O.ALARM, OE.CODE- EVIDENCE, Section 6.3.1 T.SID.1 O.CARD-MANAGEMENT, O.FIREWALL, O.GLOBAL_ARRAYS_CONFID, O.GLOBAL_ARRAYS_INTEG, O.INSTALL, O.SID Section 6.3.1 T.SID.2 O.RECOVERY, O.OS_SUPPORT, O.SID, O.OPERATE, O.FIREWALL, O.INSTALL Section 6.3.1 T.EXE-CODE.1 OE.VERIFICATION, O.FIREWALL Section 6.3.1 T.EXE-CODE.2 OE.VERIFICATION Section 6.3.1 T.NATIVE OE.VERIFICATION, OE.APPLET, O.NATIVE Section 6.3.1 T.RESOURCES O.INSTALL, O.OPERATE, O.RESOURCES, O.RECOVERY, O.OS_SUPPORT Section 6.3.1 T.DELETION O.DELETION, O.CARD-MANAGEMENT Section 6.3.1 T.INSTALL O.INSTALL, O.LOAD, O.CARD-MANAGEMENT Section 6.3.1 T.COMMUNICATION O.CARD-MANAGEMENT, O.COMMUNICATION Section 6.3.1 T.OBJ-DELETION O.OBJ-DELETION Section 6.3.1 T.PHYSICAL, T.LEAKAGE, T.FAULT, T.RND O.IC_SUPPORT, O.RND Section 8.4 Table 6.2: Security Objectives and Threats — Coverage Security Objectives Threats O.SID T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA, T.INTEG- APPLI-DATA, T.INTEG-JCS-DATA, T.SID.1, T.SID.2 O.FIREWALL T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA, T.INTEG- APPLI-DATA, T.INTEG-JCS-DATA, T.SID.1, T.SID.2, T.EXE- CODE.1 O.GLOBAL_ARRAYS_CONFID T.CONFID-APPLI-DATA, T.SID.1 O.GLOBAL_ARRAYS_INTEG T.INTEG-APPLI-DATA, T.SID.1 O.NATIVE T.CONFID-JCS-CODE, T.INTEG-APPLI-CODE, T.INTEG-JCS- CODE, T.NATIVE O.OPERATE T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA, T.INTEG- APPLI-DATA, T.INTEG-JCS-DATA, T.SID.2, T.RESOURCES O.REALLOCATION T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA O.RESOURCES T.RESOURCES O.ALARM T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA, T.INTEG- APPLI-DATA, T.INTEG-JCS-DATA O.CIPHER T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA O.KEY-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA O.PIN-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA O.TRANSACTION T.CONFID-APPLI-DATA, T.INTEG-APPLI-DATA O.OBJ-DELETION T.OBJ-DELETION O.DELETION T.DELETION O.LOAD T.INTEG-APPLI-CODE.LOAD, T.INTEG-APPLI-DATA.LOAD, T.INSTALL O.INSTALL T.SID.1, T.SID.2, T.RESOURCES, T.INSTALL O.COMMUNICATION T.COMMUNICATION OE.APPLET T.NATIVE Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 38 FT-JCOS v1.0/0.106.13 Security Target O.CARD-MANAGEMENT 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.COMMUNICATION O.IC_SUPPORT T.PHYSICAL O.RECOVERY T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA, T.INTEG- APPLI-DATA, T.INTEG-JCS-DATA, T.SID.2, T.RESOURCES O.RND T.RND, T.PHYSICAL, T.LEAKAGE, T.FAULT 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 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.INTEG-JCS-DATA O.OS_SUPPORT T.CONFID-APPLI-DATA, T.CONFID-JCS-DATA, T.INTEG- APPLI-DATA, T.INTEG-JCS-DATA, T.SID.2, T.RESOURCES Table 6.3: OSPs and Security Objectives — Coverage Organizational Security Policies Security Objectives Rationale OSP.VERIFICATION O.LOAD, OE.VERIFICATION, OE.CODE- EVIDENCE Section 6.3.2 Table 6.4: Security Objectives and OSPs — Coverage Security Objectives Organizational Security Policies 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.TRANSACTION O.OBJ-DELETION O.DELETION O.LOAD OSP.VERIFICATION O.INSTALL OE.APPLET OE.VERIFICATION OSP.VERIFICATION OE.CODE-EVIDENCE OSP.VERIFICATION Table 6.5: Assumptions and Security Objectives for the Operational Environment — Coverage Assumptions Security objectives for the Operational Environment Rationale A.APPLET OE.APPLET Section 6.3.3 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 39 FT-JCOS v1.0/0.106.13 Security Target A.VERIFICATION OE.VERIFICATION, OE.CODE-EVIDENCE Section 6.3.3 Table 6.6: Security Objectives for the Operational Environment and Assumptions — Coverage Security Objectives for the Operational Environment Assumptions OE.APPLET A.APPLET OE.VERIFICATION A.VERIFICATION OE.CODE-EVIDENCE A.VERIFICATION Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 40 FT-JCOS v1.0/0.106.13 Security Target Chapter 7 Security Requirements The operations of the SFR, that are left open in the PP (assignment, iteration, selection, and refinement), are printed in bold type and marked with brackets together with the operation, e.g. [assignment:...]. The operations that are completed in the PP are copied with no further marks. 7.1 TOE Security Functional Requirements 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 [PP0305], requirements are arranged into groups. All the groups defined in the table below apply to this Protection Profile. Table 7.1: Security Functional Requirements overview 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.2 feature. This group is the union of requirements from the Core (CoreG) and the Logical channels (LCG) groups defined in [PP0305] (cf. Java Card System Protection Profile Collection [PP-JCS]). 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.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.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. GlobalPlatform (GPG) The GPG contains the requirements that allow defining a policy for controlling access to card content management operations. Smart card platform (SCPG) The SCPG contains the security requirements for the smart card platform. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 41 FT-JCOS v1.0/0.106.13 Security Target The SFRs refer to all potentially applicable subjects, objects, information, operations, and security at- tributes. The TOE does not provide JCRMI functionality and external momory ( EMG ). Subjects are active components of the TOE that (essentially) act on the behalf of users. The users of the TOE include people or institutions (for this TOE the Chip Manufacturer, Composite Product Integrator, Applet Developer, Card Issuer, 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 is just an alias for the card issuer for this TOE. Subjects (prefixed with an “S”) are described in the following table: Table 7.2: Subjects Subject Description S.ADEL The applet deletion manager which also acts on behalf of the card issuer. It may be an applet ([JCRE222, 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 defined in section 7.1.3. 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 defined in section 7.1.6. S.CAD The CAD represents off-card entity that communicates with the S.INSTALLER. S.INSTALLER The installer is the on-card entity which acts on behalf of the card issuer. This subject is involved in the loading of packages and installation of applets. S.GPINST The GP installer is the on-card entity which acts on behalf of the card issuer. This subject is involved in the PACKAGE LOADING security policy defined in section 7.1.6. 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 Operands 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. Objects (prefixed with an “O”) are described in the following table: Table 7.3: Objects Object Description O.APPLET Any installed applet, its code and data. 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: Table 7.4: Information Information Description I.APDU Any APDU sent to or from the card through the communication channel. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 42 FT-JCOS v1.0/0.106.13 Security Target 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: Table 7.5: Security attributes 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. Address space Accessible memory portion. Applet Selection Status ”Selected” or ”Deselected”. Applet’s version number The version number of an applet (package) indicated in the export file. 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 ([JCVM222, 4.5.2]). 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). 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 Package AID or ”None”. Sharing Standards, SIO, Java Card RE entry point or global array. Static References Static fields of a package may contain references to objects. The Static References attribute records those references. (*) Transient objects of type CLEAR_ON_RESET behave like persistent objects in that they can be ac- cessed only when the Currently Active Context is the object’s context. Table 7.6: Operations 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.LOAD_PCKG(O.PACKAGE, package AID, load parameters, ...) Load and link a package from the S.CAD into card NVRAM. OP. INSTALL_APPLET (O.PACKAGE, O.APPLET, application AID, application privileges, ...) Install and create a selectable applet instance from an installed package with a specific application AID, application privileges and install parameters. 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 43 FT-JCOS v1.0/0.106.13 Security Target OP.GP(…) GlobalPlatform’s card content management APDU commands and API methods (defined in [GP211, Appendix A]): loading ([GP211, 6.4.1.1]); installation ([GP211, 6.4.1.2]); extradition ([GP211, 6.4.3]); content removal ([GP211, 6.4.2.1 to 6.4.2.3]) 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 [JCRE222, 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.THROW(O.JAVAOBJECT) Throwing of an object (athrow, see [JCRE222, 6.2.8.7]). OP.TYPE_ACCESS(O.JAVAOBJECT, class) Invoke checkcast or instanceof on an object in order to access to classes (standard or shareable interfaces objects). 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. (*) 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. 7.1.1 Coreg_LC Security Functional Requirements This group is focused on the main security policy of the Java Card System, known as the firewall. 7.1.1.1 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: • OP.CREATE • OP.INVK_INTERFACE • OP.INVK_VIRTUAL • OP.JAVA • OP.THROW • OP.TYPE_ACCESS Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 44 FT-JCOS v1.0/0.106.13 Security Target FDP_ACC.2.2/FIREWALL The TSF shall ensure that all operations between any subject controlled by the TSF and any object con- trolled by the TSF are covered by an access control SFP Application note: It should be noticed that accessing array’s components of a static array, and more generally fields and methods of static objects, is an access to the corresponding O.JAVAOBJECT. FDP_ACF.1/FIREWALL Security attribute based access control FDP_ACF.1.1/FIREWALL The TSF shall enforce the FIREWALL access control SFP to objects based on the following: Subject/Object Security attributes S.PACKAGE LC Selection Status S.JCVM Active Applets, Currently Active Context S.JCRE Selected Applet Context O.JAVAOBJECT Sharing, Context, LifeTime FDP_ACF.1.2/FIREWALL The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: • R.JAVA.1 ([JCRE222, 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 JAVAOBJECT whose Sharing attribute has value “JCRE entry point” or “global array”. • R.JAVA.2 ([JCRE222, 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. • R.JAVA.3 ([JCRE222, 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. • R.JAVA.4 ([JCRE222, 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. • 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 authorize access of subjects to objects based on the following additional rules: 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. 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). Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 45 FT-JCOS v1.0/0.106.13 Security Target FDP_ACF.1.4/FIREWALL The TSF shall explicitly deny access of subjects to objects based on the following additional rules: 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. 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 Application note: FDP_ACF.1.4/FIREWALL: The deletion of applets render some O.JAVAOBJECT inaccessible, and the Java Card RE is in charge of this aspect. The implementation is designed in such a way that deletion of installed executable content like applets or packages does not introduce security holes in the form of broken references to garbage collected code or data, nor does it affect the integrity or confidentiality of remaining applets in any way. All static references are detected prior to a deletion and if present, delete operation is canceled with an applet left in place, rather than leaving a static reference dangling such that a newly loaded applet’s memory segment could be compromised by that dangling reference. Upon erase event, any data owned by the deleted applet is no longer accessible and as such deleted applet cannot be selected or receive APDU commands. In fact, Card Manager can no long locate applet’s select() or process() Java methods because all such relevant information has been physically removed from applet’s registry. Naturally, package deletion physically removes its entry from on-card registry and makes its opcodes no longer available for execution by Java Card VM. Transactions are used throughout delete sequence to assure that any power failures do not corrupt the deletion process and jeopardize the TOE’s internal data structures. In the case of an array type, fields are components of the array ([JVM, 2.14,2.7.7]), as well as the length; the only methods of an array object are those inherited from the Object class. The Sharing attribute defines four categories of objects: • Standard ones, whose both fields and methods are under the firewall policy. • Shareable interface Objects (SIO), which provide a secure mechanism for inter-applet communi- cation, • JCRE entry points (Temporary or Permanent), who have freely accessible methods but protected fields, • Global arrays, having both unprotected fields (including components; refer to JavaCardClass dis- cussion above) and methods. When a new object is created, it is associated with the Currently Active Context. But the object is owned by the applet instance within the Currently Active Context when the object is instantiated ([JCRE222, 6.1.3]). An object is owned by an applet instance, by the JCRE or by the package library where it has been defined (these latter objects can only be arrays that initialize static fields of packages). ([JCRE222], Glossary) Selected Applet Context. The Java Card RE keeps track of the currently selected Java Card applet. Upon receiving a SELECT command with this applet’s AID, the Java Card RE makes this applet the Selected Applet Context. The Java Card RE sends all APDU commands to the Selected Applet Context. While the expression “Selected Applet Context” refers to a specific installed applet, the relevant aspect to the policy is the context (package AID) of the selected applet. In this policy, the “Selected Applet Context” is the AID of the selected package. ([JCRE222, 6.1.2.1]) At any point in time, there is only one active context within the Java Card VM (this is called the Currently Active Context). Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 46 FT-JCOS v1.0/0.106.13 Security Target It should be noticed that the invocation of static methods (or access to a static field) is not considered by this policy, as there are no firewall rules. They have no effect on the active context as well and the “acting package” is not the one to which the static method belongs to in this case. It should be noticed that the Java Card platform, version 2.2.x, introduces the possibility for an applet instance to be selected on multiple logical channels at the same time, or accepting other applets belong- ing to the same package being selected simultaneously. These applets are referred to as multiselectable applets. Applets that belong to a same package are either all multiselectable or not ([JCVM222, 2.2.5]). Therefore, the selection mode can be regarded as an attribute of packages. No selection mode is defined for a library package. An applet instance will be considered an active applet instance if it is currently selected in at least one logical channel. An applet instance is the currently selected applet instance only if it is processing the current command. There can only be one currently selected applet instance at a given time. ([JCRE222, 4]). FDP_IFC.1/JCVM Subset information flow control FDP_IFC.1.1/JCVM The TSF shall enforce the JCVM information flow control SFP on CVM, S.LOCAL, S.MEMBER, I.DATA and OP.PUT(S1, S2, I). Application note: It should be noticed that references of temporary Java Card RE entry points, which cannot be stored in class variables, instance variables or array components, are transferred from the internal memory of the Java Card RE (TSF data) to some stack through specific APIs (Java Card RE owned exceptions) or Java Card RE invoked methods (such as the process(APDU apdu)); these are causes of OP.PUT(S1,S2,I) operations as well. 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: • An operation OP.PUT(S1, S.MEMBER, I.DATA) is allowed if and only if the Currently Active Context is “Java Card RE”. • other OP.PUT operations are allowed regardless of the Currently Active Context’s value. FDP_IFF.1.3/JCVM The TSF shall enforce the [assignment: none] FDP_IFF.1.4/JCVM The TSF shall explicitly authorize an information flow based on the following rules: [assignment: none] FDP_IFF.1.5/JCVM The TSF shall explicitly deny an information flow based on the following rules: [assignment: none] Application Note: The storage of temporary Java Card RE-owned objects references is runtime-enforced ([JCRE222, 6.2.8.1-3]). It should be noticed that this policy essentially applies to the execution of bytecode. Native methods, the Java Card RE itself and possibly some API methods can be granted specific rights or limitations Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 47 FT-JCOS v1.0/0.106.13 Security Target through the FDP_IFF.1.3/JCVM to FDP_IFF.1.5/JCVM elements. The way the Java Card virtual machine manages the transfer of values on the stack and local variables (returned values, uncaught exceptions) from and to internal registers is implementation-dependent. For instance, a returned reference, depending on the implementation of the stack frame, may transit through an internal register prior to being pushed on the stack of the invoker. The returned bytecode would cause more than one OP.PUT operation under this scheme. 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. Application Note: The semantics of the Java programming language requires for any object field and array position to be initialized with default values when the resource is allocated [JVM, 2.5.1]. 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. Application note: The modification of the Selected Applet Context are performed in accordance with the rules given in [JCRE222, 4] and [JCVM222, 3.4]. 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). Application Note: The modification of the Currently Active Context are performed in accordance with the rules given in [JCRE222, 4] and [JCVM222, 3.4]. 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. Application note: The following rules are implemented in the TOE. The TOE does not support the creation of transient objects belonging to arbitrary classes. • The Context attribute of an O.JAVAOBJECT must correspond to that of an installed applet or be “Java Card RE”. • An O.JAVAOBJECT whose Sharing attribute is a Java Card RE entry point or a global array nec- essarily has “Java Card RE” as the value for its Context security attribute. • An O.JAVAOBJECT whose Sharing attribute value is a global array necessarily has “array of prim- itive type” as a JavaCardClass security attribute’s value. • Any O.JAVAOBJECT whose Sharing attribute value is not “Standard” has a PERSISTENT- Life- Time attribute’s value. • Any O.JAVAOBJECT whose LifeTime attribute value is not PERSISTENT has an array type as JavaCardClass attribute’s value. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 48 FT-JCOS v1.0/0.106.13 Security Target FMT_MSA.3/FIREWALL Static attribute initialization 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. Application note: FMT_MSA.3.1/FIREWALL • Objects’ security attributes of the access control policy are created and initialized at the creation of the object or the subject. Afterwards, these attributes are no longer mutable (FMT_MSA.1/JCRE). At the creation of an object (OP.CREATE), the newly created object, assuming that the FIREWALL access control SFP permits the operation, gets its Lifetime and Sharing attributes from the parame- ters of the operation; on the contrary, its Context attribute has a default value, which is its creator’s Context attribute and AID respectively ([JCRE222, 6.1.3]). There is one default value for the Se- lected Applet Context that is the default applet identifier’s Context, and one default value for the Currently Active Context that is “Java Card RE”. • The knowledge of which reference corresponds to a temporary entry point object or a global array and which does not is solely available to the Java Card RE (and the Java Card virtual machine). FMT_MSA.3.2/FIREWALL • The intent is that none of the identified roles has privileges with regard to the default values of the security attributes. It should be noticed that creation of objects is an operation controlled by the FIREWALL access control SFP. The operation shall fail anyway if the created object would have had security attributes whose value violates FMT_MSA.2.1/FIREWALL_JCVM. FMT_MSA.3/JCVM Static attribute initialization 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: • 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: • Java Card RE (JCRE). • Java Card VM (JCVM). FMT_SMR.1.2 The TSF shall be able to associate users with roles. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 49 FT-JCOS v1.0/0.106.13 Security Target 7.1.1.2 Application Programming Interface The following SFRs are related to the Java Card API and the extensions. The whole set of cryptographic algorithms is generally not implemented because of limited memory resources and/or limitations due to exportation. Therefore, the following requirements only apply to the implemented subset. It should be noticed that the execution of the additional native code is not within the TSF. Nevertheless, access to API native methods from the Java Card System is controlled by TSF because there is no difference between native and interpreted methods in their interface or invocation mechanism. FCS_CKM.1 Cryptographic key generation FCS_CKM.1.1/RSA The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: key generation algorithm for RSA (with or without CRT)] and specified cryp- tographic key sizes [assignment: RSA (with or without CRT): 1024, 2048 Bit] that meet the following: [assignment: According to 3.2(2) [PKCS, 3.2(2)], for u=2, i.e., without any (r_i, d_i, t_i), i > 2. For p × q < 22048 additionally according to section 3.2(1)]. FCS_CKM.1.1/EC The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [assignment: key generation for EC] and specified cryptographic key sizes [assignment: 192, 224, 233, 256, 283, 320, 384, 409, 512, 521] that meet the following: [assignment: ECDSA Key Generation: 1. According to the [ANSI-X9.62, A4.3] (the cofactor h is not supported), 2. According to [ISO15946-2, 6.1(not 6.1.1)]. ] Application note: • The keys can be generated and diversified in accordance with [JCAPI222] specification in classes KeyBuilder and KeyPair (at least Session key generation). • This component is instantiated according to the version of the Java Card API applying to this se- curity target and the implemented algorithms([JCAPI222]). • The certification covers the NIST standard FIPS 186-3 and Brainpool RFC 5639 Elliptic Curves with key lengths of 192 to 521 Bits. • The RSA and the ECC modules are optional modules delivery options for the TOE. The TOE can come without the RSA or ECC module. In that case it does not provide the Specific Security Functionality RSA or ECC. 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 [assignment: setKey for DES and AES, setExponent and setModulus for RSA, setDP1, setDQ1, setP, setQ and setPQ for RSA CRT, as well as, setA, setB, setFieldFP, setG, setK, and setR for EC] that meets the following: [assignment: [JCAPI222]]. Application note: • Command SetKEY that meets [JCAPI222] specification. • This component is instantiated according to the version of the Java Card API applying to this se- curity target and the implemented algorithms ([JCAPI222]). Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 50 FT-JCOS v1.0/0.106.13 Security Target FCS_CKM.3 Cryptographic key access FCS_CKM.3.1 The TSF shall perform [assignment: management of DES, EC, and RSA, AES-keys] in accordance with a specified cryptographic key access method [assignment: methods/commands defined in packages javacard.security and javacardx.crypto] that meets the following: [assignment: [JCAPI222]]. Application note: • The keys can be accessed as specified in [JCAPI222] Key class. • This component is instantiated according to the version of the Java Card API applicable to this security target and the implemented algorithms ([JCAPI222]). 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 [assignment: physically overwriting the keys with random data] that meets the following: [as- signment: [FIPS140]]. Application note: • The keys are reset as specified in [JCAPI222] Key class, with the method clearKey(). Any access to a cleared key for ciphering or signing shall throw an exception. • This component is instantiated according to the version of the Java Card API applicable to this security target and the implemented algorithms ([JCAPI222]). FCS_COP.1 Cryptographic operation FCS_COP.1.1/DES The TSF shall perform [assignment: data encryption and decryption] in accordance with a specified cryp- tographic algorithm [assignment: TDES in ECB/CBC Mode] and cryptographic key sizes [assignment: 112 bits, 168 bits] that meet the following: [assignment: [SP800-67], [SP800-38A]]. FCS_COP.1.1/SHA The TSF shall perform [assignment: hash-value value calculation of user chosen data] in accordance with a specified cryptographic algorithm [assignment: SHA-224, SHA-256, SHA-384 and SHA-512] and cryptographic key sizes [assignment: none] that meet the following: [assignment: [FIPS180-4]]. FCS_COP.1.1/RSA The TSF shall perform [assignment: data encryption/decryption and signature generation/verification] in accordance with a specified cryptographic algorithm [assignment: RSA] and cryptographic key sizes [assignment: 1024, 2048 bits] that meet the following: [assignment: Encryption: RSAEP (section 5.1.1 in [PKCS], without 5.1.1.1); Decryption (with or without CRT): RSADP (section 5.1.2 in [PKCS] for u = 2, only supported up to n < 22048 ); Signature Generation (with or without CRT): RSASP1 (section 5.2.1 in [PKCS] for u = 2 , only supported up to n < 22048 ) and RSASSA-PKCS-v1_5 ([PKCS, 8.2.1]); Signature Verification: RSAVP1 ([PKCS, 5.2.2] - without 5.2.2.1) and RSASSA-PKCS-v1_5 ([PKCS, 8.2.2]).]. FCS_COP.1.1/ECDH The TSF shall perform [assignment: elliptic curve Diffie-Hellman key agreement] in accordance with a specified cryptographic algorithm [assignment: ECDH] and cryptographic key sizes [assignment: 192, 224, 233, 256, 283, 320, 384, 409, 512, 521bits] that meet the following: [assignment: 1. According to [ANSI-X9.63, 5.4.1] Unlike section 5.4.1.3 our implementation not only returns the x-coordinate of Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 51 FT-JCOS v1.0/0.106.13 Security Target the shared secret, but rather the x-coordinate and y-coordinate; 2. According to sections 8.4.2.1, 8.4.2.2, 8.4.2.3, and 8.4.2.4 in [ISO15946-3]: The function enables the operations described in the four sections]. Application note: The certification covers the NIST standard FIPS 186-3 and Brainpool RFC 5639 Elliptic Curves with key lengths of 192 to 521 Bits. FCS_COP.1.1/AES The TSF shall perform [assignment: data encryption and decryption] in accordance with a specified cryp- tographic algorithm [assignment: AES in ECB/CBC mode] and cryptographic key sizes [assignment: 128, 192, or 256 bits] that meet the following: [assignment: [FIPS197], [SP800-38A]]. FCS_COP.1.1/ECDSA The TSF shall perform [assignment: digital signature generation and verification] in accordance with a specified cryptographic algorithm [assignment: ECDSA-FP, ECDSA-F2M] and cryptographic key sizes [assignment: FP: 192, 224, 256, 320, 384, 512, 521 Bit; F2M: 233, 283, 409 bits] that meet the following: [assignment: Signature Generation: 1. According to section 7.3 in [ANSI-X9.62]. Not implemented is step d) and e) thereof. The output of step e) has to be provided as input to our function by the caller. Deviation of step c) and f): The jumps to step a) were substituted by a return of the function with an error code, the jumps are emulated by another call to our function. 2. According to sections 6.2 (6.2.2. + 6.2.3) in [ISO15946-2] Not implemented is section 6.2.1: The output of to be provided by the caller as input to the function; Signature Verification: 1. According to section 7.4.1 in [ANSI-X9.62]. Not implemented is step b) and c) thereof. The output of step c) has to be provided as input to our function by the caller. Deviation of step d): Beside noted calculation, our algorithm adds a random multiple of BasepointerOrder n to the calculated values u1 and u2. 2. According to sections 6.4 (6.4.1. + 6.4.3 + 6.4.4) in [ISO15946-2]. Not implemented is section 6.4.2: The output of 5.4.2 has to be provided by the caller as input to the function]. Application note: The certification covers the NIST standard FIPS 186-3 and Brainpool RFC 5639 Elliptic Curves with key lengths of 192 to 521 Bits. FCS_COP.1.1/SCP The TSF shall perform [assignment: session key derivation and data field decryption of the messages exchanged through GlobalPlatform’s Secure Channels] in accordance with a specified cryptographic al- gorithm [assignment: TDES in CBC/ECB mode, AES in CBC mode] and cryptographic key sizes [as- signment: TDES: 112 bits, AES: 128 bits] that meet the following: [assignment: TDES: [SP800-67], AES: [FIPS197], Modes of Operation: [SP800-38A]]. FCS_COP.1.1/SCP-AUTH The TSF shall perform [assignment: authentication cryptogram generation and verification of the mes- sages exchanged through GlobalPlatform’s Secure Channels] in accordance with a specified cryptograph- ic algorithm [assignment: TDES in CBC mode, KDF in counter mode with C-MAC as PRF] and cryp- tographic key sizes [assignment: TDES: 112 bits, KDF: 128 bits] that meet the following: [assignment: TDES: [SP800-67], KDF: [SP800-108], Modes of Operation: [SP800-38A], [SP800-38B]]. FCS_COP.1.1/SCP-KA The TSF shall perform [assignment: session key derivation of the messages exchanged through Glob- alPlatform’s Secure Channels] in accordance with a specified cryptographic algorithm [assignment: Triple-DES in CBC mode with ICV = 0, KDF in counter mode with C-MAC as PRF] and cryptographic key sizes [assignment: TDES: 112 bits, KDF: 128 bits] that meet the following: [assignment: TDES: [SP800-67], KDF: [SP800-108], Modes of Operation: [SP800-38A], [SP800-38B]. Application note: The following two SFRs implement the acceleration of the communication protocol as preparation for an applet that implements secure messaging according to [ICAO-9303] specification. FCS_COP.1.1/ACC_CYPHER Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 52 FT-JCOS v1.0/0.106.13 Security Target The TSF shall perform [assignment: secure messaging – encryption and decryption] in accordance with a specified cryptographic algorithm [assignment: TDES and AES in CBC mode] and cryptographic key sizes [assignment: TDES: 112 bits, AES: 128, 192, 256 bits] that meet the following: [assignment: TDES: [SP800-67], AES: [FIPS197], Modes of Operation: [SP800-38A]]. FCS_COP.1.1/ACC_MAC The TSF shall perform [assignment: secure messaging – message authentication code] in accordance with a specified cryptographic algorithm [assignment: Retail MAC with TDES, AES in C-MAC mode (truncated to 64 bits] and cryptographic key sizes [assignment: Retail MAC: 112 bits, CMAC: 128 bits, 192 bits, or 256 bits] that meet the following: [assignment: Retail MAC: [ISO9797-1], CMAC: [SP800-38B], TDES: [SP800-67], AES: [FIPS197]] FCS_COP.1.1/DAP/TOKEN The TSF shall perform [assignment: verification of the DAP signature attached to Executable Load Files, verification of the “Delegated Management Token Signature”1 attached to card management com- mands] in accordance with a specified cryptographic algorithm [assignment: RSASSA-PSS, RSASSA- PKCS1-v1_5] and cryptographic key sizes [assignment: RSA: 1024, 2048 bits] that meet the following: [assignment: RSA [PKCS]]]. FCS_COP.1.1/RECEIPT The TSF shall perform [assignment: generation of the “Delegated Management Receipt signature”2 attached to the card management commands responses] in accordance with a specified cryptographic algorithm [RSASSA- PKCS1-v1_5, DES] and cryptographic key sizes [assignment: RSA- 1024 bits, DES - 128 bits] that meet the following: [assignment: RSA [PKCS]], DES [ISO9797-1]]. Application note: • The TOE provides a subset of cryptographic operations defined in [JCAPI222] (see javac- ardx.crypto.Cipher and javacardx.security packages). • This component is instantiated according to the version of the Java Card API applicable to this security target and the implemented algorithms ([JCAPI222]). • The RSA and the ECC modules are optional modules delivery options for the TOE. The TOE can come without the RSA or ECC module. In that case it does not provide the Specific Security Functionality RSA or ECC. 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. Application note: The events that provoke the de-allocation of a transient object are described in [JCRE222, 5.1]. 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. Application note: The allocation of a resource to the APDU buffer is typically performed as the result of a call to the process() method of an applet. 1A Delegated Management Token Signature is a cryptographic value provided by a Card Issuer as proof that a Delegated Man- agement operation has been authorized. 2The Delegated Management Receipt Signature is a cryptographic value provided by the card (if so required by the Card Issuer) as proof that a Delegated Management operation has occurred. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 53 FT-JCOS v1.0/0.106.13 Security Target 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. Application note: A resource is allocated to the bArray object when a call to an applet’s install() method is performed. There is no conflict with FDP_ROL.1 here because of the bounds on the rollback mechanism (FD- P_ROL.1.2/FIREWALL): the scope of the rollback does not extend outside the execution of the install() method, and the de-allocation occurs precisely right after the return of it. 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). Application note: The javacard.security & javacardx.crypto packages do provide secure interfaces to the cryptographic buffer in a transparent way. See javacard.security.KeyBuilder and Key interface of [JCAPI222]. 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. Application note: • The events that provoke the de-allocation of any transient object are described in [JCRE222, 5.1]. • The clearing of CLEAR_ON_DESELECT objects is not necessarily performed when the owner of the objects is deselected. In the presence of multiselectable applet instances, CLEAR_ON_DESELECT memory segments may be attached to applets that are active in different logical channels. Multiselectable applet instances within a same package must share the transient memory segment if they are concurrently active ([JCRE222, 4.2]). 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 [JCRE222, 7.7], within the bounds of the Commit Capacity ([JCRE222, 7.8]), and those described in [JCAPI222]. Application note: Transactions are a service offered by the APIs to applets. It is also used by some APIs to guarantee the atomicity of some operation. This mechanism is either implemented in Java Card platform or relies on the transaction mechanism offered by the underlying platform. Some operations of the API are not con- ditionally updated, as documented in [JCAPI222] (see for instance, PIN-blocking, PIN-checking, update of Transient objects). 7.1.1.3 Card Security Management FAU_ARP.1 Security alarms Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 54 FT-JCOS v1.0/0.106.13 Security Target FAU_ARP.1.1 The TSF shall take one of the following actions: • throw an exception, • lock the card session, • reinitialize the Java Card System and its data, • [assignment: tracking of failures up to the limit after which the card is permanently locked.] 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(), [JCAPI222] and ([JCRE222, 7.6.2]) • violation of the Firewall or JCVM SFPs, • unavailability of resources, • array overflow, • [assignment: stack overflow, • illegal method arguments, • Integrity checks on critical data structure failures, • Hardware/software countermeasures checking failures.] 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 [assignment: integrity errors] on all objects, based on the following attributes: [assignment: Keys and PIN values integrity security attributes (checksum)]. FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [assignment: increase error count reset the card]. Application note: • Although no such requirement is mandatory in the Java Card specification, an exception is raised upon integrity errors detection on cryptographic keys, PIN values, sensitive structures and their associated security attributes. Even if all the objects cannot be monitored, cryptographic keys and PIN objects are considered with particular attention by ST authors as they play a key role in the overall security. • It is also recommended to monitor integrity errors in the code of the native applications and Java Card applets. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 55 FT-JCOS v1.0/0.106.13 Security Target • For integrity sensitive application, their data is monitored (D.APP_I_DATA): applications need to protect information against unexpected modifications, and explicitly control whether a piece of information has been changed between two accesses. For example, maintaining the integrity of an electronic purse’s balance is extremely important because this value represents real money. Its modification must be controlled, for illegal ones would denote an important failure of the payment system. • A dedicated library is implemented and made available to developers to achieve better security for specific objects, following the same pattern that already exists in cryptographic APIs, for instance. FPR_UNO.1 Unobservability FPR_UNO.1.1 The TSF shall ensure that [assignment: all users] are unable to observe the operation [assignment: End User authentication, cryptographic operation] on [assignment: PIN code, TSF data] by none. 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. Application note: The Java Card RE Context is the Current context when the Java Card VM begins running after a card reset ([JCRE222, 6.2.3]) or after a proximity card (PICC) activation sequence ([JCRE222]). Behavior of the TOE on power loss and reset is described in [JCRE222, 3.6,7.1]. Behavior of the TOE on RF signal loss is described in [JCRE222, 3.6.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 • the rules defined in [JCVM222] specification, • the API tokens defined in the export files of reference implementation, • [assignment: The rules defined in [GP211] specification.] when interpreting the TSF data from another trusted IT product. Application note: Concerning the interpretation of data between the TOE and the underlying Java Card platform, it is as- sumed that the TOE is developed consistently with the SCP functions, including memory management, I/O functions and cryptographic functions. 7.1.1.4 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: • Package AID, • Applet’s version number, • Registered applet AID, Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 56 FT-JCOS v1.0/0.106.13 Security Target • Applet Selection Status ([JCVM222, 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. Application note: • By users here it must be understood the ones associated to the packages (or applets) that act as subjects of policies. In the Java Card System, every action is always performed by an identified user interpreted here as the currently selected applet or the package that is the subject’s owner. Means of identification are provided during the loading procedure of the package and the registration of applet instances. • The role Java Card RE defined in FMT_SMR.1 is attached to an IT security function rather than to a “user” of the CC terminology. The Java Card RE does not “identify” itself to the TOE, but it is part of it. 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: [assignment: if an instance of an applet class declared in a certain Java Card package is created, that package is taken as the active context associated to the new application instance.]. 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: [assignment: if an instance of an applet class declared in a certain Java Card package is created, that package is taken as the active context associated to the new application instance.]. Application note: The user is the applet and the subject is the S.PACKAGE. The subject security attribute “Context” shall hold the user security attribute “package AID” 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. 7.1.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 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 57 FT-JCOS v1.0/0.106.13 Security Target of the firewall, and therefore requires specific treatment. In this ST, loading a package or installing an applet modeled as importation of user data (that is, user application’s data) with its security attributes (such as the parameters of the applet used in the firewall rules). 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 ([JCVM222, 4.5.2]). Application note: FDP_ITC.2.1/Installer: • The most common importation of user data is package loading and applet installation on the behalf of the installer. Security attributes consist of the shareable flag of the class component, AID and version numbers of the package, maximal operand stack size and number of local variables for each method, and export and import components (accessibility). FDP_ITC.2.3/Installer: • The format of the CAP file is precisely defined in [JCVM222] specifications; it contains the us- er data (like applet’s code and data) and the security attributes altogether. Therefore there is no association to be carried out elsewhere. FDP_ITC.2.4/Installer: • Each package contains a package Version attribute, which is a pair of major and minor version numbers ([JCVM222, 4.5]). With the AID, it describes the package defined in the CAP file. When an export file is used during preparation of a CAP file, the versions numbers and AIDs indicated in the export file are recorded in the CAP files ([JCVM222, 4.5.2]): the dependent packages Versions and AIDs attributes allow the retrieval of these identifications. Checks occur on a case-by-case basis to indicate that package files are binary compatible. However, package files do have “package Version Numbers” ([JCVM222]) used to indicate binary compatibility or incompatibility between successive implementations of a package, which obviously directly concern this requirement. FDP_ITC.2.5/Installer: • A package may depend on (import or use data from) other packages already installed. • This dependency is explicitly stated in the loaded package in the form of a list of package AIDs. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 58 FT-JCOS v1.0/0.106.13 Security Target • The intent of this rule is to ensure the binary compatibility of the package with those already on the card ([JCVM222, 4.5.2]). • The application instance may only register with the instance AID assigned to it in the INSTALL (install) command by the authenticated client. 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 [JCRE222, 11.1.5]. Application note: The TOE does not provide additional feedback information to the card manager in case of potential se- curity violations (see FAU_ARP.1). The error status response of [GP211] is implemented in the TOE. FPT_RCV.3/Installer Automated recovery without undue loss FPT_RCV.3.1/Installer When automated recovery from [assignment: a failure or a service discontinuity] 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 [assignment: any failure or abortion during the installation process] 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 [assignment: the entire installed file] 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. Application note : FPT_RCV.3.1/Installer : • This element is not within the scope of the Java Card specification, which only mandates the behav- ior of the Java Card System in good working order. The following is an excerpt from [CC2, p298]: In this maintenance mode normal operation might be impossible or severely restricted, as otherwise insecure situations might occur. Typically, only authorized users should be allowed access to this mode but the real details of who can access this mode is a function of FMT: Security management. If FMT: Security management does not put any controls on who can access this mode, then it may be acceptable to allow any user to restore the system if the TOE enters such a state. However, in practice, this is probably not desirable as the user restoring the system has an opportunity to configure the TOE in such a way as to violate the SFRs. FPT_RCV.3.2/Installer: • Should the installer fail during loading/installation of a package/applet, it has to revert to a “consis- tent and secure state”. The Java Card RE has some clean up duties as well; see [JCRE222, 11.1.5] Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 59 FT-JCOS v1.0/0.106.13 Security Target for possible scenarios. This component includes among the listed failures the deletion of a pack- age/applet. In the case of a failure during loading/installation of a package/applet, all allocations are undone (by unrolling the transaction). The original state is restored. The install/load operation can be retried after correcting the original failure reason. • Other events such as the unexpected tearing of the card, power loss, and so on, are partially handled by the underlying hardware platform (see [PP0084]) and, from the TOE’s side, by events “that clear transient objects ” and transactional features. See FPT_FLS.1.1, FDP_RIP.1/TRANSIENT, FDP_RIP.1/ABORT and FDP_ROL.1/FIREWALL. FPT_RCV.3.3/Installer: • First, the SCP ensures the atomicity of updates for fields and objects, and a power-failure during a transaction or the normal runtime does not create the loss of otherwise- permanent data, in the sense that memory on a smart card is essentially persistent with this respect (Flash). Data stored on the RAM and subject to such failure is intended to have a limited lifetime anyway (runtime data on the stack, transient objects’ contents). According to this, the loss of data within the TSF scope is limited to the same restrictions of the transaction mechanism. 7.1.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. This policy is better thought as a frame to be filled by ST implementers. 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: • OP.DELETE_APPLET, • OP.DELETE_PCKG, • 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 con- trolled 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 O.APPLET Applet Selection Status O.JAVAOBJECT Owner FDP_ACF.1.2/ADEL Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 60 FT-JCOS v1.0/0.106.13 Security Target 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: (1) the owner of O is a registered applet instance A (O is reachable from A), (2) a static field of a resident package P contains a reference to O (O is reachable from P), (3) there exists a valid remote reference to O (O is remote reachable), (4) there exists an object O’ that is reachable according to either (1) or (2) or (3) 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: • R.JAVA.14 ([JCRE222, 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 (3) and 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, or ([JCRE222, 8.5]) O.JAVAOBJECT is remote reachable. • R.JAVA.15 ([JCRE222, 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, or ([JCRE222, 8.5]) O.JAVAOBJECT is remote reachable. • R.JAVA.16 ([JCRE222, 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. • R.JAVA.17 ([JCRE222, 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 in- stance 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, or ([JCRE222, 8.5]) O.JAVAOBJECT is remote reachable. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 61 FT-JCOS v1.0/0.106.13 Security Target FDP_ACF.1.3/ADEL The TSF shall explicitly authorize 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. Application note: • This policy introduces the notion of reachability, which provides a general means to describe objects that are referenced from a certain applet instance or package. • S.ADEL calls the “uninstall” method of the applet instance to be deleted, if implemented by the applet, to inform it of the deletion request. The order in which these calls and the dependencies checks are performed are out of the scope of this protection profile. 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. Application note: Deleted freed resources (both code and data) may be reused, depending on the way they were deleted (logically or physically). Requirements on de-allocation during applet/package deletion are described in [JCRE222, 11.3.4.1-3]. 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 initialization FMT_MSA.3.1/ADEL The TSF shall enforce the ADEL access control SFP to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/ADEL The TSF shall allow the following role(s): none, to specify alternative initial values to override the default values when an object or information is created. FMT_SMF.1/ADEL Specification of Management Functions FMT_SMF.1.1/ADEL The TSF shall be capable of performing the following management functions: modify the list of registered applets’ AIDs and the Resident Packages. FMT_SMR.1/ADEL Security roles FMT_SMR.1.1/ADEL The TSF shall maintain the roles: applet deletion manager. FMT_SMR.1.2/ADEL The TSF shall be able to associate users with roles. FPT_FLS.1/ADEL Failure with preservation of secure state FPT_FLS.1.1/ADEL The TSF shall preserve a secure state when the following types of failures occur: the applet deletion Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 62 FT-JCOS v1.0/0.106.13 Security Target manager fails to delete a package/applet as described in [JCRE222, 11.3.4]. Application note: • The TOE provides additional feedback information to the card manager in case of a potential secu- rity violation (see FAU_ARP.1). • The Package/applet instance deletion must be atomic. The “secure state” referred to in the re- quirement complies with Java Card specification ([JCRE222, 11.3.4.]). If the Card Manager is unable to delete all objects of the applet instance being deleted, it will abort the deletion attempt and return a failure code. Similarly, package deletion is atomic. This behavior is conformant to the Java Card specification. No special tracking of application/package deletion failures is performed. But, failures in secure channel creation induce velocity checking countermeasures and slow down reattempts. 7.1.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 unavail- able 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 javac- ard.framework.JCSystem.requestObjectDeletion(). Application note: • Freed data resources resulting from the invocation of the method javac- ard.framework.JCSystem.requestObjectDeletion() may be reused. Requirements on de-allocation after the invocation of the method are described in [JCAPI222]. • There is no conflict with FDP_ROL.1 here because of the bounds on the rollback mechanism: the execution of requestObjectDeletion() is not in the scope of the rollback because it must be performed in between APDU command processing, and therefore no transaction can be in progress. 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. Application note: The TOE may provide additional feedback information to the card manager in case of potential security violation (see FAU_ARP.1). If there is a failure when attempting to delete the unreferenced objects, these objects continue to be remain unreferenced and continue to remain as garbage. The security state is not perturbed. Since the “object deletion” function was not completed, it is automatically retried on the next available opportunity (i.e. between APDUs). 7.1.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 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 63 FT-JCOS v1.0/0.106.13 Security Target The TSF shall enforce the generation of evidence of origin for transmitted [assignment: application package, the Security Domain with Delegated Management privilege] 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 [assignment: application package contained in, the request command parameters of] 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 [assignment: by the DAP verification, the Token verification]. Application note: FCO_NRO.2.1/CM: • Upon reception of a new application package for installation, the card manager first checks that it actually comes from the verification authority. The verification authority is the entity responsible for bytecode verification. FCO_NRO.2.3/CM: • The rules described in GP 2.1.1 are enforced. Package download via INSTALL (load) command must be performed over a secure channel preceded by client authentication. Integrity checking of the package payload is performed. 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. Application note: • The subjects covered by this policy are those involved in the loading of an application package by the card through a potentially unsafe communication channel. • The operations that make information to flow between the subjects are those enabling to send a message through and to receive a message from the communication channel linking the card to the outside world. It is assumed that any message sent through the channel as clear text can be read by an attacker. Moreover, an attacker may capture any message sent through the communication channel and send its own messages to the other subjects. • The information controlled by the policy is the APDUs exchanged by the subjects through the communication channel linking the card and the CAD. Each of those messages contain part of an application package that is required to be loaded on the card, as well as any control information used by the subjects in the communication protocol. 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: [assignment: keys used for DAP]: Subjects Security attributes DAP Keys used by S.INSTALLER Valid key Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 64 FT-JCOS v1.0/0.106.13 Security Target 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: [assignment: the rules describing the communication protocol used by the CAD and the card for transmitting a new package. • The subject S.INSTALLER shall accept a message only if it comes from the subject S.CAD. • The subject S.INSTALLER shall accept an application package only if it has received without modification and in the right order all the APDUs sent by the subject S.CAD] FDP_IFF.1.3/CM The TSF shall enforce the [assignment: additional information flow control SFP rules: none]. FDP_IFF.1.4/CM The TSF shall explicitly authorize an information flow based on the following rules: [assignment: Rules defined in [GP211, E]. FDP_IFF.1.5/CM The TSF shall explicitly deny an information flow based on the following rules: The TOE fails to verify the integrity and authenticity evidences of the application package [assignment: The retry counter limit is exceeded]. Application note: FDP_IFF.1.1/CM: • The security attributes used to enforce the PACKAGE LOADING SFP depend on the communica- tion protocol enforced between the CAD and the card. For instance, some of the attributes that can be used are: (1) the keys used by the subjects to encrypt/decrypt their messages; (2) the number of pieces the application package has been split into in order to be sent to the card; (3) the ordinal of each piece in the decomposition of the package, etc. See for example [GP211, C]. FDP_IFF.1.2/CM: • The whole exchange of messages verify at least the following two rules: (1) the subjec- t S.INSTALLER shall accept a message only if it comes from the subject S.CAD; (2) the subject S.INSTALLER shall accept an application package only if it has received without modification and in the right order all the APDUs sent by the subject S.CAD. FDP_IFF.1.5/CM: • The verification of the integrity and authenticity evidences is performed either during loading or during the first installation of an application of the package. FDP_UIT.1/CM Data exchange integrity FDP_UIT.1.1/CM The TSF shall enforce the PACKAGE LOADING information flow control SFP to [selection: transmit, receive] user data in a manner protected from [selection: modification, deletion, insertion, replay] errors. FDP_UIT.1.2/CM [Editorially Refined] The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion, replay of some of the pieces of the application sent by the CAD has occurred. Application note: Modification errors are understood as modification, substitution, unrecoverable ordering change of data and any other integrity error that may cause the application package to be installed on the card to be different from the one sent by the CAD. The TOE implements [GP211]. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 65 FT-JCOS v1.0/0.106.13 Security Target FIA_UID.1/CM Timing of identification FIA_UID.1.1/CM The TSF shall allow [assignment: application selection; initializing a secure channel with the card; 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. Application note: The package installation requires the user to be identified. Here by user is meant the one(s) that in the Security Target shall be associated to the role(s) defined in the component FMT_SMR.1/CM. 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 [selection: modify, delete, [assignment: reset]] the security attributes [assignment: keys used for DAP] to [assignment: S.INSTALLER]. FMT_MSA.3/CM Static attribute initialization 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 [assignment: the authorized identified roles: none] 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: [assignment: modify the security attributes]. FMT_SMR.1/CM Security roles FMT_SMR.1.1/CM The TSF shall maintain the roles: [assignment: Card Manager]. FMT_SMR.1.2/CM The TSF shall be able to associate users with roles. 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. Application note: There is no dynamic package loading on the Java Card platform. New packages can be installed on the Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 66 FT-JCOS v1.0/0.106.13 Security Target card only on demand of the card issuer. The TOE implements SCP02 and SCP03 with the following options. SCP02: 0x15. SCP03 Option 0x10 7.1.6 GPG Security Functional Requirements The following SFRs are related to the security requirements for the GlobalPlatform card manager func- tionalities of the TOE. FDP_ACC.1/GPG Subset access control FDP_ACC.1.1/GPG The TSF shall enforce the [assignment: CARD CONTENT MANAGEMENT access control SFP] on [assignment: Subjects: S.INSTALLER, S.PACKAGE, S.ADEL, S.CAD, Objects: O.APPLET, O.CODE_PKG; Operations: OP.GP] FDP_ACF.1/GPG Security attribute based access control FDP_ACF.1.1/GPG The TSF shall enforce the [assignment: CARD CONTENT MANAGEMENT access control SFP] to objects based on the following: [assignment:] Subject/Object Security attributes S.INSTALLER None S.PACKAGE LC Selection Status, Currently Active Context S.ADEL None S.CAD None O.APPLET, O.CODE_PKG None FDP_ACF.1.2/GPG The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [assignment: CARD CONTENT MANAGEMENT access control SFP: OP.GP(...)] FDP_ACF.1.3/GPG The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [assignment: none] FDP_ACF.1.4/GPG The TSF shall explicitly deny access of subjects to objects based on the following additional rules: [as- signment: If the card life cycle state is TERMINATED or LOCKED the access of subjects for CARD CONTENT MANAGEMENT access control SFP on its objects is not allowed.] FMT_MSA.1/GPG Management of security attributes FMT_MSA.1.1/GPG The TSF shall enforce the [assignment: CARD CONTENT MANAGEMENT access control SFP] to restrict the ability to [selection: modify] the security attributes: [assignment: Card Life Cycle State, Security Level] to [assignment: S.INSTALLER]. FMT_MSA.3/GPG Static attribute initialization FMT_MSA.3.1/GPG The TSF shall enforce the [assignment: CARD CONTENT MANAGEMENT access control SFP] to provide [selection: restrictive] default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/GPG The TSF shall allow the [assignment: the authorized identified roles: none] to specify alternative initial values to override the default values when an object or information is created. FMT_SMF.1/GPG Specification of Management Functions Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 67 FT-JCOS v1.0/0.106.13 Security Target FMT_SMF.1.1/GPG The TSF shall be capable of performing the following management functions: [assignment: Modification of the security attributes Card Life Cycle State and Security Level]. FMT_SMR.1/GPG Security roles FMT_SMR.1.1/GPG The TSF shall maintain the roles [assignment: S.CAD, and S.INSTALLER]. FMT_SMR.1.2/GPG The TSF shall be able to associate users with roles. FIA_UID.1/GPG Timing of identification FIA_UID.1.1/GPG The TSF shall allow [assignment: TSF-mediated actions: GET DATA, INITIALIZE UPDATE, EXTER- NAL AUTHENTICATE according to [GP211]] on behalf of the user to be performed before the user is identified. FIA_UID.1.2/GPG The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user. Application Note: The list of TSF-mediated actions is implementation-dependent, but package installation requires the user to be identified. Here by user is meant the one(s) that in the Security Target shall be associated to the role(s) defined in the component FMT_SMR.1/GPG 7.1.7 SCPG Security Functional Requirements The group SCPG contains the security requirements, which are needed to support the platform. FCS_RNG.1 Quality metric for Random Numbers The TOE meets the requirement “Quality metric for random numbers (FCS_RNG.1)” as specified below (Common Criteria Part 2 extended). FCS_RNG.1.1 The TSF shall provide a [selection: physical] random number generator that implements: [assignment: • (PTG.2.1) A total failure test detects a total failure of entropy source immediately when the RNG has started. When a total failure is detected, no random numbers will be output. • (PTG.2.2) If a total failure of the entropy source occurs while the RNG is being operated, the RNG prevents the output of any internal random number that depends on some raw random numbers that have been generated after the total failure of the entropy source. • (PTG.2.3) The online test shall detect non-tolerable statistical defects of the raw random number sequence (i) immediately when the RNG has started, and (ii) while the RNG is being operated. The TSF must not output any random numbers before the power-up online test has finished successfully or when a defect has been detected. • (PTG.2.4)The online test procedure shall be effective to detect non-tolerable weaknesses of the random numbers soon. • (PTG.2.5)The online test procedure checks the quality of the raw random number sequence. It is triggered continuously. The online test is suitable for detecting non-tolerable statistical defects of the statistical properties of the raw random numbers within an acceptable period of time. ] Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 68 FT-JCOS v1.0/0.106.13 Security Target FCS_RNG.1.2 The TSF shall provide numbers in the format 8- or 16-bit that meet [assignment: • (PTG.2.6) Test procedure A, as defined in [AIS_PROP] does not distinguish the internal random numbers from output sequences of an ideal RNG. • (PTG.2.7)The average Shannon entropy per internal random bit exceeds 0.997. ] FPT_EMSEC.1 TOE Emanation FPT_EMSEC.1.1 The TOE shall not emit [assignment: variations in power consumption, electromagnetic field or tim- ing during command execution] in excess of [assignment: non-useful information] enabling access to [assignment: TSF data: D.JCS_KEYs and D.CRYPTO] and [assignment: User data: D.PIN, D.APP_KEYs]. FPT_EMSEC.1.2 The TSF shall ensure [assignment: that any users] are unable to use the following interface [assign- ment: electrical contacts] to gain access to [assignment: TSF data: D.JCS_KEYs and D.CRYPTO] and [assignment: User data: D.PIN, D.APP_KEYs]. FPT_RCV.3/SCP Automated recovery without undue loss FPT_RCV.3.1/SCP When automated recovery from [assignment: loss of power and card tearing] 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/SCP For [assignment: loss of power and card tearing] the TSF shall ensure the return of the TOE to a secure state using automated procedures. FPT_RCV.3.3/SCP The functions provided by the TSF to recover from failure or service discontinuity shall ensure that the secure initial state is restored without exceeding [assignment 0%] for loss of TSF data or objects within the TSC. FPT_RCV.3.4/SCP The TSF shall provide the capability to determine the objects that were or were not capable of being recovered. FPT_RCV.4/SCP Function recovery FPT_RCV.4.1/SCP The TSF shall ensure that [assignment: reading from and writing to static and objects’ fields interrupted by power loss] have the property that the SF either completes successfully, or for the indicated failure scenarios, recovers to a consistent and secure state. 7.2 TOE Security Assurance Requirements The security assurance requirement level is EAL5 augmented by AVA_VAN.5 “Advanced methodical vulnerability analysis” and ALC_DVS.2 “Sufficiency of security measures”. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 69 FT-JCOS v1.0/0.106.13 Security Target 7.3 Security Requirements Rationale 7.3.1 Objectives 7.3.1.1 Security Objectives for the TOE 7.3.1.1.1 IDENTIFICATION O.SID Subjects’ identity is AID-based (applets, packages), and is met by the following S- FRs: FDP_ITC.2/Installer, FIA_ATD.1/AID, FMT_MSA.1/JCRE, FMT_MSA.1/JCVM, FMT_MSA.1/REM_REFS, 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, FMT_MTD.3/JCRE. 7.3.1.1.2 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, FD- P_IFC.1/JCVM) and the functional requirement FDP_ITC.2/Installer. The functional require- ments 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 clear- ing 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. Protection of the array parameters of remotely invoked methods, which are global as well, is cov- ered by the general initialization of method parameters (FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FD- P_RIP.1/ABORT, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL and FDP_RIP.1/TRANSIENT). O.GLOBAL_ARRAYS_INTEG This objective is met by the JCVM information flow control policy (FDP_IFF.1/JCVM, FD- P_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 con- trol 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 re- covery from failure is ensured (FPT_RCV.3/Installer), applets’ installation may be cleanly aborted (FD- P_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 pro- Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 70 FT-JCOS v1.0/0.106.13 Security Target tected by components of the FPT class). Almost every objective and/or functional requirement indirectly contributes to this one too. Application note: Startup of the TOE (TSF-testing) can be covered by FPT_TST.1. This SFR component is not mandatory in [JCRE222], but appears in most of security requirements documents for masked applications. Self tests are performed on startup. 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, FD- P_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, FP- T_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, FMT_SMF.1/EXT_MEM and FMT_SMR.1/CM). 7.3.1.1.3 SERVICES O.ALARM This security objective is met by FPT_FLS.1/Installer, FPT_FLS.1, FPT_FLS.1/ADEL, FP- T_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. 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 FD- P_SDI.2 as well. Precisely it is met by the following components: FCS_CKM.1, FCS_CKM.2, FC- S_CKM.3, FCS_CKM.4, FCS_COP.1, FPR_UNO.1, FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FD- P_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL and FDP_RIP.1/TRANSIENT. O.PIN-MNGT This security objective is ensured by FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/APDU, FD- P_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 be- hind 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.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 FD- P_RIP.1/OBJECTS (more precisely, by the element FDP_RIP.1.1/ABORT). 7.3.1.1.4 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 71 FT-JCOS v1.0/0.106.13 Security Target 7.3.1.1.5 Applet Management O.DELETION This security objective specifies that applet and package deletion must be secure.The non-introduction of security holes is ensured by the ADEL access control policy (FDP_ACC.2/ADEL, FDP_ACF.1/ADEL). The integrity and confidentiality of data that does not belong to the deleted applet or package is a by-product of this policy as well. Non-accessibility of deleted data is met by FDP_RIP.1/ADEL and the TSFs are protected against possible failures of the deletion procedures (FPT_FLS.1/ADEL, F- PT_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). 7.3.1.1.6 Communication O.COMMUNICATION This security objective is met by FMT_SMR.1/GPG, it specifies the authorized identified roles enabling to send and authenticate card management commands. FMT_MSA.1/GPG and FMT_MSA.3/GPG cover indirectly this security objective by specifying security attributes enabling to guarantee the integrity of card management requests. FIA_UID.1/GPG specify the actions that can be performed prior to identifi- cation of the origin of the APDU commands that the TOE receives O.RECOVERY This objective is met by the component FPT_RCV.3/SCP. The components FPT_RCV.3 and FPT_RCV.4 are used to support the objective O.OS_SUPPORT and O. RECOVERY to assist the TOE to recover in the event of a power failure. FAU_ARP.1 reacts to the detection of a potential security violation, while FPT_FLS.1 preserves a secure state. If the power fails or the card is withdrawn prematurely from the CAD the operation of the TOE may be interrupted leaving the TOE in an inconsistent state 7.3.1.1.7 Random Numbers O.RND This objective is met by the component FCS_RNG.1, as [AIS20] needs non-predictable random numbers with the needed cryptographic quality. 7.3.1.1.8 Card Manager O.CARD-MANAGEMENT The objective is met by the security requirements for the GlobalPlatform card manager functionalities of the TOE. It protects against unauthorized access of the CARD CONTENT MANAGEMENT access control SFP (FDP_ACC.1/GPG and FDP_ACF.1/GPG). The GP management is controlled by the TSF (FMT_MSA.1/GPG, FMT_SMF.1/GPG, FMT_MSA.3.1/GPG, FMT_SMR.1/GPG, FIA_UID.1/GPG). O.OS_SUPPORT The objective is met by the components low-level cryptographic support by FCS_COP.1, low-level trans- action support by FDP_ROL.1/FIREWALL, low-level data integrity monitoring by FDP_SDI.2, the au- Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 72 FT-JCOS v1.0/0.106.13 Security Target tomated recovery of FPT_RCV.3/SCP and FPT_RCV.4/SCP. O.IC_SUPPORT The objective is met by the components that protect against physical attacks, i.e. the strong random num- ber generator supported by the platform true random number generator FCS_RNG, not emit variations in power consumption or timing during command execution by FPT_EMSEC. 7.3.2 Rationale tables of Security Objectives and SFRs Table 7.7: Security Objectives and SFRs — Coverage Security Objectives Security Functional Requirements Rationale O.SID FIA_ATD.1/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, FMT_MSA.1/JCVM, FMT_MSA.3/JCVM, Section 7.3.1.1.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, FD- P_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 7.3.1.1.2 O.GLOBAL _ARRAYS_CONFID FDP_IFC.1/JCVM, FDP_IFF.1/JCVM, FD- P_RIP.1/bArray, FDP_RIP.1/APDU, FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL, FD- P_RIP.1/TRANSIENT Section 7.3.1.1.2 O.GLOBAL _ARRAYS_INTEG FDP_IFC.1/JCVM, FDP_IFF.1/JCVM Section 7.3.1.1.2 O.NATIVE FDP_ACF.1/FIREWALL Section 7.3.1.1.2 O.OPERATE FAU_ARP.1, FDP_ROL.1/FIREWALL, FI- A_ATD.1/AID, FPT_FLS.1/ADEL, FPT_FLS.1, FPT_FLS.1/ODEL, FPT_FLS.1/Installer, FD- P_ITC.2/Installer, FPT_RCV.3/Installer, FD- P_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL, FPT_TDC.1, FIA_USB.1/AID Section 7.3.1.1.2 O.REALLOCATION FDP_RIP.1/ABORT, FDP_RIP.1/APDU, FD- P_RIP.1/bArray, FDP_RIP.1/KEYS, FD- P_RIP.1/TRANSIENT, FDP_RIP.1/ADEL, FD- P_RIP.1/ODEL, FDP_RIP.1/OBJECTS Section 7.3.1.1.2 O.RESOURCES FAU_ARP.1, FDP_ROL.1/FIREWALL, FMT_SMR.1/Installer, FMT_SMR.1, FMT_SMR.1/ADEL, FPT_FLS.1/Installer, FP- T_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 7.3.1.1.2 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 73 FT-JCOS v1.0/0.106.13 Security Target O.ALARM FPT_FLS.1/Installer, FPT_FLS.1, FPT_FLS.1/ADEL, F- PT_FLS.1/ODEL, FAU_ARP.1 Section 7.3.1.1.3 O.CIPHER FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FCS_COP.1, FCS_RNG.1, FPR_UNO.1 Section 7.3.1.1.3 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, FD- P_RIP.1/bArray, FDP_RIP.1/ABORT, FD- P_RIP.1/KEYS, FDP_SDI.2, FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT Section 7.3.1.1.3 O.PIN-MNGT FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FD- P_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, FD- P_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL Section 7.3.1.1.3 O.TRANSACTION FDP_ROL.1/FIREWALL, FDP_RIP.1/ABORT, FD- P_RIP.1/ODEL, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL, FD- P_RIP.1/TRANSIENT, FDP_RIP.1/OBJECTS Section 7.3.1.1.3 O.OBJ-DELETION FDP_RIP.1/ODEL, FPT_FLS.1/ODEL Section 7.3.1.1.4 O.DELETION FDP_ACC.2/ADEL, FDP_ACF.1/ADEL, FDP_RIP.1/ADEL, FPT_FLS.1/ADEL, F- PT_RCV.3/Installer, FMT_MSA.1/ADEL, FMT_MSA.3/ADEL, FMT_SMR.1/ADEL Section 7.3.1.1.5 O.LOAD FCO_NRO.2/CM, FDP_IFC.2/CM, FDP_IFF.1/CM, FD- P_UIT.1/CM, FIA_UID.1/CM, FTP_ITC.1/CM Section 7.3.1.1.5 O.INSTALL FDP_ITC.2/Installer, FPT_RCV.3/Installer, FP- T_FLS.1/Installer Section 7.3.1.1.5 O.COMMUNICATION FMT_SMR.1/GPG, FMT_MSA.1/GPG, FMT_MSA.3/GPG, FIA_UID.1/GPG Section 7.3.1.1.6 O.RECOVERY FPT_FLS.1, FPT_FLS.1/SCP, FPT_RCV.3/SCP, FP- T_RCV.4/SCP, FAU_ARP.1 Section 7.3.1.1.6 O.RND FCS_RNG.1 Section 7.3.1.1.7 O.CARD- MANAGEMENT FDP_ACC.1/GPG, FDP_ACF.1/GPG, FMT_MSA.1/GPG, FMT_SMF.1/GPG, FMT_MSA.3/GPG, FMT_SMR.1/GPG, FI- A_UID.1/GPG Section 7.3.1.1.8 O.OS_SUPPORT FCS_COP.1, FDP_ROL.1/FIREWALL, FDP_SDI.2, FP- T_RCV.3/SCP, FPT_RCV.4/SCP Section 7.3.1.1.8 O.IC_SUPPORT FPT_EMSEC.1, FCS_RNG.1 (Hardware Platform SFR) Section 7.3.1.1.8 Table 7.8: SFRs and Security Objectives Dependencies Security Functional Requirements Security Objectives FDP_ACC.2/FIREWALL O.FIREWALL, O.OPERATE, O.PIN-MNGT FDP_ACF.1/FIREWALL O.FIREWALL, O.NATIVE, O.OPERATE, O.PIN-MNGT 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.GLOBAL_ARRAYS_CONFID, O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION, O.REALLOCATION FMT_MSA.1/JCRE O.SID, O.FIREWALL FMT_MSA.1/JCVM O.SID, O.FIREWALL FMT_MSA.2/FIREWALL_JCVM O.FIREWALL Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 74 FT-JCOS v1.0/0.106.13 Security Target FMT_MSA.3/FIREWALL O.SID, O.FIREWALL 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 FDP_RIP.1/ABORT O.GLOBAL_ARRAYS_CONFID, O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION, O.REALLOCATION FDP_RIP.1/APDU O.GLOBAL_ARRAYS_CONFID, O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION, O.REALLOCATION FDP_RIP.1/bArray O.GLOBAL_ARRAYS_CONFID, O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION, O.REALLOCATION FDP_RIP.1/KEYS O.GLOBAL_ARRAYS_CONFID, O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION, O.REALLOCATION FDP_RIP.1/TRANSIENT O.GLOBAL_ARRAYS_CONFID, O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION, O.REALLOCATION FDP_ROL.1/FIREWALL O.OPERATE, O.RESOURCES, O.PIN-MNGT, O.TRANSACTION FAU_ARP.1 O.OPERATE, O.RESOURCES, O.ALARM FDP_SDI.2 O.KEY-MNGT, O.PIN-MNGT FPR_UNO.1 O.CIPHER, O.KEY-MNGT, O.PIN-MNGT FPT_FLS.1 O.OPERATE, O.RESOURCES, O.ALARM FPT_TDC.1 O.OPERATE FIA_ATD.1/AID O.SID, O.OPERATE 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, O.RECOVERY FDP_ACC.2/ADEL O.DELETION FDP_ACF.1/ADEL O.DELETION FDP_RIP.1/ADEL O.GLOBAL_ARRAYS_CONFID, O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION, O.DELETION, O.REALLOCATION FMT_MSA.1/ADEL O.SID, O.FIREWALL, O.DELETION FMT_MSA.3/ADEL O.SID, O.FIREWALL, O.DELETION FMT_SMF.1/ADEL O.SID, O.FIREWALL, O.RESOURCES FMT_SMR.1/ADEL O.FIREWALL, O.RESOURCES, O.DELETION FPT_FLS.1/ADEL O.OPERATE, O.RESOURCES, O.ALARM, O.DELETION FDP_RIP.1/ODEL O.GLOBAL_ARRAYS_CONFID, O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION, O.OBJ-DELETION, O.REALLOCATION 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 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 75 FT-JCOS v1.0/0.106.13 Security Target FTP_ITC.1/CM O.LOAD FDP_ACC.1/GPG O.CARD-MANAGEMENT FDP_ACF.1/GPG O.CARD-MANAGEMENT FMT_MSA.1/GPG O.COMMUNICATION, O.CARD-MANAGEMENT FMT_SMF.1/GPG O.CARD-MANAGEMENT FMT_MSA.3/GPG O.COMMUNICATION, O.CARD-MANAGEMENT FMT_SMR.1/GPG O.COMMUNICATION, O.CARD-MANAGEMENT FIA_UID.1/GPG O.COMMUNICATION, O.CARD-MANAGEMENT FCS_RNG.1 O.RND FPT_EMSEC.1 O.IC_SUPPORT FPT_RCV.3/SCP O.RECOVERY, O.OS_SUPPORT FPT_RCV.4/SCP O.RECOVERY, O.OS_SUPPORT 7.3.3 Dependencies 7.3.3.1 SFRs dependencies Table 7.9: 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, FT- P_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) FMT_MSA.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 FDP_UIT.1/CM (FDP_ACC.1 or FDP_IFC.1) and (FT- P_ITC.1 or FTP_TRP.1) FDP_IFC.2/CM, FT- P_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 FDP_ACC.2/FIREWALL (FDP_ACF.1) FDP_ACF.1/FIREWA LL Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 76 FT-JCOS v1.0/0.106.13 Security Target FDP_ACF.1/FIREWALL (FDP_ACC.1) and (FMT_MSA.3) FDP_ACC.2/FIREWA LL, FMT_MSA.3/FIREW ALL 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/FIREWA LL, 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/FIREWA L- L, FDP_IFC.1/JCVM, FMT_SMF.1, FMT_SMR.1 FDP_RIP.1/KEYS No dependencies FDP_RIP.1/TRANSIENT No dependencies FDP_ROL.1/FIREWALL (FDP_ACC.1 or FDP_IFC.1) FDP_ACC.2/FIREWA LL, 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 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/GPG (FDP_ACF.1) FDP_ACF.1/GPG FDP_ACF.1/GPG (FDP_ACC.1) and (FMT_MSA.3) FDP_ACC.1/GPG, FMT_MSA.3/GPG FMT_MSA.1/GPG (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FDP_ACC.1/GPG, FMT_SMF.1/GPG, FMT_SMR.1/GPG FMT_SMF.1/GPG No dependencies FMT_MSA.3/GPG (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/GPG, FMT_SMR.1/GPG FMT_SMR.1/GPG (FIA_UID.1) FIA_UID.1/GPG FIA_UID.1/GPG No dependencies FCS_RNG.1 No dependencies FPT_EMSEC.1 No dependencies FPT_RCV.3/SCP (AGD_OPE.1) AGD_OPE.1 FPT_RCV.4/SCP No dependencies 7.3.3.1.1 Rationale for the exclusion of dependencies The dependency FIA_UID.1 of FMT_SMR.1/Installer is unsupported. 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 unsupported. 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 unsupported. 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 unsupported. 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. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 77 FT-JCOS v1.0/0.106.13 Security Target 7.3.3.2 SARs Dependencies Table 7.10: SARs dependencies Requirements CC Dependencies Satisfied Dependencies ADV_ARC.1 (ADV_FSP.1) and (ADV_TDS.1) ADV_FSP.4, ADV_TDS.3 ADV_FSP.5 (ADV_TDS.1) and (ADV_IMP.1) ADV_TDS.3, ADV_IMP.1 ADV_IMP.1 (ADV_TDS.3) and (ALC_TAT.1) ADV_TDS.3, ALC_TAT.2 ADV_INT.2 (ADV_IMP.1) and (ADV_TDS.3) and (AL- C_TAT.1) ADV_TDS.3, ADV_IMP.1, AL- C_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 (AL- C_LCD.1) ALC_CMS.4, ALC_DVS.2, AL- C_LCD.1 ALC_CMS.5 No dependencies ALC_DEL.1 No dependencies ALC_DVS.2 No dependencies ALC_LCD.1 No dependencies ALC_TAT.2 (ADV_IMP.1) ADV_IMP.1 ASE_CCL.1 (ASE_ECD.1) and (ASE_INT.1) and (ASE_REQ.1) ASE_ECD.1, ASE_INT.1, ASE_REQ.2 ASE_ECD.1 No dependencies ASE_INT.1 No dependencies ASE_OBJ.2 (ASE_SPD.1) ASE_SPD.1 ASE_REQ.2 (ASE_ECD.1) and (ASE_OBJ.2) ASE_ECD.1, ASE_OBJ.2 ASE_SPD.1 No dependencies ASE_TSS.1 (ADV_FSP.1) and (ASE_INT.1) and (ASE_REQ.1) ADV_FSP.5, ASE_INT.1, ASE_REQ.2 ATE_COV.2 (ADV_FSP.2) and (ATE_FUN.1) ADV_FSP.5, ATE_FUN.1 ATE_DPT.3 (ADV_ARC.1) and (ADV_TDS.2) and (ATE_FUN.1) ADV_ARC.1, ADV_TDS.3, 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.3, AGD_OPE.1, AGD_PRE.1, ATE_DPT.1 7.3.4 Rationale for the Security Assurance Requirement EAL5 is chosen for TOE and product since it is intended to defend against sophisticated attacks. This evaluation assurance level allows a developer to gain maximum assurance from positive security engi- neering based on good practices. EAL5 represents the highest practical level of assurance expected for a commercial grade product. In order to provide a meaningful level of assurance that the TOE and its embedding product provide an adequate level of defense against such attacks: the evaluators should have access to the low level design and source code. The lowest for which such access is provided is EAL5. 7.3.5 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 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 78 FT-JCOS v1.0/0.106.13 Security Target product, it is necessary to justify the sufficiency of these procedures to protect their confidentiality and integrity. ALC_DVS.2 has no dependencies. 7.3.6 AVA_VAN.5 Advanced methodical vulnerability analysis The TOE is intended to operate in hostile environments. AVA_VAN.5 “Advanced methodical vulner- ability analysis” is considered as the expected level for Java Card technology-based products hosting sensitive applications, in particular in payment and identity areas. AVA_VAN.5 has dependencies on ADV_ARC.1, ADV_FSP.1, ADV_TDS.3, ADV_IMP.1, AGD_PRE.1 and AGD_OPE.1. All of them are satisfied by EAL5. 7.4 Extended Components Definition 7.4.1 Definition of the Family FCS_RNG This chapter has been defined in the certified (BSI-PP-0084) Smartcard IC Platform Protection Profile [PP0084]. Family behavior This family defines quality requirements for the generation of random numbers which are intended to be use for cryptographic purposes. Component leveling: FCS_RNG Generation of random numbers FCS_RNG.1: Generation of random numbers requires that random numbers meet a defined quality metric. Management: FCS_RNG.1 There are no management activities foreseen. Audit: FCS_RNG.1 There are no actions defined to be auditable. FCS_RNG.1 Quality metric for random numbers Hierarchical to: No other components. Dependencies: No Dependencies. FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic, hy- brid] random number generator that implements: [assignment: list of security ca- pabilities]. FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined quality metric]. Application Note: A physical random nubmer generaotr(RNG) produces the ran- dom number by a noise source based on physical random processes. A non-physical true RNG uses a noise source based on non-physical random processes like human interaction(key strokes, mouse movement). A deterministic RNG uses a random seed to produce a pseudorandom output. A hybrid RNG combines the prindiples of physical and deterministic RNGs. 7.4.2 Definition of the Family FPT_EMSEC This chapter has been copied from the certified Protection Profile [PP0055] and [PP0056]. The additional family FPT_EMSEC (TOE Emanation) of the Class FPT (Protection of the TSF) is defined here to describe the IT security functional requirements of the TOE. The TOE shall prevent attacks against the private signature key and other secret data where the attack is based on external observable physical phenomena of the TOE. Examples of such attacks are evaluation of TOE’s electromagnetic radiation, simple power analysis (SPA), differential power analysis (DPA), timing attacks, etc. This family describes the functional requirements for the limitation of intelligible emanations which are not directly addressed by any other component of Common Criteria part 2. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 79 FT-JCOS v1.0/0.106.13 Security Target Family behaviour This family defines requirements to mitigate intelligible emanations. Component behaviour: FPT_EMSEC TOE emanation FPT_EMSEC.1 TOE emanation has two constituents: FPT_EMSEC.1.1 Limit of emissions requires to not emit intelligible emissions enabling access to TSF data or user data. FPT_EMSEC.1.2 Interface emanation requires not emit interface emanation enabling access to TSF data or user data. Management: FPT_EMSEC.1 There are no management activities foreseen. Audit: FPT_EMSEC.1 There are no actions defined to be auditable. FPT_EMSEC.1 TOE Emanation Hierarchical to: No other components. FPT_EMSEC.1.1 The TOE shall not emit [assignment: types of emissions] in excess of [assign- ment: specified limits] enabling access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. FPT_EMSEC.1.2 The TSF shall ensure [assignment: type of users] are unable to use the following interface [assignment: type of connection] to gain access to [assignment: list of types of TSF data] and [assignment: list of types of user data]. Dependencies: No other components. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 80 FT-JCOS v1.0/0.106.13 Security Target Chapter 8 TOE Summary Specification This chapter summarizes the security functionality and the assurance measures of the TOE that fulfil the TOE security requirements. The next table lists the summary of the security functionality of the TOE. Table 8.1: SFRs dependencies TOE Security Functionality Mapping to SFR GLOBALPLATFORM’s TOE Security Functionality SF.Card Manager FAU_ARP.1 FIA_ATD.1/AID FIA_UID.2/AID FCO_NRO.2/CM FDP_ACC.1/GPG FDP_ACF.1/GPG FDP_ACC.2/ADEL FDP_IFF.1/CM FDP_ITC.2/Installer FDP_UIT.1/CM FTP_ITC.1/CM FIA_UID.1/CM FMT_MSA.1/CM FMT_MSA.1/JCVM FMT_MSA.1/ADEL FMT_MSA.3/ADEL FMT_MSA.3/CM FMT_MSA.3/JCVM FMT_MTD.1/JCRE FMT_MTD.3/JCRE FMT_SMF.1 FMT_SMF.1/ADEL FMT_SMF.1/CM FMT_SMF.1/GPG FMT_SMR.1/ADEL FMT_SMR.1/CM FMT_SMR.1/Installer FPT_FLS.1 FPT_FLS.1/ADEL FPT_FLS.1/Installer FPT_FLS.1/ODEL FPT_RCV.3/Installer FPT_TDC.1 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 81 FT-JCOS v1.0/0.106.13 Security Target SF.Secure Channels FDP_RIP.1/TRANSIENT FDP_ACF.1/ADEL FDP_ACF.1/FIREWALL FAU_ARP.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 SF.Secure Channel Key Management FDP_RIP.1/TRANSIENT FDP_SDI.2 FCS_CKM.1 FCS_CKM.2 FCS_CKM.3 FCS_CKM.4 FCS_COP.1 SF.Global PIN Management 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 FDP_SDI.2 FDP_ACC.2/FIREWALL FDP_ACF.1/FIREWALL Java Card Runtime Environment TOE Security Functionality SF.Java Card Firewall FDP_ACC.2/FIREWALL FDP_ACF.1/FIREWALL FAU_ARP.1 FMT_SMR.1/GPG FDP_IFC.1/JCVM FDP_IFC.2/CM FDP_IFF.1/JCVM FIA_USB.1/AID FMT_MSA.1/GPG FMT_MSA.2/FIREWALL_JCVM FMT_MSA.3/FIREWALLFMT_MSA.3/GPG FIA_UID.1/GPG FMT_MSA.1/JCRE SF.End User Authentication FMT_SMR.1 FPR_UNO.1 SF.Sensitive Data Cleaner FDP_RIP.1/OBJECTS 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 Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 82 FT-JCOS v1.0/0.106.13 Security Target SF.Atomic_Transactions FDP_ROL.1/FIREWALL FPT_RCV.3/SCP FPT_RCV.4/SCP SF.Security Violation FDP_ACC.2/FIREWALL FDP_ACF.1/FIREWALL SF.PIN integrity FAU_ARP.1 FPR_UNO.1 FDP_SDI.2 SF.Key Management FAU_ARP.1 FCS_COP.1 FCS_CKM.1 FCS_CKM.2 FCS_CKM.3 FCS_CKM.4 FDP_SDI.2 SF.Cryptographic Operations FAU_ARP.1 FCS_COP.1 FCS_CKM.1 FCS_CKM.2 FCS_CKM.3 FCS_CKM.4 FCS_RNG.1 FPT_EMSEC.1 8.1 Security Functionality 8.1.1 GLOBALPLATFORM’s TOE Security Functionality 8.1.1.1 SF.Card Manager In Open Mode configuration, the Card Manager is activated and is responsible for card administration. The goal of the Card Manager is to enforce the security policies of the Card Issuer on the card by providing the following features: Card Content Management(CCM) This feature is the capability for loading, installing, register updating and removal of card content (exe- cutable load file). DAP Verification This feature guarantees the authenticity of the Executable Load File by verifying the DAP signature on the Load File using the Verification Authority’s RSA public key. This is an optional feature of the Java Card Platform and will be activated only if the card has been config- ured to do so. If the TOE has been configured to verify the DAP then the Verification Authority signs the Application electronically (loading file) right after its verification according to [APPNOTE]. Otherwise if the TOE has not been configured to verify DAP signatures, the Verification Authority shall transmit appli- cation to the IC Manufacturer/Composite Product Integrator/Card Issuer through a secure communication channel ensuring the origin and the integrity of transmitted files. Upon reception, the IC Manufacturer/- Composite Product Integrator/Card Issuer shall store the application in its secure environment until the file is downloaded into the card. Card Management Environment This feature initializes and manages the GlobalPlatform Registry data such as the currently loaded applets instances and AIDs or the Security Domain associations and privileges. APDU Commands Dispatcher This TOE Security Functionality is in charge of dispatching the APDU commands received by the Card Manager to the selected applet installed on the card. It is the responsibility of the application to correctly reject the command if necessary. Note that also the Proprietary APDUs do go through the Card Manager Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 83 FT-JCOS v1.0/0.106.13 Security Target and its dispatcher. APDU Commands Dispatcher This TOE Security Functionality is in charge of dispatching the APDU commands received by the Card Manager to the selected applet installed on the card. It is the responsibility of the application to correctly reject the command if necessary. Note that also the Proprietary APDUs do go through the Card Manager and its dispatcher. SSD Delegated Management This feature enables Delegated Card Content Management which allows the Application Provider’s Se- curity Domain to perform delegated loading, delegated installation and make selectable, delegated extra- dition, delegated update of GP registry and delegated deletion. This feature is realized by the Advanced GP module which includes Delegated Management with token verification and receipt generation, Install for Registry Update and Install for Extradition. This is an optional feature of the Java Card Platform and will be activated only if the card has been configured to do so. Life-Cycle Management This feature controls the state transition of the card and the installed applications as required by the Glob- alPlatform specification [GP211]. It ensures that initialization and personalization dedicated commands are disabled in the usage stage of the TOE to prevent any unauthorized modification of the TSF data. Logical Channel Management This feature enables the multi-selection of applet instance. 8.1.1.2 SF.Secure Channels This TOE Security Functionality provides a secure mean for the IC Manufacturer/Composite Product Integrator/Card Issuer to perform card management. This TSF protects the sensitive assets exchanged during that process. It relies on the Secure Channel Protocols defined in GlobalPlatform specification [GP211]. This is achieved by the following features: Mutual Authentication The IC Manufacturer/Composite Product Integrator/Card Issuer is authenticated through the following Secure Channel Protocols compliant with the GP specification: SCP02 (with options 0x15, or 0x55) Or, SCP03 (with option 0x10) Depending on the configuration of the Card, only one of the two protocols must be activated to execute mutual authentication operation. Message Integrity Verification This feature ensures the integrity of the APDU commands received through a Secure Channel. Message Confidentiality This feature decrypts the contents of APDU commands received through a Secure Channel, guaranteeing the confidentiality of the sensitive assets. 8.1.1.3 SF.Secure Channel Key Management This TOE security Functionality is intended to securely manage the keys used to establish a secure chan- nel. These are the Session keys used to open a secure channel with the CAD and the ISD keys used to open a secure channel with the IC Manufacturer/Composite Product Integrator/Card Issuer. Session Key/ISD Key Generation The TOE generates the keys in accordance with the Java Card Specification and supported by the platform Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 84 FT-JCOS v1.0/0.106.13 Security Target true random number generator. 8.1.1.4 SF.Global PIN Management This TOE Security Functionality controls the update of the security attributes associated the global CVM which is restricted to the applets installed with the CVM Privilege. 8.1.2 Java Card TOE Security Functionality 8.1.2.1 SF.Java Card Firewall The Java Card firewall provides protection against the most frequently anticipated security concern: de- veloper mistakes and design oversights that might allow sensitive data to be “leaked” to another applet. However, if the object is owned by an applet protected by its own firewall, the requesting applet must satisfy certain access rules before it can use the reference to access the object. These set of access rules controls the sharing and separation of resources between applet instantiations. This TSF is enforced by the Java Card Virtual Machine. Each applet has its own bytecode, set of APDUs and classes. The instantiated applet gains the capability to have exclusive ownership of data object con- structed from its classes. When an applet is activated, it is given private, exclusive ownership of a logical communication channel. In addition, it gains a unique execution context (instruction counter, status and stack). The firewall also provides protection against incorrect code. If incorrect code is loaded onto a card, the firewall still protects objects from being accessed by this code. 8.1.2.2 SF.End User Authentication This TOE Security Functionality allows and applet’s user identification and authentication using the fol- lowing features: PIN comparison feature This feature is based on a secure comparison between the PIN value stored in the persistent memory and the value received from the CAD. 8.1.2.3 SF.Sensitive Data Cleaner This TOE Security Functionality ensures that sensitive information contained in data containers (APDU buffer, cryptographic buffer, local variables, bArray, static fields, Class instances fields, etc.) are cleared after usage upon sensitive operations (Deletion of Packages/Applets/Objects, Cryptographic operations, APDU commands, etc.). 8.1.2.4 SF.Atomic_Transactions This TOE Security Functionality ensures the atomicity of transactions. It manages the contents of per- sistent storage after a stop, failure, or fatal exception during an update of a single object field or single class field or single array component. An applet might need to atomically update several different fields or array components in several different objects. Either all updates take place correctly and consistently, or else all fields or components are restored to their previous values. 8.1.2.5 SF.Security Violation This TOE Security Functionality detects an attempt to illegally access an object belonging to another applet across the firewall boundary, on violation of fundamental language restrictions, such as attempting to invoke a private method in another class, on unavailability of data upon allocation. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 85 FT-JCOS v1.0/0.106.13 Security Target 8.1.2.6 SF.PIN integrity This TOE Security Functionality ensures that the PIN value is protected in integrity. The integrity value is checked as well as its persistent attributes before any operation made on the PIN value. 8.1.2.7 SF.Key Management This TOE Security Functionality ensures a secure on-card cryptographic keys infrastructure. Thus, pro- viding the following security features: Keys Integrity Protection This feature guarantees that the cryptographic keys are protected from unauthorized modification. Keys Confidentiality Protection This feature guarantees that the cryptographic keys are protected from disclosure. Keys Secure Generation This feature provides applets with on-card generation of cryptographic keys. Keys Secure Deletion This feature ensures that the keys can never be disclosed after deletion. Therefore, upon deletion, the content of the key objects is erased and the allocated memory space is free again. Keys Secure Distribution This feature enforces the distribution of the cryptographic keys. Keys Secure Agreement This feature ensures a secure sharing of secrets between the applet and the terminal. For that, the applet instances use key agreement algorithms. 8.1.2.8 SF.Cryptographic Operations This TOE Security Functionality enforces security means to execute the following cryptographic opera- tions: Message Digest Generation This feature generates a hash value from a block of data contained in a byte array. It is almost impossible to generate one hash value from two different blocks of data. Signature Generation & Verification This feature is responsible for generating and verifying an electronic signature. It uses a private key to generate the electronic signature contained in a byte array and a public key to verify the signature. In addition it uses a hash function in the signature generation process to obtain a condensed version of the data to be signed/ a message digest. The message digest is given in input to the digital signature algorithm to generate the digital signature. Encryption & Decryption This feature is responsible for encrypting and decrypting the contents of a byte array. Unique Hash Value This feature enables the generation of a unique hash value (SHA-2) for application instance’s data. Random Number Generation This feature enables the generation of random data to be used for generating cryptographic protocol chal- lenges and cryptographic key values. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 86 FT-JCOS v1.0/0.106.13 Security Target 8.2 Statement of Compatibility Concerning Composite Security Target This is a composite evaluation. For this kind of evaluation the BSI defines the [AIS36] composite e- valuation scheme. The compatibility between this Composite Security Target (this ST) and the Platform Security Target [ST_IC] is claimed. In the section “Usage of Platform TSF by TOE TSF”, the separation of the relevant security functionality described in the ST of the smart card platform used by the TOE. The Java Card Protection Profile defines miscellaneous sets of possible Java Card Systems as a TOE. See Appendix 1 of [PP] for details. The [PP] defines Groups, which can be chosen for different evaluations. For this Security Target the following groups are part of the TOE. The TOE is the Java Card System v2.2.2 without the RMI group (RMIG). So the following groups are part of the TOE: • Core with Logical Channels (CoreG_LC) • Installer (InstG) • Object deletion (ODELG) • Applet deletion (ADELG) • Secure carrier (CarG) • GlobalPlatform (GPG), this is an addition to the Java Card PP The smart card platform (SCP) is composed of the Infineon micro-controller and hardware abstraction layer containing the cryptographic library. Group Description TOE Core (CoreG_LC) The CoreG_LC contains the requirements concerning the run- time environment of the Java Card System implementing logi- cal channels. This includes the firewall policy and the require- ments related to the Java Card API. TOE Installer (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 se- curity aspects of the installation procedure that are related to applet execution. TOE Object deletion(ODELG) The ODELG contains the security requirements for the object deletion capability. This provides a safe memory recovering mechanism. TOE Applet deletion(ADELG) The ADELG contains the security requirements for erasing in- stalled applets from the card. TOE 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 configura- tions 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 TOE GlobalPlatform (GPG) The Card Manager is conformant to [GP211]. TOE Smart card platform(SCPG) The SCPG contains the security requirements for the smart card platform, that is, operating system and chip that the Ja- va Card System is implemented upon. In this Security Target, this group applies to the composite platform and is within the scope of evaluation. TOE Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 87 FT-JCOS v1.0/0.106.13 Security Target 8.3 Assumptions and OSP of the Platform for its Operational En- vironment The assumptions A.APPLET and A.VERIFICATION include no assumption for the platform. They are related to the processes and users of the TOE. There is no significant platform assumption (SgPA) of the Platform-ST and no conflict to the security environments of the Platform-ST [ST_IC]. Assumptions of the hardware platform [ST_IC, 4.3] Description Categorization, see [AIS36] Remark A.Process-Sec-IC Protection during Packaging, Finishing and Personalization Fulfilled (CfPA) Fulfilled by the composite-SAR class ALC A.Plat-Appl Usage of Hardware Platform Fulfilled (CfPA) Fulfilled by the composite-SAR AD- V_COMP.1 A.Resp-Appl Treatment of User Da- ta Fulfilled (CfPA) The TOE implements the needed functionali- ty as A.Resp-Appl can be mapped to O.KEY- MNGT and O.PIN- M- NGT A.Key-Function Usage of Key- depen- dent Functions Fulfilled (CfPA) The TOE implements the needed functional- ity as A.Key- Function can be mapped to T.PHYSICAL and T.CONFID-APPLI- DATA There are two OSPs mentioned in the ST of the hardware platform [ST_IC], P.Process-TOE and P.Add- Functions. OSP of the hardware platform [ST_IC, 4.2] Applicable threats by TOE Remark P.Process- TOE Protection during TOE Develop- ment and Production 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 The OSP of the hardware platform is not contra- dictory to the threats of the Composite- ST P.Add- Functions specific security func- tionality to the TOE T.CONFID-APPLI-DATA T.CONFID-JCS-DATA T.INTEG-APPLI-DATA T.INTEG-JCS-DATA T.SID.2 T.RESOURCES matches O.IC_SUPPORT Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 88 FT-JCOS v1.0/0.106.13 Security Target 8.4 Threats of the Platform The threats T.PHYSICAL, T.FAULT, T.LEAKAGE, and T.RND can be directly mapped to the platform threats, as listed in the following table. The other threats of the TOE are not related to the platform IC. Platform threats (Hardware and Crypto Library) TOE threats Remark T.Phys-Manipulation, T.Abuse-Func T.PHYSICAL They match, as these threaps are directed to the SCP. T.Malfunction T.FAULT They match, as both dealing with parameter outside the normal operating condition- s. T.Leak-Inherent, T.Leak-Forced T.LEAKAGE They match, as both dealing with leakage threats. T.RND T.RND They match. 8.5 Security Objectives Mapping of the Platform The following TOE security objectives are directly addressed to the platform: O.IC_SUPPORT, O.RECOVERY, O.OS.SUPPORT. These can be mapped to the Objective of the hardware platform as listed in the following table: TOE objectives O.IC_SUPPORT O.RECOVERY O.OS_SUPPORT O.Phys-Manipulation X X O.Phys-Probing X X O.Malfunction X X X O.Leak-Inherent X X O.Leak-Forced X X O.Abuse-Func X X O.RND X O.Add-Functions X O.Mem-Access X O.IC_SUPPORT is mapped to the objectives of the platform features against physical attacks like physical probing and sophisticated analysis of the chip. This is all, but .O.Identification and O.RND. O.RECOVERY is mapped to O.Malfunction as it is needed to restart the TOE after a malfunction. O.OS_SUPPORT is mapped to all hardware relevant platform features that provide support for the func- tions to be not bypassed or altered. These are all, except O.Identification. 8.6 Separation of the Platform-TSF by TOE SFR The TOE implements the following SFR, which are related to the platform SFR [ST_IC]. The following table lists the relevant Platform-SFRs being used by the Composite-ST. All not listed SFRs are irrelevant and not being used by the Composite-ST. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 89 FT-JCOS v1.0/0.106.13 Security Target Hardware Platform SFR TOE SFR Remark FPT_FLS.1 FPT_FLS.1 The SFR matches the platform SFR FRU_FLT.2 FPT_RCV.3 The SFR matches the platform SFR FPT_PHP.3 FPT_EMSEC.1 FPT_EMSEC.1 uses the plat- form SFR FCS_RNG.1 FCS_RNG.1 The random number generator uses the platform TRNG as in- put FCS_COP.1/DES FCS_COP.1/DES FCS_COP.1.1/SCP cryptographic coprocessor of hardware used FCS_COP.1/AES FCS_COP.1/AES cryptographic coprocessor of hardware used FCS_COP.1/RSA FCS_COP.1/RSA Library of hardware used FCS_COP.1/ECDH FCS_COP.1/ECDH Library of hardware used FCS_COP.1/ECDSA FCS_COP.1/ECDSA EC library of the hardware is used FCS_COP.1/SHA FCS_COP.1/SHA Library of hardware used FCS_CKM.1/RSA FCS_CKM.1/EC FCS_CKM.1/ECDSA FCS_CKM.1 Key generation for RSA and ECC is supported by the platfor- m FDP_ACC.1 FDP_ACC.2/ADEL FDP_ACC.2/FIREWALL Access control is supported by platform FDP_ACF.1 FDP_ACF.1/ADEL FDP_ACF.1/FIREWALL Security attribute based access control supported by platform FMT_MSA.1 FMT_MSA.1/ADEL FMT_MSA.1/JCRE FMT_MSA.1/JCVM FMT_MSA.1/CM FMT_MSA.1/GPG Management of security at- tributes supported by platform FMT_MSA.3 FMT_MSA.3/ADEL FMT_MSA.3/FIREWALL FMT_MSA.3/JCVM FMT_MSA.3/CM FMT_MSA.1/GPG Static attribute initialization supported by platform FDP_SDI.1 FDP_SDI.2 FDP_SDI.2 Stored data integrity monitoring and action supported by platfor- m FDP_ITT.1 FPT_ITT.1 FDP_IFC.1.1/JCVM Subset information flow control supported by platform FDP_IFC.1 FDP_IFC.1/JCVM FDP_IFC.2/CM Subset/Complete information flow control supported by platform Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 90 FT-JCOS v1.0/0.106.13 Security Target Bibliography [APPNOTE] APPLICATION NOTE CERTIFICATION OF “OPEN” SMART CARD PRODUCTS. [ICAO-9303] ”Doc 9303, Machine Readable Travel Documents, ICAO. [PP-JCS] Java Card Protection Profile Collection, Version 1.0b, August 2003, registered and certified by the French certification body (ANSSI) under the following references: [PP/0303] “Minimal Con- figuration”, [PP/0304] “Standard 2.1.1 Configuration”, [PP/0305] “Standard 2.2 Configuration” and [PP/0306] “ Defensive Configuration”. [JVM] The Java Virtual Machine Specification. Lindholm, Yellin. ISBN 0-201-43294-3. [PKCS] Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1. [FIPS140] Federal Information Processing Standards Publication 140-2: Security Requirements for Cryptographic Modules (FIPS PUB 140-2). May 2001. [ANSI-X9.63] Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography. November 2001. [ISO15946-2] Information technology — Security techniques — Cryptographic techniques based on el- liptic curves — Part 2: Digital Signatures. 2002. [JAVASPEC] The Java Language Specification. Third Edition, May 2005. Gosling, Joy, Steele and Bracha. ISBN 0-321-24678-0. May 2005. [ANSI-X9.62] Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA). 2005. [PP0055] Machine Readable Travel Document with ”ICAO Application”, Basic Access Control. March 2009. [PP0056] Machine Readable Travel Document with ”ICAO Application”, Extended Access Control, Ver- sion 1.10. March 2009. [AIS20] Anwendungshinweise und Interpretationen zum Schema, AIS 20: Funktionalitaetsklassen und Evaluationsmethodologie für deterministische Zufallszahlengeneratoren, Version 2.1. February 2011. [ISO9797-1] ISO/IEC 9797-1:2011 Information technology — Security techniques — Message Authen- tication Codes (MACs) — Part 1: Mechanisms using a block cipher : MAC algorithm 3. 2011. [AIS_PROP] A proposal for: Functionality classes for random number generators , Version 2.0. Septem- ber 2011. [CC1] Common Criteria for Information Technology Security Evaluation, Part 1, Version 3.1, Revision 4. September 2012. [CC2] Common Criteria for Information Technology Security Evaluation, Part 2, Version 3.1, Revision 4. September 2012. [CC3] Common Criteria for Information Technology Security Evaluation, Part 3, Version 3.1, Revision 4. September 2012. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 91 FT-JCOS v1.0/0.106.13 Security Target [CEM] Common Methodology for Information Technology Security Evaluation, Evaluation Methodolo- gy, Version 3.1, Revision 4. September 2012. [PP0084] Security IC Platform Protection Profile with Augmentation Packages Version 1.0. 2014. [SLE78-DATASHEET] M7892 Controller Family for Security Applications Hardware Reference Man- ual Revision 1.7.1. September 2015. [ST_IC] Infineon Technologies AG. M7892 B11 Recertification Including optional Software Libraries RSA - EC - SHA -2 - Toolbox Common Criteria CC v3.1 EAL6 augmented (EAL6+ ). October 2015. [JCBV] Oracle Corporation. Java Card Platform, version 2.2 Off-Card Verifier. White paper. June 2002. [PP] Oracle Corporation. Java Card Protection Profile – Open Configuration, Version 3.0. May 2012. [GP211] GlobalPlatform Inc. GlobalPlatform Card Specification, Version 2.1.1. March 2003. [JCAPI222] Sun Microsystems. Java CardTM application programming interface(API), version 2.2.2. March 2006. [JCRE222] Sun Microsystems. Java CardTM Technology for Runtime Environment Specification, version 2.2.2. August 2006. [JCVM222] Sun Microsystems. Java CardTM Technology for Virtual Machine Specification, version 2.2.2. November 2006. [SP800-38A] National Institute of Standards and Technology. NIST Special Publication 800-38A, Rec- ommendation for Block Cipher Modes of Operation Methods and Techniques. December 2001. [SP800-38B] National Institute of Standards and Technology. NIST Special Publication 800-38B, Rec- ommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication. May 2005. [SP800-108] National Institute of Standards and Technology. NIST Special Publication 800-108, Rec- ommendation for Key Derivation Using Pseudorandom Functions. October 2009. [FIPS197] National Institute of Standards and Technology. FIPS PUB 197 - ADVANCED ENCRYPTION STANDARD (AES). November 2011. [SP800-67] National Institute of Standards and Technology. NIST Special Publication 800-67, Recom- mendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, Version 1.2. July 2011. [FIPS180-4] National Institute of Standards and Technology. FIPS PUB 180-4 - FEDERAL INFORMA- TION PROCESSING STANDARDS PUBLICATION: Secure Hash Standard (SHS). March 2012. Copyright© 2016 Feitian Technologies Co., Ltd. Website: www.FTsafe.com 92