ID-ONE COSMO V8.2 Public Security Target © IDEMIA. All rights reserved. Specifications and information are subject to change without notice. The products described in this document are subject to continuous development and improvement. All trademarks and service marks referred to herein, whether registered or not in specific countries, are the properties of their respective owners. - Printed versions of this document are uncontrolled - ID-ONE COSMO V8.2 Public Security Target 2 | 202 Document Management Identification Business Unit - Department PSI - R&D Document type: FQR Document Title: ID-One Cosmo V8.2 – Public Security Target FQR No: 110 9067 FQR Issue: 8 Document revision Date Revision-Issue Modification Modified by 03 -2019 1 Creation IDEMIA 04-2019 2 Update optional patch Identification code in section 2.3 TOE Reference and issue of [R41] IDEMIA 06-2019 3 Courbevoie is added IDEMIA 07-2019 4 Update section 2.4.4 IDEMIA 10-2019 5 Update for Assurance continuity following IAR [R45] IDEMIA 14-02-2020 6 Update TOE references, including guidance and IC. IDEMIA 02-06-2020 8 Update TOE references, including guidance IDEMIA ID-ONE COSMO V8.2 Public Security Target 3 | 202 Table of contents Document Management 2 Identification 2 Document revision 2 1 PREFACE 8 1.1 OBJECTIVES OF THE DOCUMENT 8 1.2 SCOPE OF THE DOCUMENT 8 1.3 Abbreviations and Notations 8 1.3.1 Abbreviations 8 1.3.2 Notations 9 2 Security Target Introduction 11 2.1 Product family 11 2.2 Public Security Target reference 11 2.3 TOE Reference 12 2.4 TOE Identification 13 2.4.1 Product Commercial Version (DO ‘DF66’) 13 2.4.2 IC Card Manufacturing Data (tag ‘DF50’) 13 2.4.3 Card Identification Data (tag ‘DF52’) 14 2.4.4 Applications included in the TOE 16 3 TOE overview 18 3.1 TOE Configuration 18 3.2 TOE Type 19 3.2.1 Defensive Java Card Platform 19 3.2.2 Global Platform 20 3.2.3 Integrated Circuit (IC) 21 3.2.4 Operating System (OS) 22 3.3 Major Security feature of the TOE 24 3.4 NON-TOE HW/SW/FW AVAILABLE TO THE TOE 28 3.5 TOE usage 29 3.6 TOE Guidances 30 3.6.1 Platform isolation 30 3.6.2 Sensitive applications 30 3.7 TOE Life cycle 31 3.7.1 Phases 33 3.7.2 Phase 1: Security IC Embedded Software development 34 3.7.3 Phase 2: Security IC Development 37 3.7.4 Phase 3: Security IC Manufacturing 37 ID-ONE COSMO V8.2 Public Security Target 4 | 202 3.7.5 Phase 4: JavaCard Platform Packaging 38 3.7.6 Phase 5: Composite Product Integration 38 3.7.7 Phase 6: Composite Product Personalisation 41 3.7.8 Phase 7: Operational Usage 44 3.8 Software Components Life Cycle 47 3.8.1 Card Life Cycle 47 3.8.2 Security Domain Life Cycle States 49 3.8.3 Load File Life Cycle 51 3.8.4 Application Life Cycle 52 4 Common Criteria conformance claim 54 4.1 Common Criteria 54 4.2 Protection Profile 54 4.3 Conformance claim rationale 54 4.3.1 TOE Type conformance 55 4.3.2 SPD Statement Consistency 55 4.3.3 Objectives 56 4.3.4 SFR and SARs Statements consistency 56 5 Security aspects 60 5.1 Confidentiality 60 5.2 Integrity 60 5.3 Unauthorized executions 61 5.4 Bytecode verification 62 5.4.1 CAP file verification 62 5.4.2 Integrity and authentication 62 5.4.3 Linking and authentication 63 5.5 Card management 63 5.6 Services 64 6 Security Problem Definition 66 6.1 Assets 66 6.1.1 User data 66 6.1.2 TSF data 67 6.1.3 Additional assets 67 6.2 Users / Subjects 68 6.2.1 Additional Users / Subjects 68 6.2.2 Miscellaneous 69 6.3 Threats 70 6.3.1 CONFIDENTIALITY 70 6.3.2 INTEGRITY 70 6.3.3 IDENTITY USURPATION 71 6.3.4 UNAUTHORIZED EXECUTION 71 6.3.5 DENIAL OF SERVICE 72 6.3.6 CARD MANAGEMENT 72 ID-ONE COSMO V8.2 Public Security Target 5 | 202 6.3.7 SERVICES 72 6.3.8 MISCELLANEOUS 72 6.3.9 Additional threats 73 6.4 Organisational Security Policies 73 6.5 Assumptions 73 7 Security Objectives 74 7.1 Security Objectives for the TOE 74 7.1.1 IDENTIFICATION 74 7.1.2 EXECUTION 74 7.1.3 SERVICES 75 7.1.4 OBJECT DELETION 75 7.1.5 APPLET MANAGEMENT 76 7.1.6 Additional security objectives for the TOE 76 7.2 Security objectives for the Operational Environment 77 7.3 Security Objectives Rationale 78 7.3.1 Threats 78 7.3.2 Organisational Security Policies 84 7.3.3 Assumptions 84 7.3.4 SPD and Security Objectives 84 8 Extended Requirements 89 8.1 Extended Families 89 8.1.1 Extended Family FCS_–NG - FCS_RNG: Random Number Generation 89 9 Security Requirements 90 9.1 Security Functional Requirements 90 9.1.1 CoreG_LC Security Functional Requirements 94 9.1.2 InstG Security Functional Requirements 111 9.1.3 ADELG Security Functional Requirements 114 9.1.4 ODELG Security Functional Requirements 118 9.1.5 CarG Security Functional Requirements 119 9.2 Security Assurance Requirements 141 9.3 Security Requirements Rationale 141 9.3.1 Objectives 141 9.3.2 Rationale tables of Security Objectives and SFRs 148 9.3.3 Dependencies 157 9.3.4 Rationale for the Security Assurance Requirements 166 9.3.5 AVA_VAN.5 Advanced methodical vulnerability analysis 166 9.3.6 ALC_DVS.2 Sufficiency of security measures 166 10 TOE Summary Specification 167 10.1 TOE Summary Specification 167 10.2 SFRs and TSS 174 10.2.1 SFRs and TSS - Rationale 174 10.2.2 Association tables of SFRs and TSS 189 ID-ONE COSMO V8.2 Public Security Target 6 | 202 11 Rationale for the composition with the IC 198 12 RELATED DOCUMENTS 199 ID-ONE COSMO V8.2 Public Security Target 7 | 202 List of tables Table 1: GET DATA P1/P2 – Supported data objects tags............................... 13 Table 2: Product Commercial Version data................................................... 13 Table 3: IC Card Manufacturing data........................................................... 14 Table 4: Card identification data................................................................. 16 Table 5: Aid(s) of applications included in the TOE ....................................... 17 Table 6: Guidance references..................................................................... 30 Table 7: TOE Life Cycle – Summary ................................................................. 32 Table 8: Security IC Embedded Software development Environment & Roles................ 36 Table 9: Javacard Platform Packaging Roles....................................................... 38 Table 10: Composite Product Integration – Administrators....................................... 39 Table 11: Composite Product Integration – Keysets............................................... 41 Table 12: Composite Product Personalisation – Administrators ................................. 42 Table 13: Composite Product Personalisation – Keysets......................................... 44 Table 14: Operational Usage – Administrators ..................................................... 45 Table 15: Operational Usage – Keysets ............................................................. 46 Table 16: CC conformance rationale ........................................................... 54 Table 17: Threats and Security Objectives – Coverage......................................... 85 Table 18: Security Objectives and Threats – Coverage......................................... 87 Table 19: OSPs and Security Objectives – Coverage ........................................... 87 Table 20: Security Objectives and OSPs – Coverage ........................................... 88 Table 21: Assumptions and Security Objectives for the Operational Environment – Coverage ......................................................................................................... 88 Table 22: Security Objectives for the Operational Environment and Assumptions – Coverage ......................................................................................................... 88 Table 23– Security Objectives and SFRs - Coverage...........................................150 Table 24: SFRs and Security Objectives..........................................................157 Table 25: SFRs Dependencies .....................................................................164 Table 26: SARs Dependencies .....................................................................166 Table 27: SFRs and TSS – Coverage.............................................................195 ID-ONE COSMO V8.2 Public Security Target 8 | 202 1 PREFACE 1.1 OBJECTIVES OF THE DOCUMENT The objective of this document is to present the public security target of the ID-One Cosmo v8.2 family. 1.2 SCOPE OF THE DOCUMENT This document describes the Public Security Target for the ID-One Cosmo v8.2 family. This Public Security Target covers the development of the family which is able to receive and manage different types of applications:  Basic: applications that do not require certificate, with no assets to protect. This is the case for fidelity applications, Information-on-demand (IOD) applications, etc.  Secure: applications that require a Common criteria certificate. The objectives of this Public Security Target are: - To describe the Target of Evaluation (TOE), its life cycle and to position it in the smart card life cycle. - To describe the security environment of the TOE including the assets to be protected and the threats to be countered by the TOE and by the operational environment during the platform active phases. - To describe the security objectives of the TOE and its supporting environment in terms of integrity and confidentiality of sensitive information. It includes protection of the TOE (and its documentation) during the platform active phases. - To specify the security requirements which include the TOE functional requirements, the TOE assurance requirements and the security requirements for the environment. 1.3 Abbreviations and Notations 1.3.1 Abbreviations AES Advanced Encryption Standard AID Applet Identifier APDU Application Protocol Data Unit API Application Programmer Interface APSD Application Provider Security Domain BIOS Basic Input/Output System CASD Controlling Authority Security Domain CC Common Criteria CM Card Manager CPLC Card Production Life Cycle DAP Data Authentication Pattern ID-ONE COSMO V8.2 Public Security Target 9 | 202 DES Cryptographic module "Data Encryption Standard" EAL Evaluation Assurance Level EC Elliptic Curves EEPROM Electrically Erasable and Programmable Read Only Memory ES Embedded Software FAT File Allocation Table GP Global Platform IC Integrated Circuit ISD Issuer Security Domain IT Information Technology JCP Java Card Platform JCRE Java Card Runtime Environment OSP Organizational Security Policy PP Protection Profile RNG Random Number Generation ROM Read Only Memory RSA Cryptographic module "Rivest, Shamir, Adleman" SF Security Function SFP Security Function Policy SHA-1 Cryptographic module "Secure hash standard" ST Security Target TOE Target of Evaluation. TSC TSF Scope of Control TSF TOE Security Functions TSP TOE Security Policy VASD Validation Authority Security Domain VHBR Very High Bit Rates (contactless data transfer beyond the ISO14443) VM Virtual Machine 1.3.2 Notations Applet Application which can be loaded and executed with the environment of the Java Card platform Card Issuer Entity that owns the card and is ultimately responsible for the behavior of the card Card Manager Main entity which represents the issuer and supervises the whole services available on the card. The Card Manager entity encompasses the Open and the Issuer Security domain. ID-ONE COSMO V8.2 Public Security Target 10 | 202 DAP Part of the Load File used for ensuring authenticity of the Load File. The DAP is the signature of the Load File Data Block Hash and is provided during the loading. Issuer Security Domain The primary on-card entity providing support for the control, security, and communication requirements of the Card Issuer. Load File Data Block Hash The Load File Data Block Hash provides integrity of the Load File Data Block following receipt of the complete Load File Data Block. OPEN Part of the Card Manager entity which has the responsibilities to provide an API to applications, command dispatch, Application selection, logical channel management, and Card Content management. The OPEN also manages the installation of applications loaded to the card. The OPEN is responsible for enforcing the security policy defined for Card Content management. Security DomainOn-card entity providing support for the control, security, and communication requirements of an off-card entity (e.g. the Card Issuer, an Application Provider or a Controlling Authority). ID-ONE COSMO V8.2 Public Security Target 11 | 202 2 Security Target Introduction This Public Security Target aims to satisfy the requirements of Common Criteria level EAL5+, augmented with AVA_VAN.5, ALC_DVS.2 in defining the security enforcing functions of the Target Of Evaluation and describing the environment in which it operates. The basis for this composite evaluation is the composite evaluation of Platform and the hardware plus the cryptographic and Mifare libraries. 2.1 Product family This Public Security target addresses a family ID-One Cosmo V8.2 based on a NXP component. Family Name Product Name IDEMIA reference code Chip Reference IDEMIA reference Chip Reference/Chip configuration In the public ST lite ID-One Cosmo v8.2 ID-One Cosmo v8.2 on P60D145 091121 P60D145 P6022y VB The platform ‘ID-One Cosmo v8.2 on P60D145’ Platform embeds several javacard applications, i.e. 2.4.4. Applications included in the TOE The present public security target addresses only the platform, regardless the ROMed applications. 2.2 Public Security Target reference The following table defines the information related to the security target and associated evaluation. Title: ID-ONE COSMO v8.2 – Public Security Target Product Family Name: ID-One Cosmo v8.2 Editor: IDEMIA IDEMIA registration: FQR 110 9067 EAL: EAL5+, augmented with: ALC_DVS.2 AVA_VAN.5 ITSEF: CEA LETI Certification Body: ANSSI Evaluation scheme: French More precisely, the security target describes:  The Target Of Evaluation (TOE), including the TOE components, the components in the TOE environment, the product type and its life cycle ID-ONE COSMO V8.2 Public Security Target 12 | 202  The TOE security environment TOE, including assets to be protected and threats to be countered by the TOE and by the operational environment during the development and the platform active phases  The TOE security objectives and its supporting environment in terms of integrity and confidentiality of sensitive information of the TOE  The organizational security policies and the assumptions  The security requirements which include the TOE functional requirements, the TOE assurance requirements and the security requirements for the environment  The summary of the TOE specification including a description of the security functions and assurance measures that meet the TOE security requirements This ID-One Cosmo v8.2 on P60D145 platform is able to receive and manage different types of applications, Basic and Sensitive one (CombICAO, IAS, LDS, PIV, Authentic and ID-One Classic for example…). Some of these applications are in ROM (already loaded in the platform), others can be loaded in EEPROM at the Personalisation phase or at the use phase. The product is open at use phase. 2.3 TOE Reference TOE Name ID-One Cosmo v8.2 Platform Mask / Hardware Identification 091121 Patch ID 094222 - Optional_Code_Generic_DLATCH_on_Cosmo8.2 Label GIT code IDOne_Cosmo_V8.2_091121 IC reference version NXP P60D145 IC configuration NXP P6022Y VB 1- IC ST identification 2- IC ST identification NXP Secure Smart Card Controller P6022y VB Security Target Lite Rev. 2.6 - 23 August 2019 NXP Secure Smart Card Controller P6022y VB Security Target Lite Rev. 2.1 - 6 April 2018 IC EAL EAL6 with augmentations: ALC_FLR.1 and ASE_TSS.2 1- IC certificate 2- IC certificate BSI-DSZ-CC-1059-V3 BSI-DSZ-CC-1059 ID-ONE COSMO V8.2 Public Security Target 13 | 202 NB: Additional Patches can be loaded on the platform. The loading mechanism, part of the TOE, is under the present evaluation. 2.4 TOE Identification This chapter described the TOE identification information that can be retrieved over the GET DATA command. This command is used to retrieve following data objects from the card’s EEPROM. This command works when the Resident Application is active, i.e. when no applet (including the Card Manager itself) is selected or in terminated phase. In use life phase, this command is a Card Manager command. DO Tag DO Length Meaning Reference ‘DF50’ ‘16’ IC Card Manufacturing Proprietary tag ‘DF52’ Variable Card identification Proprietary tag ‘DF66’ ‘0D’ Product Commercial Version Proprietary tag ‘DF67’ ‘07’ Product Internal Version Proprietary tag Table 1: GET DATA P1/P2 – Supported data objects tags 2.4.1 Product Commercial Version (DO ‘DF66’) This command is used to retrieve the Product Commercial Version. The response of the GET DATA ‘DF66’ is structured as following: OS SAAAAR code Commercial Version Length 4 bytes 4 bytes Value ‘091121FF’ ‘08020000’ Table 2: Product Commercial Version data 2.4.2 IC Card Manufacturing Data (tag ‘DF50’) The 37 bytes of the IC Card Manufacturing are structured as following: ID-ONE COSMO V8.2 Public Security Target 14 | 202 Die number Wafer number Batch number Wafer XY Coordinates Time stamp Version subcode Device code ROM code number 4 bytes 1 byte 4 bytes 2 bytes 2 bytes 1 byte 5 bytes 3 bytes P60D145 ‘XXXXXXXX’ ‘XX’ ‘XXXXXXXX’ ‘XXXX’ ‘XXXX’ ‘42’ ’2230XX1700’ ‘423932’ Table 3: IC Card Manufacturing data 2.4.3 Card Identification Data (tag ‘DF52’) This command is used to retrieve the card identification as the mask identification, locks identification and patches identification. ID-ONE COSMO V8.2 Public Security Target 15 | 202 Tag Length Value ‘01’ ‘01’ Hardware platform identifier Length Content Value Meaning 1 Component number ‘30’ Version of the component ‘02’ ‘03’ Hardware platform version Length Content Value Meaning 1 Chip interface ’00’ Enable all available interfaces ‘04’ TCL / contact is available ‘05’ Only TCL is available ‘06’ Only contact is available 2 Maximum NVM Size NVM Size Configuration ‘8E’ for example ‘03’ ‘02’ Mask identification Length Content Value Meaning 1 Mask number ‘6F’ ID-One Cosmo V8.2 1 Mask version ‘01’ ‘04’ ‘XX’ Optional codes identification Length Content 36 Optional Code based on integrity algorithm SHA 256 06 Optional Code based on integrity algorithm CRC 16 First codop (optional code) identification ( if any, please ref to section 2.3 TOE Reference) Length Content 3 Identification in BCD 1 Internal Version in BCD 32 02 Optional code Integrity (SHA 256) Optional code Integrity (CRC 16) 36 or 06 Second codop (optional code) identification ( if any, please ref to section 2.3 TOE Reference) … … ‘05’ ‘01’ FIPS Mode (‘00’ card not configured, ‘01’ card configured for FIPS-140 – see FIPS card lock) ‘06’ ‘xx’ Locks identification Length Content 1 Checksum lock 1 FIPS lock 1 FIPS card lock 4 Post lock ID-ONE COSMO V8.2 Public Security Target 16 | 202 1 CVM lock 1 RFU 1 TCL management lock 1 EC and RSA lock 1 Security lock 1 Biometry lock 1 Rotation lock 1 DLATCH 2 Erase lock 1 MSK Div lock 1 MSK Div verify lock ‘07’ ‘01’ Card state (life cycle) ‘08’ ‘xx’ TCL Historical bytes (only through TCL interface) ‘09’ ‘07’ TCL area ‘0A’ ‘09’ ’A0 XXXX 80 XXXX 81 XXXX’ Key Check Values (MASTER_MSK KCV, MSK KCV & LSK KCV) ‘0B’ ‘06’ ’08020000 0000’ Commercial version & Extended Commercial version ‘0C’ ‘04’ ‘091121 FF’ Item number encoded in BCD ( ‘F’ byte used for not signifying digits) ‘0D’ ‘02’ ‘11’ xxxx Mifare identification : MFPOPTN configuration and MDFOPTN configuration Table 4: Card identification data Application Note: tag ‘04’ ‘XX’, this tag indicates the code optional; if any. 2.4.4 Applications included in the TOE Some applications, Java card applets are included in the product, some are sensitive and others are basic. Except the Card Manager applet, part of the present evaluation; applications listed are not in the scope of the TOE evaluation and are considered as know applet as defined in [R29]. Applet name Version AID Package name CHV2.2 V2.2 A0000000770108080720000000000003 Chv A0000000770108080720000000000002 Cvm A0000000770108080720000000000001 id3 A0000000770108080720000000000006 Pw A0000000770108080720000000000005 pw_fp SAC Server V1.1 A0000000770108000710000000000015 SAC Applet Manager A0000000770108000710000000000018 SAC Java Applet A000000077010000071000000000000E Ldslib LDS V10 V10.1 A0000000770100000710000000000005 Ldseac A000000077010800071000000000000B Server Applet Manager A000000077010800071000000000000D IAS ECC API ID-ONE COSMO V8.2 Public Security Target 17 | 202 Applet name Version AID Package name IAS ECC V2 V2.0 A0000000770108000710000000000013 IAS light Add-On PIV 2.4.1 V2.4.1 A0000000770100000610000000000024 PIV CPS2ter V2 A0000000 77010800 07100000 0000000C CPS2ter Table 5: Aid(s) of applications included in the TOE ID-ONE COSMO V8.2 Public Security Target 18 | 202 3 TOE overview The Smart Card intended to support the TOE is composed of hardware and software components, as listed below and described in Figure 1. Figure 1: Java Platform Architecture The TOE includes the BIOS, the Virtual Machine, the APIs, the Global Platform application, the Resident application and the IC component. Details of components are presented in the TOE description. 3.1 TOE Configuration As for composition with the IC, MIFARE functionality does not implement any SFR and its functionality therefore does not interfere with the security functionality provided by the IC hardware neither the current Java card platform. However, the TOE implements the Post Delivery Configuration (PDC) mechanism in order to tailor the TOE to the specific Mifare options as following: PDC configuration True Maximum NVM Size NO MIFARE ‘8E’ MIFARE CLASSIC 1K ‘8C’ MIFARE CLASSIC 4K ‘89’ MIFARE PLUS 2K ‘8A’ MIFARE PLUS 4K ‘87’ ID-ONE COSMO V8.2 Public Security Target 19 | 202 PDC configuration True Maximum NVM Size MIFARE DESFIRE 2K ‘8B’ MIFARE DESFIRE 4K ‘88’ MIFARE DESFIRE 8K ‘85’ MIFARE DESFIRE 16K ‘7D’ MIFARE DESFIRE 32K ‘6D’ 3.2 TOE Type The ID-One Cosmo v8.2 on NXP is a contact/dual/contactless Java Card platform based, compatible with multi-application ID-One Cosmo product family. The functional level of the OS will be based on a Java™ based multi-application platform, compliant with Java Card 3.0.4 Classic Edition and Global Platform 2.2.1 specifications. 3.2.1 Defensive Java Card Platform The Java technology, embedded on the TOE, combines a subset of the Java programming language with a runtime environment optimized for smart cards and similar small-memory embedded devices. The Java CardTM platform is a smart card platform enabled with Java CardTM technology (also called, for short, a “Java Card”). This technology allows for multiple applications to run on a single card and provides facilities for secure interoperability of applications. Applications running on the Java Card platform (“Java Card applications”) are called applets. The TOE is compliant with the version of the Java Card 3.0.4 classic edition, specified by three documents related to Java Card API, Java Card Runtime Environment and Java Card Virtual Machine Specifications, defined respectively in [R6], [R7] and [R8]. The next paragraph introduces those three elements. As the terminology is sometimes confusing, the term “Java Card System” has been introduced in [R5] that defines the set constituted by the Java Card RE, the Java Card VM and the Java Card API. The Java Card System provides an intermediate layer between the operating system of the card and the applications. This layer allows applications written for one smart card platform enabled with Java Card technology to run on any other such platform. The Java Card VM is a bytecode interpreter embedded in the smart card. The Java Card RE is responsible for card resource management, communication, applet execution, on-card system and applet security. Applet isolation is achieved through the Java Card Firewall mechanism defined in [R7]. This mechanism confines an applet to its own designated memory area. Thus, each applet is prevented from accessing fields and operations related to objects owned by other applets, ID-ONE COSMO V8.2 Public Security Target 20 | 202 unless those applets provide a specific interface (shareable interface) for that purpose. This access control policy is enforced at runtime by the Java Card VM. However, applet isolation cannot be entirely granted by the firewall mechanism if certain well- formedness conditions are not satisfied by loaded applications. Therefore, a bytecode verifier (BCV) formally verifies those conditions. The BCV is out of the scope of the Java Card System defined in [R5]. The IDEMIA platform implements dynamic Verifier that allows the platform to be defensive. Verifications are done during execution of the byte code. And as this security target claims a demonstrable conformance to PP SUN Java Card™ System Protection Profile Open Configuration V3.0, May 2012. The off card verifier is also used. All applications are verified by the latest Oracle off card verifier. Possible Verifier Type When? Off-card bytecode verifier Static Once, outside of the card Runtime verifier Dynamic Every time, during execution The Java Card API (JCAPI) provides classes and interfaces for the core functionality of a Java Card application. It defines the calling conventions by which an applet may access the JCRE and services such as, among others, I/O management functions, PIN and cryptographic specific management and the exceptions mechanism. The JCAPI is compatible with formal international standards, such as ISO/IEC 7816 and industry specific standards. 3.2.2 Global Platform The TOE is compliant with the Global Platform 2.2.1 (GP) standard [R9] which provides a set of APIs and technologies to perform in a secure way, the operations involved in the management of the applications hosted by the card. Using GP maximizes the compatibility and the opportunities of communication as it becomes the current card management standard. The main features addressed by GP are:  The authentication of users through secure channels  The downloading, installation removal, and selection for execution of Java Card applications  The life cycle management of both the card and the applications  The sharing of a global common PIN among all the applications installed on the card These operations are addressed by a set of APIs used by the applications hosted on the card in order to communicate with the external world on a standard basis. The version considered in this document is version 2.2.1 of the GP Card specification. The following GP functionalities, at least, are present within the TOE:  Card content loading  Extradition ID-ONE COSMO V8.2 Public Security Target 21 | 202  Asymmetric keys  DAP support, Mandated DAP support  DAP calculation with asymmetric cryptography  Logical channels  SCP02 support  SCP03 support [R12]  Support for contact and contactless cards different implicit selection on different interfaces and channels  Support for Supplementary Security Domains  Trusted path privileges  Post-issuance personalisation of Security Domain [R12]  Application personalisation [R12] 3.2.3 Integrated Circuit (IC) The platform is designed on NXP components: NXP P60D145/NXP Secure Smart Card Controller P6022y VB. The configuration used is the P6022Y VB for MIFARE Classic, MIFARE Plus and DESFire implementations. ROM = 512KB RAM = 11KB EEPROM = 144KB The IC is an NXP dual interface component that supports ISO/IEC 14443 Type A. It is a hardware device composed of a processing unit, memories, security components and I/O interfaces. It has to implement security features able to ensure: - The confidentiality and the integrity of information processed and flowing through the device, - The resistance of the security IC to externals attacks such as physical tampering, environmental stress or any other attacks that could compromise the sensitive assets stored or flowing through it. The IC configuration used in this project does not include any optional software or optional toolbox. The IC Dedicated Software with MIFARE Classic or MIFARE Plus MF1PLUSx0 or MIFARE DESFire EV1, or both MIFARE Plus MF1PLUSx0 and MIFARE DESFire EV1 or both MIFARE Classic and MIFARE DESFire EV1 are included in the Used IC for the ID-One Cosmo v8.2 Family. ID-ONE COSMO V8.2 Public Security Target 22 | 202 More information regarding the components is available in the public security target of the chip [R26]. 3.2.4 Operating System (OS) The TOE relies on an Operating System (OS) which is an embedded piece of software loaded into the Security IC. The Operating System manages the features and resources provided by the underneath chip. It is, generally divided into two levels: 1. Low level: a. Drivers related to the I/O, RAM, ROM, EEPROM, , and any other hardware component present on the Security IC 2. High level: a. Protocols and handlers to manage I/O b. Memory and file manager c. Cryptographic services and any other high level services provided by the OS 3.2.4.1 BIOS The BIOS is an interface between hardware and native components like VM and APIs. The BIOS implements the following functionalities: - APDU management, using T=0, T=1 and T=CL protocols (Type A and type A VHBR) - Timer management - Exceptions management - Transaction management - EEPROM access 3.2.4.2 Cryptographic features The following crypto services are included in the OS: ID-ONE COSMO V8.2 Public Security Target 23 | 202 Cryptographic Services RSA from 1024 to 4096-bits by step of 256-bits References are standard ones ECC with , 192, 256, 384, 512 and 521-bits key sizes TDES with 56, 112 and 168-bits key sizes AES with 128, 192, 256 key sizes SHA-1, SHA 224, 256, 384 and 512, SHA3-224, SHA3- 256, SHA3-384 and SHA3-512 RSA, ECC Key generation CRC 16 and 32 RNG FIPS AES SP800-90 RSA signature/verification Based on supported RSA key sizes ECDSA signature/verification Based on supported ECC key sizes ECDH Based on supported ECC key sizes AES secure messaging References are standard ones TDES secure messaging HMAC with SHA1 up to SHA 512 ECC with 508, 511-bits key sizes Curve lengths are proprietary. 3.2.4.3 Biometric feature ID-One Cosmo v8.2 embeds the MOC V5.2.0 algorithm. The biometric feature allows matching a CANDIDATE Template with REFERENCE Templates (up to 10) 3.2.4.4 Virtual Machine The Virtual Machine, which is compliant with the Java Card 3.0.4 classic edition, interprets the byte code of Java Card applets. The Virtual Machine supports logical channels; this means that it allows an applet to be selected on a channel, while a different applet is selected on another channel. It also supports secure execution of applets loaded and stored in ROM. The Virtual Machine is activated upon the selection of an applet. 3.2.4.5 The Java Card Runtime Environment The Java Card Runtime Environment (JCRE) contains the Java Card Virtual Machine (VM), the Java Card Application Programming Interface (API) classes and industry-specific extensions, and support services. For details, please refer to reference [R7]. 3.2.4.6 APIs The APIs, compliant with the Java Card 3.0.4 classic edition, support key generation, Key Agreement, signature, ciphering of messages and proprietary IDEMIA API. Proprietary APIs have been developed like ISOSecureMessaging to assure the data are exchanged in confidentiality and integrity; OTPinBio to compare a candidate fingerprint template with one of the reference fingerprint template previously store in the card; utilBER_Reader to read BER-TLV; SecureStore to store integrity sensitive information ID-ONE COSMO V8.2 Public Security Target 24 | 202 3.2.4.7 Open and isolating Platform This security target claims conformance to the Application Note 10 on Open and Isolating platform, issued by ANSSI [R29]. An “open platform” can host new applications: - Before its delivery to the end user (during phases 4, 5 or 6 of the traditional smartcard lifecycle). Such loadings are called “pre-issuance”. - After its delivery to the end user (phase 7). Such loadings are called “post-issuance”. An “isolating platform” is a platform that maintains the separation of the execution domains of all embedded applications on a platform, as of the platform itself. “Isolation” refers here to domain separation of applications as well as protection of application’s data. 3.2.4.8 Resident Application It provides a native code application, with a basic main dispatcher, to receive the card commands and dispatch them to the application and module functions to implement the application commands. It also deals with the Card Manufacturer authentication and logical channels management. The dispatcher is always activated. Some card commands (for administration) are only available during prepersonalisation phase. 3.2.4.9 Applets Applets bytecodes shall go thru the latest Oracle or IDEMIA off card verifiers before the loading. The platform evaluation shall identify, if any, recommendations in order to maintain isolation properties. These recommendations then shall be followed by the applet developer and shall be checked before loading. 3.3 Major Security feature of the TOE The main goal of the TOE is to provide a sound and secure execution environment to critical assets that need to be protected against unauthorized disclosure and/or modification. The TOE with its security function has to protect itself and protect applets from bypassing, abuse or tampering of its services that could compromise the security of all sensitive data. Even if the applets are not in the scope of this evaluation. Atomic Transactions The TOE shall provide a transaction mechanism. It shall execute a sequence of modifications and allocations on the persistent memory so that either all of them are completed, or the TOE behaves as if none of them had been attempted. The transaction mechanism shall permit to update internal TSF data as well as to perform different functions of the TOE, like installing a new package on the card. ID-ONE COSMO V8.2 Public Security Target 25 | 202 This mechanism shall be available for applet instances The TOE shall perform the necessary actions to roll back to a safe state upon interruption. Card Content Management The TOE shall control the loading, installation, and deletion of packages and applet instances. To remove the code of a package from the card, or to definitely deactivate an applet instance, so that it becomes no longer selectable; it shall perform physical removal of those packages and applet data stored in memories (except applet in ROM memory that shall only be logically removed). Card Management Environment This function shall initialize and manage the internal data structure of the Card Manager. During the initialization phase of the card, it creates the Installer and the Applet Deletion Manager and initializes their internal data structures. The internal data structure of the Card Manager includes the Package and Applet Registries, which respectively contains the currently loaded packages and the currently installed applet instances, together with their associated AIDs. This function shall also be in charge of dispatching the APDU commands to the applet instances installed on the card and keeping trace of the currently active ones. It therefore handles sensitive TSF data of other security functions, like the Firewall or the Remote Access Control function. Cardholder Verification The TOE shall implement mechanisms to identify and authenticate the user of the product. This function is available to applet instances. Clearing of sensitive information The TOE shall ensure that no residual information is available from memories, and shall protect sensitive information that is no longer used. The Platform has to securely clear and destroy this information. It concerns PINs, keys, sensitive data (such as D.BIO), buffer APDU. This function is also available to applet. DAP Verification An Application Provider may require that its Application code to be loaded on the card shall be checked for integrity and authenticity. The DAP Verification privilege of the Application Provider’s Security Domain shall provide this service on behalf of the Application Provider. A Controlling Authority may require that all Application code to be loaded onto the card shall be checked for integrity and authenticity. The Mandated DAP Verification privilege of the Controlling Authority’s Security Domain shall provide this service on behalf of the Controlling Authority. Data coherency As coherency of data should be maintained, and as power is provided by the CAD and might be stopped at all moment (by tearing or attacks), a transaction mechanism need to be implemented. ID-ONE COSMO V8.2 Public Security Target 26 | 202 When updating data, before writing the new ones, the old ones are saved in a specific memory area. If a failure appears, at the next start-up, if old data are valid in the transaction area, the system restores them for staying in a coherent state. Data integrity Sensitive data have to be protected from modifications: keys, pins, patch code and sensitive applet data. Encryption and Decryption The TOE provides the applet instances with a mechanism for encrypting and decrypting the contents of a byte array. Ciphering operations are implemented to resist environmental stress and glitches and include measures for preventing information leakage through covert channels. Entity authentication/secure Channel Off-card entity authentication is achieved through the process of initiating a Secure Channel and provides assurance to the card that it is communicating with an authenticated off-card entity. If any step in the off-card authentication process fails, the process shall be restarted (i.e. new session keys generated). The Secure Channel initiation and off-card entity authentication implies the creation of session keys derived from card static key(s). Exception In case of abnormal event: data unavailable on an allocation or illegal access to a data, the system shall own an internal mechanism allowing it to stop the code execution and raise an exception. Firewall The TOE with the Firewall shall control information flow at runtime. It shall ensure controls object sharing between different applet instances, and between applet instances and the Java Card RE. GP_Dispatcher While a Security Domain or Card Manager is selected, the TOE shall test for every command if Security Domain Owner authentication is required. If a secure channel is opened, the TOE tests according to the Security Domain state and the Card state for every command if secure messaging is required. Hardware operating The TOE shall boot after the IC has successfully powered-up. The TOE boot operations shall ensure the correct initialization of the TOE functionalities and the integrity of the code and data. The TOE shall monitor IC detectors (e.g. out-of-range voltage, temperature, frequency, active shield, memory aging) and shall provide automatic answers to potential security violations through interruption routines that leave the device in a secure state. Key Access ID-ONE COSMO V8.2 Public Security Target 27 | 202 The TOE shall enforce secure access to all cryptographic keys on the card: RSA keys, DES keys, EC keys, AES keys Key Agreement The TOE shall provide to applet instances a mechanism for supporting key agreement algorithms such as EC Diffie-Hellman. Key destruction The TOE shall provide secure key destruction, such as keys cannot be retrieved from erased data. Key Distribution The TOE shall enforce the distribution of all the cryptographic keys of the card using a specific method. Key Generation The TOE shall enforce the creation and the on card generation of all the cryptographic keys of the card using a specific method. Key management The TOE shall manage key set: Loading keys, adding a new key set (version and value of the key) or updating a key set (update key value). Manufacturer Authentication During prepersonalisation phase, manufacturer authentication at the beginning of a communication session shall be mandatory prior to any relevant data being transferred to the TOE. Memory failure This security functionality is in charge of the management of bad usage of the memory. Message Digest Message digest generation shall be implemented to resist environmental stress and glitches and include measures for preventing information leakage through covert channels. The TOE shall provide the applet instances with a mechanism for generating an (almost) unique value for the contents of a byte array. This value can be used as a short representative of the information contained in the whole byte array. For Hashing algorithms that do not pad the messages, the TSF checks that the information is block aligned before computing its hash value. Pre-personalisation This function shall permit to pre-initialize the internal data structures, to load the configuration of the card and to load patch code if needed and locks. The TOE shall allow loading of TOE sensitive data: configuration data. Configuration data can contain patches. The TOE shall check the integrity of the incoming data. Unless stated otherwise, the origin of the incoming data shall be ensured by organisational means. The TOE shall ensure that TOE code and patches installed after delivery cannot be bypassed. The loading functionality of patches shall be disabled ID-ONE COSMO V8.2 Public Security Target 28 | 202 before entering the final usage phase. The TOE identification shall take into account the patches installed after delivery. Random Number This TOE functionality provides the card manager, the resident application and the applets a mechanism for generating challenges and key values. The Number Generator is a combination of hardware and software RNG. The RNG is compliant with [R30]. Resident Application dispatcher During prepersonalisation phase, this function shall verify for every command if manufacturer authentication is required. Remote access During prepersonalisation phase, this function shall verify for every command if manufacturer authentication is required. Runtime Verifier This security functionality ensures the secure processing of the stack, heap and transient by ensuring additional controls. Security functions of the IC This TOE functionality ensures the correct execution of the IC functionalities. Signature This TSF shall provide the applet instances with a mechanism for generating an electronic signature of the contents of a byte array and verifying an electronic signature contained in a byte array. An electronic signature is made of a hash value of the information to be signed, encrypted with a secret key. The verification of the electronic signature includes decrypting the hash value and checking that it actually corresponds to the block of signed bytes. Signature operations shall be implemented to resist environmental stress and glitches and include measures for preventing information leakage through covert channels. Unobservability The TOE shall use and manipulate sensitive information without revealing any element of this information. 3.4 NON-TOE HW/SW/FW AVAILABLE TO THE TOE The only non-TOE component required on the product is the bytecode verifier. The bytecode verifier is a program that performs static checks on the bytecodes of the methods of a CAP file. 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 ID-ONE COSMO V8.2 Public Security Target 29 | 202 reference. In other words, bytecodes are verified to hold up to the intended use to which they are defined. This TOE considers static bytecode verification; it has to be performed on the host at off-card verification and prior to the loading of the file on the card in any case. 3.5 TOE usage This Platform is an open and isolating platform that is compliant with the ANSSI Application Note 10 that deals with open and isolating platforms. 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 application. The Java Card System is intended to transform a smart card into a platform capable of executing applications 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. So far, the most 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. This platform provides a highly secure technology for smartcards applications. The Match-On- Card technology is an entire part of the product, and enables the Authentication by way of digital prints. ID-ONE COSMO V8.2 Public Security Target 30 | 202 3.6 TOE Guidances The ID-One Cosmo v8.2 is evaluated with its guidance. The guidance’s of the Platform are listed hereafter: Audience Mandatory Ref Title Developer of sensitive applications Yes [R37] ID-One Cosmo V8.2 Security Recommendations Guidance for application developer No [R38] ID-One Cosmo V8.2 Reference Guide For pre- personalisation Yes [R39] ID-One Cosmo v8.2 Pre-Perso Guide Issuer of the platform that aims to load applications Yes [R40] COSMO V8.1-N Application Loading Protection Guidance Table 6: Guidance references Some guidance are mandatory, they shall be used by its users. Some guidance are not mandatory, they constitute a help to users of the TOE or developer of applet to load on the TOE. 3.6.1 Platform isolation To ensure the platform isolation, see objective OE1 [R29] the following verifications must be done: 1: For library packages intended to be loaded on the platform, the versioning rules described in the Java Card Virtual Machine Specification at chapter “Binary Compatibility” and chapter “Package Version“ must be applied in particular to determine the binary compatibility or incompatibility of this package with a previous version. These rules are also summarized in “GlobalPlatform Card Composition Model Security Guidelines for Basic Applications” at chapter “Versioning”. 2: The byte code verification (required for any package intended to be loaded on the platform) must be done using export files provided by IDEMIA. Those verifications shall be done for all application intended to be loaded on the platform. 3.6.2 Sensitive applications For sensitive application, the recommendations listed in [R37] are mandatory. The evaluator of the sensitive application, checks that the guidance is followed by the sensitive application developer. ID-ONE COSMO V8.2 Public Security Target 31 | 202 The integrity and optionally the confidentiality of the application shall be maintained after the Off card verifier check or after the evaluation and the loading on the TOE. This check shall be ensured by the organisational measures or by security mechanisms. The platform is evaluated without applications. [R37] If the applet needs to have a security certification, the applet must follow recommendations listed in the document. If the applet is a basic application, and does not need security certification with the platform, the certificate of the Platform is still valid if the applet go through the verifier before the loading of this applet (the security function of the platform are still ok). This guide is provided to the Developer and evaluator of a sensitive application to be certified. [R38] This document describes the ID-One Cosmo v8.2 smart card usage. It describes how to use the card from an APDU commands point of view and gets onto topics such as common platform APDU commands, secure channels and security domains. This document also describes the available JavaCard and proprietary APIs for applet developers. This guide is provided to the Developer of an application to be certified or not. [R39] This document describes the pre-personalisation steps that should be followed to correctly initialize the ID-One Cosmo v8.2 platforms. The TOE is finalized once it’s prepersonalised. This guide is provided to the user (in phases 4-5). [R40] This document describes the loading procedure, in compliance with ANSSI Note 10 and the Java Card Open Platform protection profile. The [R40] is provided to the Loading Authority, who is in charge of loading an application. 3.7 TOE Life cycle The development and manufacturing processes of the Composite Product is separated into seven distinct phases to be in accordance with the Java Card™ System Protection Profile (section 2.4, figure 3). Each phase is under the control of one (or several) administrator(s) and protected by an environment. Each phase is covered by the assurance components. ID-ONE COSMO V8.2 Public Security Target 32 | 202 Phase Phase name Description Covered by Reference from [R29] for loading application 1 Security IC Embedded Software development 3.7.2 Phase 1 3.7.2.2 Environment & Roles ALC NA 2 Security IC Development 3.7.3 Phase 2 3.7.3.2 Environment & Roles ALC [IC] NA 3 Security IC Manufacturing 3.7.4 Phase 3 3.7.4.2 Environment & Roles ALC [IC] NA 4 Security IC Packaging 3.7.5 Phase 4 3.7.5.2 Environment & Roles AGD_PRE NA 5 Composite Product Integration 3.7.6 Phase 5 3.7.6.2 Environment & Roles AGD_PRE [ISO_VERIF]: [ORG_LOAD] 6 Composite Product Personalisation 3.7.7 Phase 6 3.7.7.2 Environment & Roles AGD_OPE [ISO_VERIF]: [ORG_LOAD] Or [TECH_LOAD] 7 Operational Usage 3.7.8 Phase 7 3.7.8.2 Environment & Roles AGD_OPE [ISO_VERIF] [TECH_LOAD] Table 7: TOE Life Cycle – Summary [ISO_VERIF]: is related to chapter 3.6.1. [ORG_LOAD] is related organisational measure to ensure the integrity and authenticity of the application after the verifications defined in chapter 3.6.1. This guidance is defined in [R40] [TECH_LOAD] is related to the mandatory use of the mandated DAP specified in the present security target. The guidance is defined in [R40] NB: The patch loading mechanism is evaluated. No patch code can be loaded after phase 5, as the patch loading mechanism is deactivated. The loading, if performed, is done in accordance with ANSSI Note 6 [R33]. ID-ONE COSMO V8.2 Public Security Target 33 | 202 3.7.1 Phases Figure 2: TOE Life Cycle – Overviews Phase Security IC Embedde User Data & Supplement for Security IC Phase Phase Phase Card Manager Card Content Management Card Manager Card Content Phase Phase PRODUCT CONSTRUCTION PRODUCT USAGE Deliver Phase Deliver Deliver Card Manager Card Content Resident Application TOE Delivery TOE is self ID-ONE COSMO V8.2 Public Security Target 34 | 202 3.7.2 Phase 1: Security IC Embedded Software development 3.7.2.1 Description The Phase 1 of the Composite Product life cycle covers: o User Data definition: o Data written during the Security IC manufacturing (Phase 3) and used by the Security IC Embedded Software – covered by ALC [COSMO V8.2] o Data written during the Composite Product Integration (Phase 5) configuring the Security IC Embedded Software – covered by AGD_PRE [COSMO V8.2] o Writing User Data: o Data not requiring encryption during the Security IC manufacturing (Phase 3) – covered by ALC [COSMO V8.2] o Data not requiring encryption during the Composite Product Integration (Phase 5) – covered by AGD_PRE [COSMO V8.2] o Data requiring encryption during the Composite Product Integration (Phase 5) – covered by AGD_PRE [COSMO V8.2] o Security IC Embedded Software development. The software components described in TOE are delivered to the Security IC Manufacturer (Phase 3). This includes conception, design, implementation, testing and documentation by respecting the Environment & Roles (3.7.2.2). The phase fulfils requirements defined in the TOE Reference. At the end of this phase, the Security IC Embedded Software, User Data (written in Phase 3 or Phase 5) and Supplement for Security IC Embedded Software (required in Phase 3 or Phase 5) are transferred by the administrators from the premises of IDEMIA to the IC Manufacturer or Card Manufacturer (by respecting the rules for integrity and confidentiality). ID-ONE COSMO V8.2 Public Security Target 35 | 202 3.7.2.2 Environment & Roles The Security IC Embedded Software described in this document is developed in places under the control of administrators. Phase Phase name Task Company / Administrator Locations Destination 1 Security IC Embedded Software development User Data definition IDEMIA / Security IC Embedded Software Integrator IDEMIA Courbevoie AGD_PRE Writing User Data without encryption IDEMIA / Security IC Embedded Software Integrator IDEMIA Courbevoie IDEMIA / Key Administrator – MSK AGD_PRE Writing User Data with encryption IDEMIA / Security IC Embedded Software Integrator – LSK IDEMIA Courbevoie IDEMIA / Key Administrator – MSK AGD_PRE IDEMIA / Key Administrator – LSK IDEMIA Courbevoie IDEMIA / Key Administrator – MSK Transferring User Data IDEMIA / Key Administrator – MSK IDEMIA Courbevoie IC Manufacturer Software component development ID3 (Biometry algorithm) / Software Developer Grenoble IDEMIA and ID3 / Security IC Embedded Software Integrator IDEMIA / Software Developer IDEMIA Courbevoie Pessac IDEMIA / Security IC Embedded Software Integrator ID-ONE COSMO V8.2 Public Security Target 36 | 202 Phase Phase name Task Company / Administrator Locations Destination Security IC Embedded Software development IDEMIA / Security IC Embedded Software Integrator IDEMIA Courbevoie IDEMIA / Key Administrator – MSK Transferring Security IC Embedded Software IDEMIA / Key Administrator – MSK IDEMIA Courbevoie IC Manufacturer Card Manufacturer Supplement for Security IC Embedded Software (patch code) development IDEMIA / Software Developer & IDEMIA / Security IC Embedded Software Integrator IDEMIA Courbevoie IDEMIA / Security IC Embedded Software Integrator – LSK IDEMIA / Key Administrator – LSK Supplement for Security IC Embedded Software (patch code) encryption IDEMIA / Security IC Embedded Software Integrator – LSK IDEMIA Courbevoie IDEMIA / Key Administrator – MSK IDEMIA / Key Administrator – LSK IDEMIA Courbevoie Transferring Supplement for Security IC Embedded Software (patch code) IDEMIA / Key Administrator – MSK IDEMIA Courbevoie IC Manufacturer Card Manufacturer Table 8: Security IC Embedded Software development Environment & Roles ID-ONE COSMO V8.2 Public Security Target 37 | 202 To ensure security, access to development tools and products elements (computer, emulator, card reader, documentation, source code including patches, locks, etc...) is protected. The protection is based on measures for prevention and detection of unauthorized access. The following levels of protection are applied: o Access control to IDEMIA offices and sensitive areas, o Access control to ID3 offices and sensitive areas, that lay on the ID3 site audit, o Access to development data through the use of a secure computer system to design, implement and test software. The Software Developers are in charge to develop software components (BIOS, Resident Application, API, ...) and Supplement for Security IC Embedded Softwares. The Security IC Embedded Software Integrators are in charge to build the Security IC Embedded Software from the software components and define data managed by the Security IC Embedded Software (User Data). They may cipher User Data requiring a secure writing and the Supplement for Security IC Embedded Software by using LSK key. The Key Administrators may cipher the User Data requiring a secure writing (not already ciphered by Security IC Embedded Software Integrators) and the Supplement for Security IC Embedded Software requiring a secure loading (not already ciphered by Security IC Embedded Software Integrators) by using LSK key. They transfer User Data (required in Phase 3), the Security IC Embedded Software and Supplement for Security IC Embedded Software (required in Phase 3) to IC Manufacturer by using MSK. They transfer the Supplement for Security IC Embedded Software (required in Phase 5) to Card Manufacturer by using MSK. 3.7.3 Phase 2: Security IC Development 3.7.3.1 Description The Phase 2 of the Composite Product life cycle covers Security IC development which is described in the IC ST identification (see TOE Reference). 3.7.3.2 Environment & Roles The Security IC Development is described in the certification reference of the Security IC (2.3 TOE Reference). 3.7.4 Phase 3: Security IC Manufacturing 3.7.4.1 Description The Phase 3 of the Composite Product life cycle covers Security IC Manufacturing which is described in the IC ST identification (see TOE Reference). The Security IC manufacturer writes: o Security IC Embedded Software developed in Phase 1 in persistent memory (ROM) o User Data (static or dynamic) needed by the Security IC Embedded Software in volatile memory (EEPROM) o Supplement for Security IC Embedded Software (if required in TOE Reference) developed in Phase 1 in volatile memory (EEPROM) The delivery of the Security IC occurs at the end of this phase in form of wafers. The Security IC Embedded Software is protected by a secret (MSK). The delivery of the TOE occurs at the end of the Phase 3. ID-ONE COSMO V8.2 Public Security Target 38 | 202 3.7.4.2 Environment & Roles The Security IC Manufacturing is described in the certification reference of the Security IC (2.3 TOE Reference). 3.7.5 Phase 4: JavaCard Platform Packaging 3.7.5.1 Description The JavaCard Platform delivered by the IC Manufacturer to the Card Issuer / Integrator is integrated in an appropriate form factor (card, token …) required by the end-consumer. 3.7.5.2 Environment & Roles The JavaCard Platform described in this document is packaged in places under the control of administrators. Phase Phase name Tasks Administrators 4 Javacard Platform Packaging Javacard Platform Packaging IC Packaging Manufacturer Packaging Testing IC Packaging Manufacturer Table 9: Javacard Platform Packaging Roles 3.7.6 Phase 5: Composite Product Integration 3.7.6.1 Description From this phase, the Javacard Platform Embedded Software is activated. The Card Life Cycle is defined by the Card Manager Life cycle. The states in this phase are Pre_production, OP_READY and INITIALIZED. This Card Life Cycle begins in state Pre_production. During this state, the Resident Application manages the Javacard Platform Embedded Software and ensures the security. This state supports: o the Javacard Platform Embedded Software configuration (by loading User Data in clear, User Data ciphered, Supplement for Javacard Platform Embedded Software ciphered by LSK), o the Card Content Management (activating Load File from persistent memory, loading, installation, and deletion of Load Files and applet instances), o Card Manager configuration (first key-set, …). By switching from the Pre_production state up to OP_READY, the Card Manager replaces the Resident Application. From this state, the Card Manager ensures the Card Content Management (loading, installation, and deletion of Load Files and applet instances) and provides security in place of the Resident Application. At the end of this phase, the Card Life Cycle state is INITIALIZED. ID-ONE COSMO V8.2 Public Security Target 39 | 202 3.7.6.2 Environment & Roles The Composite Product described in this document is integrated under the control of administrators. This table below summarizes the administrators available during this phase and the secret securing it. Phase Phase Name Card life cycle state Target Selected Target State Authentication Administrator Secret 5 Composite Product Integration Pre_production Resident Application Pre_production Card Manufacturer MSK (Table 11) OP_READY Issuer SD (ISD) OP_READY Card Issuer / ISK Admin (ISK)d (Table 11) Supplementary SD (SSD) INSTALLED SELECTABLE The Security Domain can only be used if the keys have been populated (PERSONALIZED). In these states, the Issuer Security Domain is used for the Card Content Management. The possible actions are consistent with the selection of ISD. PERSONALIZED Application Provider (AMK)d (Table 11) INITIALIZED Issuer SD (ISD) INITIALIZED Card Issuer / KMC Admin (KMC)d (Table 11) Supplementary SD (SSD) INSTALLED SELECTABLE The Security Domain can only be used if the keys have been populated (PERSONALIZED). In these states, the Issuer Security Domain is used for the Card Content Management. The possible actions are consistent with the selection of ISD. PERSONALIZED Application Provider (AMK)d (Table 11) Table 10: Composite Product Integration – Administrators ID-ONE COSMO V8.2 Public Security Target 40 | 202 The Card Manufacturer is the entity responsible for producing smart cards on behalf of the Card Issuer. This entity manages applications through a secure communication channel with the card until the card manager is initialized (OP_READY state). It is in charge of: o Authentication, o configuring the Javacard Platform Embedded Software by writing the User Data (in clear or encrypted), o loading securely Supplement for Javacard Platform Embedded Software (patch code developed in Phase 1) in volatile memory (EEPROM), o activating Load Files from immutable persistent memory (ROM), o instantiating the Card Manager and populating the initialization key (ISK), o Card Content Management, o Switching the Card Life Cycle from Pre_production to OP_READY . The Card Issuer is the entity that owns the card and is ultimately responsible for the behaviour of the card. It is initially the only entity authorized to manage applications through a secure communication channel with the card. According to the secret managed by the Card Issuer, we separate this entity in several: o Card Issuer / ISK Admin (this entity replaces Card Manufacturer) o Card Issuer / KMC Admin (this entity replaces the Card Issuer / ISK Admin) Each one is in charge of: o Authentication, o Card Content Management, o Card Life Cycle administration. The Application Provider personalizes their applications and Security Domains (SSD) in a confidential manner. It has Security Domain keysets enabling them to be authenticated to the corresponding Security Domain and to establish a trusted channel between the TOE and an external trusted device. These Security Domain final keysets are not known by the Card issuer. The Application Provider is in charge of: o Authentication, o Providing the Load Files, o Personalizing the SSD associated (if required by the Application Provider). The Application Administrator is in charge of: o Personalizing the application. ID-ONE COSMO V8.2 Public Security Target 41 | 202 The table below summarizes the secret used by the administrators during this phase. Secret Name Definition MSK Manufacturer MSK shared between the the Card Manufacturer and the Card Issuer and protects the card from any entity besides the Card Manufacturer and the Card Issuer. (ISK)d First key-set if the Card Issuer to protect the card during the transport if this step of personalisation is shared by two entities. (KMC)d Initial key-set of the Card Issuer that ensures mutual authentication, provides command integrity during the Secure Channel initiation and provides confidentiality for keys within Secure Channel session. (AMK)d Application Key-set that ensures mutual authentication, provides command integrity during the Secure Channel initiation and provides confidentiality for keys within Secure Channel session. Kdap This key ensures that application code being loaded to the card has been verified by the Controlling Authority or the Application Provider. Table 11: Composite Product Integration – Keysets 3.7.7 Phase 6: Composite Product Personalisation 3.7.7.1 Description The Card Life Cycle states defined in this phase are INITIALIZED and then SECURED. These states allow the Card Content Management. According to the “Environment & Roles”, the applets already instantiated may be personalized. Additional Load Files may be loaded. The applets may be instantiated and personalized. At the end of this phase: o Card Life Cycle state is SECURED the Security Domain Mandated DAP is fully operational (PERSONALIZED) and protects the Load File loading during Phase 7. ID-ONE COSMO V8.2 Public Security Target 42 | 202 3.7.7.2 Environment & Roles The Composite Product described in this document is personalized in places under the control of administrators. Phase Phase Name Card life cycle state Target Selected Target State Authentication Administrator Secret 6 Composite Product Personalisation INITIALIZED Issuer SD (ISD) INITIALIZED Card Issuer / KMC Admin (KMC)d (Table 13) Supplementary SD (SSD) INSTALLED SELECTABLE The Security Domain can only be used if the keys have been populated (PERSONALIZED). In these states, the Issuer Security Domain is used for the Card Content Management. The possible actions are consistent with the selection of ISD. PERSONALIZED Application Provider (AMK)d (Table 13) SECURED Issuer SD (ISD) SECURED Card Issuer / CMK Admin (CMK)d (Table 13) Supplementary SD (SSD) INSTALLED SELECTABLE The Security Domain can only be used if the keys have been populated (PERSONALIZED). In these states, the Issuer Security Domain is used for the Card Content Management. The possible actions are consistent with the selection of ISD. PERSONALIZED Application Provider (AMK)d (Table 13) Table 12: Composite Product Personalisation – Administrators ID-ONE COSMO V8.2 Public Security Target 43 | 202 The Card Issuer is the entity that owns the card and is ultimately responsible for the behaviour of the card. It is an entity authorized to manage applications through a secure communication channel with the card. According to the secret managed by the Card Issuer, we separate this entity in several: o Card Issuer / KMC Admin o Card Issuer / CMK Admin (this entity replaces the Card Issuer / KMC Admin) Each one is in charge of: o Authentication, o Card Content Management, o Card Life Cycle administration. The Application Provider personalizes their applications and Security Domains (SSD) in a confidential manner. It has Security Domain keysets enabling them to be authenticated to the corresponding Security Domain and to establish a trusted channel between the TOE and an external trusted device. These Security Domain keysets are not known by the Card issuer. The Application Provider is in charge of: o Authentication, o Providing and Loading the Load Files o Personalizing the SSD associated (if required by the Application Provider). The Application Administrator is in charge of: o Instantiating and personalizing the application. The Controlling Authority is a trusted third party which ensures the integrity of the Load Files. This Controlling Authority gives a DAP signature for all Load Files requiring a loading during the Phase 7. Without this signature, no more Load File can be added into the card. The Controlling Authority creates the Verification Authority into the card (SSD mandated DAP initialized with Kdap). The Verification Authority, trusted third party represented on the card by a SSD mandated DAP is responsible for the verification of applications signatures during the loading process. This SSD is personalized by a Controlling Authority. This SSD is protected by a keyset (AMK)d. The key verification is named Kdap. This DAP signature is optional during this phase, but becomes mandatory during the Phase 7. ID-ONE COSMO V8.2 Public Security Target 44 | 202 Secret Name Definition (KMC)d Initial key-set of the Card Issuer that ensures mutual authentication, provides command integrity during the Secure Channel initiation and provides confidentiality for keys within Secure Channel session. (AMK)d Application Key-set that ensures mutual authentication, provides command integrity during the Secure Channel initiation and provides confidentiality for keys within Secure Channel session. Kdap This key ensures that application code being loaded to the card has been verified by the Controlling Authority (CMK)d Final key-set of the Card Issuer that ensures mutual authentication, provides command integrity during the Secure Channel initiation and provides confidentiality for keys within Secure Channel session. Table 13: Composite Product Personalisation – Keysets 3.7.8 Phase 7: Operational Usage 3.7.8.1 Description In this phase, the Card Life Cycle state is SECURED. This state allows the Card Content Management. According to the “Environment & Roles”, the applets may be instantiated and personalized from Load File already present or from additional Load File loaded during this phase. The applets already instantiated may be personalized. Additional Load File may be loaded but requires a DAP Verification to ensure the Load File integrity. This verification is carried out by Security Domain Mandated DAP (see Protection Profile). ID-ONE COSMO V8.2 Public Security Target 45 | 202 3.7.8.2 Environment & Roles The Composite Product described in this document may be personalized in unprotected environment under the control of administrators. Phase Phase Name Card life cycle state Target Selected Target State Authentication Administrator Secret 7 Operational Usage SECURED Issuer SD (ISD) SECURED Card Issuer / CMK Admin (CMK)d (Table 15) Supplementary SD (SDD) INSTALLED SELECTABLE The Security Domain can only be used if the keys have been populated (PERSONALIZED). In these states, the Issuer Security Domain is used for the Card Content Management. The possible actions are consistent with the selection of ISD. PERSONALIZED Application Provider (AMK)d (Table 15) Table 14: Operational Usage – Administrators ID-ONE COSMO V8.2 Public Security Target 46 | 202 The Card Issuer is the entity that owns the card and is ultimately responsible for the behaviour of the card. It manages applications through a secure communication channel with the card by using a secret. During this phase, the Card Issuer is named: o Card Issuer / CMK Admin It is in charge of: o Authentication, o Card Content Management, o Card Life Cycle administration. The Application Provider personalizes their applications and Security Domains (SSD) in a confidential manner. It has Security Domain keysets enabling them to be authenticated to the corresponding Security Domain and to establish a trusted channel between the TOE and an external trusted device. These Security Domain keysets are not known by the Card issuer. The Application Provider is in charge of: o Authentication, o Providing and Loading Load Files including the DAP signature (from the Controlling Authority). The Verification Authority ensures the verification of the DAP signature. o Instantiating and personalizing the SSD associated (if required). The Application Administrator is in charge of: o Instantiating and personalizing the application. The Controlling Authority is a trusted third party which ensures the integrity of the Load Files. This Controlling Authority gives a DAP signature for all Load Files requiring a loading during this phase. Without this signature, no Load File can be added into the card. The Controlling Authority creates the Verification Authority into the card (SSD mandated DAP initialized with Kdap). The Verification Authority, trusted third party represented on the card by a SSD mandated DAP is responsible for the verification of applications signatures during the loading process. This SSD is in the state PERSONALIZED (keyset and Kdap initialized). This DAP signature is mandatory during this phase for loading all new Load Files. Keyset Name Definition (AMK)d Application Key-set that ensures mutual authentication, provides command integrity during the Secure Channel initiation and provides confidentiality for keys within Secure Channel session. Kdap This key ensures that application code being loaded to the card has been verified by the Controlling Authority (CMK)d Final key-set of the Card Issuer that ensures mutual authentication, provides command integrity during the Secure Channel initiation and provides confidentiality for keys within Secure Channel session. Table 15: Operational Usage – Keysets ID-ONE COSMO V8.2 Public Security Target 47 | 202 3.8 Software Components Life Cycle 3.8.1 Card Life Cycle Figure 3: Card Life Cycle Pre_production This initial life state of the Card allows managing the prepersonalisation of the Javacard Platform Embedded Software up to the Card Manager Life Cycle OP_READY. During this state, the Resident Application provides a set of APDU commands which allows: o Writing User Data for configuring the Javacard Platform Embedded Software. This configuration (by using lock mechanism) is only carried out during this state. o Writing Supplement for Javacard Platform Embedded Software (patch code). It is developed at IDEMIA premises (Phase 1), delivered and loaded securely in volatile memory (EEPROM) during the Composite Product Integration (Phase 5). The security of this loading is fully enforced by technical measures provided by the TOE, and evaluated by the ITSEF. This task is only carried out during this state. o Activating Load Files from immutable persistent memory (ROM). This task is only carried out during this state. o Loading Load Files from mutable persistent memory (EEPROM). o Instantiating the Issuer Security Domain (Card Manager). Only one ISD is available by card. ID-ONE COSMO V8.2 Public Security Target 48 | 202 o Populating with initialization key (ISK) and Chip CPLC. The Card Life Cycle switchs automatically in OP_READY state when the initialization key (ISK) is populated in the ISD. The APDU commands depend on the mutual authentication carries out (by using MSK). The next states possible are OP_READY or TERMINATED. The transition is irreversible. OP_READY During this life cycle state, all the basic functionalities of the runtime environment are available and the Card Manager is ready to receive, execute and respond to APDU commands. During this state, a new keyset have to be loaded before switching to INITIALIZED life state. The card is assumed to have the following functionalities in the OP_READY state: o The runtime environment is ready for execution. o An Initialization key is available within the Card Manager. o Card Content Management operations are supported. o Post-issuance personalisation of applets belonging to the Card Issuer can be carried out via the Card Manager. The next states possible are INITIALIZED or TERMINATED. The transition is irreversible. INITIALIZED This life state is an administrative card production state. Most of the personalisation of the Card Manager is performed when entering in this state. The card is assumed to have the following functionalities in the INITIALIZED state: o The runtime environment is ready for execution. o A keyset is available within the Card Manager. o Card Content Management operations are supported. o Post-issuance personalisation of applets belonging to the Card Issuer can be carried out via the Card Manager. The next states possible are SECURED or TERMINATED. The transition is irreversible. SECURED The Card life cycle state SECURED is the normal operating life cycle state of the card after issuance. This state is the indicator for the Card Manager to enforce the Card Issuer’s security policies related to post-issuance card behaviour such as applet loading and activation. The card is assumed to have the following functionality in the state SECURED: o The Card Manager contains all necessary key sets and security elements for full functionality. o Card Issuer initiated card content changes can be carried out through the Card Manager. o Card Content Management operations are supported. o Post-issuance personalisation of applets belonging to the Card Issuer can be carried out via the Card Manager. The next states possible are CM_LOCKED or TERMINATED. The transition in the TERMINATED state is irreversible. ID-ONE COSMO V8.2 Public Security Target 49 | 202 CM_LOCKED The state CM_LOCKED is used to instruct the Card Manager to temporarily disable all applets on the card except for the Card Manager. This state is created to give the Card Issuer the ability to temporarily disable functionality of the card on detection of security threats (either internal or external to the card). Setting the Card Manager to this state implies that the card will no longer work, except via the Card Manager which is controlled by the Card Issuer. No Card Content Management operation is possible. The next states possible are SECURED or TERMINATED. The transition in the TERMINATED state is irreversible. TERMINATED The Card Manager is set to the life cycle state TERMINATED to permanently disable all card functionalities including the functionality of the Card Manager itself. This state is created as a mechanism for the Card Issuer to logically ‘destroy’ the card for such reasons as the detection of a severe security threat or upon expiration of the card. Only GET DATA (CPLC) command is available. No Card Content Management operation is possible. The Card Manager state TERMINATED is irreversible and signals the end of the card’s life cycle. 3.8.2 Security Domain Life Cycle States The Security Domain Life Cycle begins when a Security Domain is instantiated in the card. The Security Domain Life Cycle States defined by Global Platform are INSTALLED, SELECTABLE, PERSONALIZED and LOCKED. There are no proprietary Security Domain Life Cycle States. Figure 4: Security Domain Life Cycle illustrates the state transition diagram for the Security Domain Life Cycle. This can typically be viewed as a sequential process with certain possibilities for reversing a state transition or skipping states. Figure 4: Security Domain Life Cycle ID-ONE COSMO V8.2 Public Security Target 50 | 202 INSTALLED The state INSTALLED means that the Security Domain becomes an entry in the Global Platform Registry and this entry is accessible to off-card entities authenticated by the associated Security Domain. The Security Domain is not yet available for selection. It cannot be associated with Executable Load Files or Applications yet and therefore its Security Domain services are not available to Applications. SELECTABLE The state SELECTABLE means that the Security Domain is able to receive commands (specifically personalisation commands) from off-card entities. As they still do not have keys, the Security Domains cannot be associated with Executable Load Files or Applications and therefore their services are not available to Applications when they are in this state. The state transition from INSTALLED to SELECTABLE is irreversible. The transition to SELECTABLE may be combined with the Security Domain installation process. PERSONALIZED The definition of what is required for a Security Domain to transition to the state PERSONALIZED is Security Domain dependent but is intended to indicate that the Security Domain has all the necessary personalisation data and keys for full runtime functionality (i.e. usable in its intended environment). The transition from SELECTABLE to PERSONALIZED is irreversible. In the state PERSONALIZED, the Security Domain may be associated with Applications and its services become available to these associated Applications. LOCKED The OPEN, the Security Domain itself, the Security Domain’s associated Security Domain (if any), an Application with the Global Lock privilege or a Security Domain with the Global Lock privilege uses the state LOCKED as a security management control to prevent the selection of the Security Domain. If the OPEN detects a threat from within the card and determines that the threat is associated with a particular Security Domain, that Security Domain may be prevented from further selection by the OPEN setting the Security Domain’s Life Cycle State to LOCKED. Alternatively, the off-card entity may determine that a particular Security Domain on the card needs to be locked for a business or security reason and may initiate the state transition via the OPEN. Locking a Security Domain prevents this Security Domain from being associated with new Executable Load Files or Applications. In this state DAP verification, extradition and access to that Security Domain’s services shall fail. In summary, if a Security Domain is in the lifecycle state LOCKED, it shall reject all received commands. Once the Life Cycle State is LOCKED, only the Security Domain’s associated Security Domain (if any), an Application with Global Lock privilege or a Security Domain with Global Lock privilege is allowed to unlock the Security Domain. The OPEN shall ensure that the Security Domain’s Life Cycle returns to its previous state. DELETED At any point in the Security Domain Life Cycle, the OPEN may receive a request to delete a Security Domain. ID-ONE COSMO V8.2 Public Security Target 51 | 202 The space previously used to store a physically deleted Security Domain is reclaimed and may be reused. The entry within the Global Platform Registry shall no longer be available, and the OPEN is not required to maintain a record of the deleted Security Domain’s previous existence. 3.8.3 Load File Life Cycle The Load Files Life Cycle begins when a Load File is activated from immutable persistent memory (ROM) or loaded in mutable persistent memory (EEPROM). Figure 5: Load File Life Cycle illustrates the state transition diagram for the Load File Life Cycle. This can typically be viewed as a sequential process. Figure 5: Load File Life Cycle The Load Files activated (Phase 5) or loaded (Phase 5 and/or 6) must satisfy a process using the following tools: o Compiler: software that generates machine-independent code (bytecode) o Converter: software that preprocesses all of the Java programming language class files that make up a package, and converts the package to a standard file format for the binary compatibility of the Java Card platform (CAP file). The Converter also produces an export file. o Loader: software that transfers the Load File. During the Phase 7, the TOE must prevent the installation of a package that has not been bytecode verified, or that has been modified after bytecode verification. The loading process requires adding the proof of the origin of the Load File (computed by off-card entity) and verifying it by a Security Domain with Mandated DAP privilege. The following tools are used: o Compiler: software that generates machine-independent code (bytecode) o Converter: software that preprocesses all of the Java programming language class files that make up a package, and converts the package to a standard file format for the binary compatibility of the Java Card platform (CAP file). The Converter also produces an export file. o Verifier: software that performs static checks on the bytecodes of the methods of a CAP file and generates a signature . o Loader: software that transfers the Load File (including the ). The bytecode, CAP file, DAP Block can be generated from any software. LOADED The state LOADED is the initial life state just after it has been activated (from the Resident Application) or loaded (from the Resident Application or the Card Manager). ID-ONE COSMO V8.2 Public Security Target 52 | 202 This state is independent of the visibility of the Load File (Get Status command of the Card Manager) and just depends on the presence in the Global Platform registry. DELETED The OPEN may receive a request to delete a Load File. For Load Files in EEPROM, the space previously used to store a physically deleted Load File is reclaimed and may be reused. For Load Files in ROM, a flag definitely prohibits further use. The entry within the Global Platform Registry is also removed, and the OPEN is not required to maintain a record of the deleted Load File’s previous existence. 3.8.4 Application Life Cycle The Application Life Cycle begins when an applet is instantiated in the card. This instantiation may occur directly after loading transaction or alternatively from a Load File which is present on the card. The Application Life Cycle States defined by Global Platform are INSTALLED, SELECTABLE or LOCKED. Figure 6: Application Life Cycle, illustrates the state transition diagram for the Application Life Cycle. This can typically be viewed as a sequential process with certain possibilities for reversing a state transition or skipping states. In addition to these states, the Application may define its own Application dependent states. Once the Application reaches the SELECTABLE state, it is responsible for managing the next steps of its own Life Cycle. It may use any Application specific states as long as these do not conflict with the states already defined by Global Platform. The OPEN may not perform these transitions without instruction from the Application and the Application is responsible for defining state transitions and ensuring that these transitioning rules are respected. Figure 6: Application Life Cycle INSTALLED The INSTALLED state means that the Application executable code has been properly linked and that any necessary memory allocation has taken place. The Application becomes an entry in the Global Platform Registry and this entry is accessible to authenticated off-card entities. The Application is not yet selectable. The installation process is not intended to incorporate personalisation of the Application, which may occur as a separate step. ID-ONE COSMO V8.2 Public Security Target 53 | 202 SELECTABLE The SELECTABLE state implies that the applet is able to receive commands from off-card entities. The state transition from INSTALLED to SELECTABLE is irreversible. The Application shall be properly installed and functional before it may be set to the SELECTABLE state. The transition to SELECTABLE may be combined with the Application installation process. The behaviour of the Application in the SELECTABLE state is beyond the scope of this Specification. LOCKED The OPEN or the off-card entity authenticated by the Issuer Security Domain uses the state LOCKED as a security management control to prevent the selection, and therefore the execution, of the Application. If the OPEN detects a threat from within the card and determines that the threat is associated to a particular Application, this Application may be prevented from further selection by the OPEN setting its state to LOCKED. Alternatively, the off-card entity authenticated by the Issuer Security Domain may determine that a particular Application on the card needs to be locked for a business or security reason and may initiate the Application Life Cycle transition via the OPEN. Once the state is LOCKED, only the Issuer Security Domain is allowed to unlock the Application. The OPEN shall ensure that the Application Life Cycle returns to its previous state. DELETED At any point in the Application Life Cycle, the OPEN may receive a request to delete an Application. The space previously used to store a physically deleted Application is reclaimed and may be reused. The entry within the Global Platform Registry is also removed, and the OPEN is not required to maintain a record of the deleted Application’s previous existence. Application Specific Life Cycle States These states are Application specific. The behaviour of the Applet during these states is determined by the Applet itself and is beyond the scope of this document. The OPEN does not enforce any control on Application specific Life Cycle State transitions. ID-ONE COSMO V8.2 Public Security Target 54 | 202 4 Common Criteria conformance claim 4.1 Common Criteria This security Target claims conformance to the Common Criteria version 3.1 revision 5, with the following documents: [1] “Common Criteria for information Technology Security Evaluation, Part 1: Introduction and general model”, April 2017, Version 3.1 revision 5. [2] “Common Criteria for information Technology Security Evaluation, Part 2: Security Functional component”, April 2017, Version 3.1 revision 5. [3] “Common Criteria for information Technology Security Evaluation, Part 3: Security Assurance components”, April 2017, Version 3.1 revision 5. The Conformance to the Common Criteria is claims as follows: Common Criteria Conformance rationale Part 1 conformance Part 2 Conformance to the extended part. FCS_RNG.1: “Random number generation” Part 3 Compliant to EAL5 +, augmented with - ALC_DVS.2: “Sufficiency of security measures” (highest component) - AVA_VAN.5: “Advanced methodical vulnerability analysis” (highest component) Table 16: CC conformance rationale 4.2 Protection Profile This security target claims a demonstrable conformance to: PP SUN Java Card™ System Protection Profile Open Configuration V3.0, May 2012. The product is in conformance with the minimum assurance level EAL5+ augmented with ALC_DVS.2 and AVA_VAN.5 described in paragraph 3.2 of the Protection Profile by claiming an evaluation level EAL5+ augmented with ALC_DVS.2 and AVA_VAN.5. 4.3 Conformance claim rationale This paragraph presents the consistency between the security target and the Java Card System Open configuration profile Protection Profile. ID-ONE COSMO V8.2 Public Security Target 55 | 202 4.3.1 TOE Type conformance The TOE type is in conformance with the TOE type described in the protection profile. For more information on this point, please refer to chapter 2.1 of this security target. 4.3.2 SPD Statement Consistency 4.3.2.1 Assets All assets from the protection profile are included in the security target. The following assets have been added: Assets Rationale D.CONFIG This asset defines the elements of configuration during the prepresonalization phase D.SENSITIVE_DATA This asset describes the set of sensitive data to be protected D.ARRAY This asset describes the applets sensitive data D.JCS_KEYS This asset describes two cryptographic keys used during the loading of a file in the card D.BIO This asset describes the biometric sensitive data NB: D.BIO asset is already described in the protection profile in the appendix. 4.3.2.2 Threats All threats from the protection profile are included in the security target. Three additional threats have been added in the security target: Threats Rationale T.CONFIGURATION This threat is directly linked to D.CONFIG T.CONF_DATA_APPLET This threat is directly linked to D.ARRAY T.PATCH_LOADING This threat is directly linked to patch loading 4.3.2.3 OSPs All the OSP from the protection profile is included in the security target, no additional OSP have been added. 4.3.2.4 Assumptions ID-ONE COSMO V8.2 Public Security Target 56 | 202 All the assumptions from the protection profile have been added in the security target, except A.DELETION. A.DELETION has been removed from the security target because the deletion of applets is in the scope of the evaluation, as O.CARD_MANAGEMENT is an objective in this security target. 4.3.3 Objectives 4.3.3.1 Security Objectives for the TOE All the security objectives for the TOE from the protection profile are included in the security target. The following security objectives have been added: Security objectives for the TOE Rationale O.SCP.SUPPORT This security objective comes from a security objective for the operational environment O.SCP.IC This security objective comes from a security objective for the operational environment O.SCP.RECOVERY This security objective comes from a security objective for the operational environment O.RESIDENT_APPLICATION This security objective deals with the security of the resident application O.CARD_MANAGEMENT This security objective comes from a security objective for the operational environment O.SECURE_COMPARE This security objective is linked to D.ARRAY O.PATCH_LOADING This security objective is related to patch loading 4.3.3.2 Security Objectives for the Operational Environment All the security objectives for the operational environment are included in the security target. Some security objectives for the operational environment has been transformed in security objectives for the TOE, the rationale is presented in the previous chapter. 4.3.4 SFR and SARs Statements consistency 4.3.4.1 SFRs Consistency All the SFR from the protection profile have been added in the security target. The following SFR have been added in the security target: Additional SFR for the Card Manager SFR Rationale ID-ONE COSMO V8.2 Public Security Target 57 | 202 FPT_TST.1 Initial startup test in case of future requirement FCO_NRO.2/CM_DAP Refinement of the requirements in terms of non-repudiation of the origin to the Card Manager during the DAP process FIA_AFL.1/CM Concerns applets composition evaluation FIA_UAU.1/CM Concerns smartcard product and composition FIA_UAU.4/CardIssuer Prevents from Card Issuer authentication reuse FIA_UAU.7/CardIssuer Defines the authentication process FPR_UNO.1/Key_CM Prevents from observation of import key operation FPT_TDC.1/CM Technical requirement for communication with another trusted IT product FMT_SMR.2/CM Defines several roles FCS_COP.1/CM Defines the Cryptographic algorithm available to the CM for the Card Issuer authentication Additional SFR for the resident application SFR Rationale FDP_ACC.2/PP Access control policy during prepersonalisation FDP_ACF.1/PP Access control functions during prepersonalisation FDP_UCT.1/PP Precision of the prepersonalisation access control regarding inter-TSF user data confidentiality transfer protection FDP_ITC.1/PP Precision of the import of user data during prepersonalisation FIA_AFL.1/PP Precision of the authentication failures during prepersonalisation FIA_UAU.1/PP Precision of the user accessible functions before user authentication during prepersonalisation FIA_UID.1/PP Precision of the user accessible functions before user identification during prepersonalisation FMT_MSA.1/PP Precision of the management of the security attributes during prepersonalisation FMT_SMF.1/PP Precision of the specification of the management functions during prepersonalisation FIA_ATD.1/CardManu Precision of the user attribute during prepersonalisation FIA_UAU.4/CardManu Prevents from Card Manufacturer authentication reuse during prepersonalisation FIA_UAU.7/CardManu Defines the authentication process of the Card Manufacturer during prepersonalisation FMT_MOF.1/PP Management of functions of the TSF during prepersonalisation, especially for the resident application FMT_SMR.2/PP Restrictions on security roles during prepersonalisation ID-ONE COSMO V8.2 Public Security Target 58 | 202 FMT_MSA.3/PP Precision of the security attribute initialization during prepersonalisation FCS_COP.1/PP Cryptographic operation available during prepersonalisation FCS_CKM.4/PP Cryptographic key destruction during prepersonalisation FDP_UIT.1/PP Ensures the integrity of the patch loaded FCS_CKM.1/PP Provides the MSK diversification FTP_ITC.1/PP Defines the trusted channel for the patch and locks loading FAU_STG.2 Provides the patch identification evidence Additional SFR for the SmartCard Platform SFR Rationale FPT_PHP.3/SCP Additional security features are added in the product, using security features of the IC FPT_FLS.1/SCP Technical requirement for composition FPT_RCV.3/SCP Additional SFR regarding operational objective on the operational environment transformed in security objectives FPT_RCV.4/SCP Additional SFR regarding operational objective on the operational environment transformed in security objectives FRU_FLT.1/SCP Additional SFR regarding operational objective on the operational environment transformed in security objectives FCS_RNG.1/SCP Additional SFR for RNG management FPR_UNO.1/USE_KEY Additional SFR for the unobservability of keys FIA_AFL.1/PIN Precision of the authentication failures for the PIN FMT_MTD.2/GP_PIN Additional SFR for the management of limits on TSF data regarding the GP PIN FPR_UNO.1/Applet Additional SFR for the unobservability of array comparison by applets, regarding D.ARRAY FMT_MTD.1/PIN Additional SFR for the management of TSF data regarding the PIN FIA_AFL.1/GP_PIN Precision of the authentication failures for the GP PIN Additional SFR for the BIO SFR Rationale FIA_AFL.1/PIN_BIO Precision of the authentication failures for the PIN BIO FMT_MTD.1/PIN_BIO Additional SFR for the management of TSF data regarding the PIN BIO Additional SFR for the stack control ID-ONE COSMO V8.2 Public Security Target 59 | 202 SFR Rationale FDP_ACC.2/RV_Stack Access control policy for stack control FDP_ACF.1/RV_Stack Access control functions for stack control FMT_MSA.1/RV_Stack Precision of the Stack access control SFP FMT_MSA.2/RV_Stack Precision of the secure security attributes for stack control FMT_MSA.3/RV_Stack Precision of the static attribute initialization for stack control FMT_SMF.1/RV_Stack Specification of management functions for stack control Additional SFR for the heap access SFR Rationale FDP_ACC.2/RV_Heap Access control policy for heap access FDP_ACF.1/RV_Heap Access control functions for heap access FMT_MSA.1/RV_Heap Precision of the heap access control SFP FMT_MSA.2/RV_Heap Precision of the secure security attributes for heap control FMT_MSA.3/RV_Heap Precision of the static attribute initialization for heap control FMT_SMF.1/RV_Heap Specification of management functions for heap control Additional SFR for the transient control SFR Rationale FDP_ACC.2/RV_Transient Access control policy for transient control FDP_ACF.1/RV_Transient Access control functions for transient control FMT_MSA.1/RV_Transient Precision of the transient access control SFP FMT_MSA.2/RV_Transient Precision of the secure security attributes for transient control FMT_MSA.3/RV_Transient Precision of the static attribute initialization for transient control FMT_SMF.1/RV_Transient Specification of management functions for transient control ID-ONE COSMO V8.2 Public Security Target 60 | 202 5 Security aspects This chapter describes the main security issues of the Java Card System and its environment addressed in this Security Target, called “security aspects”, in a CC-independent way. In addition to this, they also give a semi-formal framework to express the CC security environment and objectives of the TOE. They can be instantiated as assumptions, threats, objectives (for the TOE and the environment) or organizational security policies. For instance, we will define hereafter the following aspect: #.OPERATE (1) The TOE must ensure continued correct operation of its security functions. (2) The TOE must also return to a well-defined valid state before a service request in case of failure during its operation. TSFs must be continuously active in one way or another; this is called “OPERATE”. The Security Target may include an assumption, called “A.OPERATE”, stating that it is assumed that the TOE ensures continued correct operation of its security functions, and so on. However, it may also include a threat, called “T.OPERATE”, to be interpreted as the negation of the statement #.OPERATE. In this example, this amounts to stating that an attacker may try to circumvent some specific TSF by temporarily shutting it down. The use of “OPERATE” is intended to ease the understanding of this document. This section presents security aspects that will be used in the remainder of this document. Some being quite general, we give further details, which are numbered for easier cross- reference within the document. For instance, the two parts of #.OPERATE, when instantiated with an objective “O.OPERATE”, may be met by separate SFRs in the rationale. The numbering then adds further details on the relationship between the objective and those SFRs. 5.1 Confidentiality #.CONFID-APPLI-DATA: Application data must be protected against unauthorized disclosure. This concerns logical attacks at runtime in order to gain read access to other application’s data. #.CONFID-JCS-CODE: Java Card System code must be protected against unauthorized disclosure. Knowledge of the Java Card System code may allow bypassing the TSF. This concerns logical attacks at runtime in order to gain a read access to executable code, typically by executing an application that tries to read the memory area where a piece of Java Card System code is stored. #.CONFID-JCS-DATA: Java Card System data must be protected against unauthorized disclosure. This concerns logical attacks at runtime in order to gain a read access to Java Card System data. Java Card System data includes the data managed by the Java Card RE, the Java Card VM and the internal data of Java Card platform API classes as well. 5.2 Integrity #.INTEG-APPLI-CODE: ID-ONE COSMO V8.2 Public Security Target 61 | 202 Application code must be protected against unauthorized modification. This concerns logical attacks at runtime in order to gain write access to the memory zone where executable code is stored. In post-issuance application loading, this threat also concerns the modification of application code in transit to the card. #.INTEG-APPLI-DATA: Application data must be protected against unauthorized modification. This concerns logical attacks at runtime in order to gain unauthorized write access to application data. In post- issuance application loading, this threat also concerns the modification of application data contained in a package in transit to the card. For instance, a package contains the values to be used for initializing the static fields of the package. #.INTEG-JCS-CODE: Java Card System code must be protected against unauthorized modification. This concerns logical attacks at runtime in order to gain write access to executable code. #.INTEG-JCS-DATA: Java Card System data must be protected against unauthorized modification. This concerns logical attacks at runtime in order to gain write access to Java Card System data. Java Card System data includes the data managed by the Java Card RE, the Java Card VM and the internal data of Java Card API classes as well. 5.3 Unauthorized executions #.EXE-APPLI-CODE: Application (byte)code must be protected against unauthorized execution. This concerns (1) invoking a method outside the scope of the accessibility rules provided by the access modifiers of the Java programming language ([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. #.EXE-JCS-CODE: Java Card System bytecode must be protected against unauthorized execution. Java Card System bytecode includes any code of the Java Card RE or API. This concerns (1) invoking a method outside the scope of the accessibility rules provided by the access modifiers of the Java programming language([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 instances, and isolation of their data and code between packages (that is, controlled execution contexts) as well as between packages and the JCRE context. An applet shall not read, write, compare a piece of data belonging to an applet that is not in the same context, or execute one of the methods of an applet in another context without its authorization. #.NATIVE: Because the execution of native code is outside of the JCS TSF scope, it must be secured so as to not provide ways to bypass the TSFs of the JCS. Loading of native code, which is as well outside those TSFs, is submitted to the same requirements. Should native software be ID-ONE COSMO V8.2 Public Security Target 62 | 202 privileged in this respect, exceptions to the policies must include a rationale for the new security framework they introduce. 5.4 Bytecode verification #.VERIFICATION Bytecode must be verified prior to being executed. Bytecode verification includes (1) how well- formed CAP file is and the verification of the typing constraints on the bytecode, (2) binary compatibility with installed CAP files and the assurance that the export files used to check the CAP file correspond to those that will be present on the card when loading occurs. 5.4.1 CAP file verification Bytecode verification includes checking at least the following properties: (3) bytecode instructions represent a legal set of instructions used on the Java Card platform; (4) adequacy of bytecode operands to bytecode semantics; (5) absence of operand stack overflow/underflow; (6) control flow confinement to the current method (that is, no control jumps to outside the method); (7) absence of illegal data conversion and reference forging; (8) enforcement of the private/public access modifiers for class and class members; (9) validity of any kind of reference used in the bytecodes (that is, any pointer to a bytecode, class, method, object, local variable, etc actually points to the beginning of piece of data of the expected kind); (10) enforcement of rules for binary compatibility (full details are given in [R8], [R42], [R43]). The actual set of checks performed by the verifier is implementation-dependent, but shall at least enforce all the “must clauses” imposed in [R8] 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 Security Target assumes bytecode verification is performed off-card. Another important aspect to be considered about bytecode verification and application downloading is, first, the assurance that every package required by the loaded applet is indeed on the card, in a binary-compatible version (binary compatibility is explained in [R8] §4.4), second, that the export files used to check and link the loaded applet have the corresponding correct counterpart on the card. 5.4.2 Integrity and authentication Verification off-card is useless if the application package is modified afterwards. The usage of cryptographic certifications coupled with the verifier in a secure module is a simple means to prevent any attempt of modification between package verification and package installation. Once a verification authority has verified the package, it signs it and sends it to the card. Prior to the installation of the package, the card verifies the signature of the package, which authenticates the fact that it has been successfully verified. In addition to this, a secured ID-ONE COSMO V8.2 Public Security Target 63 | 202 communication channel is used to communicate into the card, ensuring that no modification has been performed on it. Alternatively, the card itself may include a verifier and perform the checks prior to the effective installation of the applet or provide means for the bytecodes to be verified dynamically. 5.4.3 Linking and authentication 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. 5.5 Card management #.CARD_MANAGEMENT: (4) The card manager (CM) shall control the access to card management 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: (5) The TOE must be able to return to a safe and consistent state when the installation of a package or an applet fails or be cancelled (whatever the reasons). (2) Installing an applet must have no effect on the code and data of already installed applets. The installation procedure should not be used to bypass the TSFs. In short, it is an atomic operation, free of harmful effects on the state of the other applets. (3) The procedure of loading and installing a package shall ensure its integrity and authenticity. #.SID: (6) Users and subjects of the TOE must be identified. (2) The identity of sensitive users and subjects associated with administrative and privileged roles must be particularly protected; this concerns the Java Card RE, the applets registered on the card, and especially the default applet and the currently selected applet (and all other active applets in Java Card System 2.2.x). A change of identity, especially standing for an administrative role (like an applet impersonating the Java Card RE), is a severe violation of the Security Functional Requirements (SFR). Selection controls the access to any data exchange between the TOE and the CAD and therefore, must be protected as well. The loading of a package or any exchange of data through the APDU buffer (which can be accessed by any applet) can lead to disclosure of keys, application code or data, and so on. #OBJ-DELETION: (7) Deallocation of objects should not introduce security holes in the form of references pointing to memory zones that are not longer in use, or have been reused for other purposes. Deletion of collection of objects should not be maliciously used to circumvent the TSFs. (2) Erasure, if deemed successful, shall ensure that the deleted class instance is no longer accessible. #DELETION: (8) Deletion of installed applets (or packages) should not introduce security holes in the form of broken references to garbage collected code or data, nor should they alter integrity or ID-ONE COSMO V8.2 Public Security Target 64 | 202 confidentiality of remaining applets. The deletion procedure should not be maliciously used to bypass the TSFs. (2) Erasure, if deemed successful, shall ensure that any data owned by the deleted applet is no longer accessible (shared objects shall either prevent deletion or be made inaccessible). A deleted applet cannot be selected or receive APDU commands. Package deletion shall make the code of the package no longer available for execution. (3) Power failure or other failures during the process shall be taken into account in the implementation so as to preserve the SFRs. This does not mandate, however, the process to be atomic. For instance, an interrupted deletion may result in the loss of user data, as long as it does not violate the SFRs. The deletion procedure and its characteristics (whether deletion is either physical or logical, what happens if the deleted application was the default applet, the order to be observed on the deletion steps) are implementation-dependent. The only commitment is that deletion shall not jeopardize the TOE (or its assets) in case of failure (such as power shortage). Deletion of a single applet instance and deletion of a whole package are functionally different operations and may obey different security rules. For instance, specific packages can be declared to be undeletable (for instance, the Java Card API packages), or the dependency between installed packages may forbid the deletion (like a package using super classes or super interfaces declared in another package). 5.6 Services #.ALARM: The TOE shall provide appropriate feedback upon detection of a potential security violation. This particularly concerns the type errors detected by the bytecode verifier, the security exceptions thrown by the Java Card VM, or any other security-related event occurring during the execution of a TSF. #.OPERATE: (9) The TOE must ensure continued correct operation of its security functions. (2) In case of failure during its operation, the TOE must also return to a well-defined valid state before the next service request. #.RESOURCES: The TOE controls the availability of resources for the applications and enforces quotas and limitations in order to prevent unauthorized denial of service or malfunction of the TSFs. This concerns both execution (dynamic memory allocation) and installation (static memory allocation) of applications and packages. #.CIPHER: The TOE shall provide a means to the applications for ciphering sensitive data, for instance, through a programming interface to low-level, highly secure cryptographic services. In particular, those services must support cryptographic algorithms consistent with cryptographic usage policies and standards. #.KEY-MNGT: The TOE shall provide a means to securely manage cryptographic keys. This includes: (1) Keys shall be generated in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes, (2) Keys must be distributed in accordance with specified cryptographic key distribution methods, (3) Keys must be initialized before being used, (4) Keys shall be destroyed in accordance with specified cryptographic key destruction methods. ID-ONE COSMO V8.2 Public Security Target 65 | 202 #.PIN-MNGT: The TOE shall provide a means to securely manage PIN objects. This includes: (1) Atomic update of PIN value and try counter, (2) No rollback on the PIN-checking function, (3) Keeping the PIN value (once initialized) secret (for instance, no clear-PIN-reading function), (4) Enhanced protection of PIN’s security attributes (state, try counter…) in confidentiality and integrity. #.SCP: The smart card platform must be secure with respect to the SFRs. Then: (1) After a power loss, RF signal loss or sudden card removal prior to completion of some communication protocol, the SCP will allow the TOE on the next power up to either complete the interrupted operation or revert to a secure state. (2) It does not allow the SFRs to be bypassed or altered and does not allow access to other low-level functions than those made available by the packages of the Java Card API. That includes the protection of its private data and code (against disclosure or modification) from the Java Card System. (3) It provides secure low- level cryptographic processing to the Java Card System. (4) It supports the needs for any update to a single persistent object or class field to be atomic, and possibly a low-level transaction mechanism. (5) It allows the Java Card System to store data in “persistent technology memory” or in volatile memory, depending on its needs (for instance, transient objects must not be stored in non-volatile memory). The memory model is structured and allows for low–level control accesses (segmentation fault detection). (6) It safely transmits low– level exceptions to the TOE (arithmetic exceptions, checksum errors), when applicable. Finally, I required that (7) the IC is designed in accordance with a well-defined set of policies and standards (for instance, those specified in [R24]), and will be tamper resistant to actually prevent an attacker from extracting or altering security data (like cryptographic keys) by using commonly employed techniques (physical probing and sophisticated analysis of the chip). This especially matters to the management (storage and operation) of cryptographic keys. #.TRANSACTION: The TOE must provide a means to execute a set of operations atomically. This mechanism must not jeopardise the execution of the user applications. The transaction status at the beginning of an applet session must be closed (no pending updates). ID-ONE COSMO V8.2 Public Security Target 66 | 202 6 Security Problem Definition 6.1 Assets Assets are security-relevant elements to be directly protected by the TOE. Confidentiality of assets is always intended with respect to un-trusted people or software, as various parties are involved during the first stages of the smart card product life-cycle; details are given in threats hereafter. Assets may overlap, in the sense that distinct assets may refer (partially or wholly) to the same piece of information or data. For example, a piece of software may be either a piece of source code (one asset) or a piece of compiled code (another asset), and may exist in various formats at different stages of its development (digital supports, printed paper). This separation is motivated by the fact that a threat may concern one form at one stage, but be meaningless for another form at another stage. The assets to be protected by the TOE are listed below. They are grouped according to whether it is data created by and for the user (User data) or data created by and for the TOE (TSF data). For each asset it is specified the kind of dangers that weigh on it. 6.1.1 User data D.APP_CODE The code of the applets and libraries loaded on the card. To be protected from unauthorized modification. D.APP_C_DATA Confidential sensitive data of the applications, like the data contained in an object, a static field of a package, a local variable of the currently executed method, or a position of the operand stack. To be protected from unauthorized disclosure. D.APP_I_DATA Integrity sensitive data of the applications, like the data contained in an object, a static field of a package, a local variable of the currently executed method, or a position of the operand stack. To be protected from unauthorized modification. D.APP_KEYs Cryptographic keys owned by the applets. To be protected from unauthorized disclosure and modification. D.PIN Any end-’ser's PIN. To be protected from unauthorized disclosure and modification. ID-ONE COSMO V8.2 Public Security Target 67 | 202 6.1.2 TSF data D.API_DATA Private data of the API, like the contents of its private fields. To be protected from unauthorized disclosure and modification. D.CRYPTO Cryptographic data used in runtime cryptographic computations, like a seed used to generate a key. To be protected from unauthorized disclosure and modification. D.JCS_CODE The code of the Java Card System. To be protected from unauthorized disclosure and modification. D.JCS_DATA The internal runtime data areas necessary for the execution of the Java Card VM, such as, for instance, the frame stack, the program counter, the class of an object, the length allocated for an array, any pointer used to chain data-structures. To be protected from unauthorized disclosure or modification. D.SEC_DATA The runtime security data of the Java Card RE, like, for instance, the AIDs used to identify the installed applets, the currently selected applet, the current context of execution and the owner of each object. To be protected from unauthorized disclosure and modification. 6.1.3 Additional assets D.CONFIG The configuration DATA are put at prepersonalisation phase. These elements of configuration have to be loaded securely. To be protected from unauthorized disclosure or modification. D.SENSITIVE_DATA The other sensitive data are grouped in the same D.Sensitive Data. The list is presented below: o D.NB_AUTHENTIC: Number of authentications. This number is specified in the SFR o D.NB_REMAINTRYOWN: Number of remaining tries for owner PIN. This number is specified in the SFR o D.NB_REMAINTRYGLB: Number of remaining tries for a global PIN. This number is specified in the SFR o ASG.CARDREG: Card registry (AS.APID: Applet Identifier (AID), AS.CMID: Card Manager ID (AID)) o ASG.APPRIV: Applet privileges group (Card Manager lock privilege, Card terminate privilege, Default selected privilege, PIN change privilege, Security ID-ONE COSMO V8.2 Public Security Target 68 | 202 Domain privilege, Security Domain with DAP verification privilege, Security Domain with Mandated DAP verification privilege) o AS.AUTH_MSK_STATUS: Authentication MSK Status o AS.AUTH_CM_STATUS: Authentication CM Status o AS.CMLIFECYC: Card life cycle state o AS.MSKKEY: MSK (Manufacturer Secret Key) o AS.SECURITY_LEVEL: Security levels of a Secure Channel (Confidentiality, Integrity or both) To be protected from unauthorized disclosure and modification. o D.NB_REMAINTRYOTPINBIO: Number of remaining tries for PIN BIO object. This number is specified by the applet. o D.TRESHOLDOTPINBIO: Threshold value used for Match On Card comparison. This value is specified by the applet. D.ARRAY Applets are enabled to store confidential data. To be protected from unauthorized disclosure and modification. D.BIO Any biometric template. To be protected from unauthorized disclosure and modification. Application note: This asset is similar to D.PIN asset. The handling of D.BIO is performed in the same way than D.PIN. The same objectives (for the conformity, we added the O.BIO- MNGT, issued from appendix 2, chapter2), threats, SFR and others relevant security elements applicable to D.PIN are applicable to D.BIO. D.JCS_KEYS AS.KEYSET_VERSION and AS.KEYSET_Value Cryptographic keys used when loading a file into the card. To be protected from unauthorized disclosure and modification. 6.2 Users / Subjects 6.2.1 Additional Users / Subjects S.RESIDENT_APPLICATION The resident application R.personaliser Card Issuer or card Manufacturer R.Prepersonaliser Card manufacturer U.Card_Issuer The Card Issuer is the entity that own the card and is ultimately responsible for the behaviour of the card. It is initially the only entity authorized to manage applications through a secure communication channel with the card. ID-ONE COSMO V8.2 Public Security Target 69 | 202 U.Card_Manufacturer The Card Manufacturer is the entity responsible for producing smart cards on behalf of the Card Issuer. 6.2.2 Miscellaneous S.ADEL The applet deletion manager which also acts on behalf of the card issuer. It may be an applet ([R7], §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 §7.1.3.1. S.APPLET Any applet instance. S.BCV The bytecode verifier (BCV), which acts on behalf of the verification authority who is in charge of the bytecode verification of the packages. This subject is involved in the PACKAGE LOADING security policy S.CAD The CAD represents the actor that requests, by issuing commands to the card, for RMI services. It also plays the role of the off-card entity that communicates with the S.INSTALLER. S.INSTALLER The installer is the on-card entity which acts on behalf of the card issuer. This subject is involved in the loading of packages and installation of applets. S.JCRE The runtime environment under which Java programs in a smart card are 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 ob’ect'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. ID-ONE COSMO V8.2 Public Security Target 70 | 202 S.TOE Source code. 6.3 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. 6.3.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, D.BIO. 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.CRYPTO and D.JCS_KEYS. 6.3.2 INTEGRITY T.INTEG-APPLI-CODE The attacker executes an application to alter (part of) its own code or another applica’ion's code. See #.INTEG-APPLI-CODE for details. Directly threatened asset(s): D.APP_CODE. T.INTEG-APPLI-CODE.LOAD The attacker modifies (part of) its own or another application code when an application package is transmitted to the card for installation. See #.INTEG-APPLI-CODE for details. Directly threatened asset(s): D.APP_CODE. T.INTEG-APPLI-DATA The attacker executes an application to alter (part of) another applica’ion's data. See #.INTEG-APPLI-DATA for details. Directly threatened asset(s): D.APP_I_DATA, D.PIN, D.BIO and D.APP_KEYs. T.INTEG-APPLI-DATA.LOAD ID-ONE COSMO V8.2 Public Security Target 71 | 202 The attacker modifies (part of) the initialization data contained in an application package when the package is transmitted to the card for installation. See #.INTEG-APPLI-DATA for details. Directly threatened asset(s): D.APP_I_DATA and D_APP_KEY. T.INTEG-JCS-CODE The attacker executes an application to alter (part of) the Java Card System code. See #.INTEG-JCS-CODE for details. Directly threatened asset(s): D.JCS_CODE. T.INTEG-JCS-DATA The attacker executes an application to alter (part of) Java Card System or API data. See #.INTEG-JCS-DATA for details. Directly threatened asset(s): D.API_DATA, D.SEC_DATA, D.JCS_DATA, D.JCS_KEYS and D.CRYPTO. Other attacks are in general related to one of the above, and aimed at disclosing or modifying on-card information. Nevertheless, they vary greatly on the employed means and threatened assets, and are thus covered by quite different objectives in the sequel. That is why a more detailed list is given hereafter. 6.3.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.BIO, D.JCS_KEYS and D.APP_KEYs. T.SID.2 The attacker modifies the’TOE's attribution of a privileged role (e.g. default applet and currently selected applet), which allows illegal impersonation of this role. See #.SID for further details. Directly threatened asset(s): D.SEC_DATA (any other asset may be jeopardized should this attack succeed, depending on whose identity was forged). 6.3.4 UNAUTHORIZED EXECUTION T.EXE-CODE.1 An applet performs an unauthorized execution of a method. See #.EXE-JCS-CODE and #.EXE-APPLI-CODE for details. Directly threatened asset(s): D.APP_CODE. T.EXE-CODE.2 An applet performs an execution of a method fragment or arbitrary data. See #.EXE-JCS- CODE and #.EXE-APPLI-CODE for details. ID-ONE COSMO V8.2 Public Security Target 72 | 202 Directly threatened asset(s): D.APP_CODE. T.NATIVE An applet executes a native method to bypass a TOE Security Function such as the firewall. See #.NATIVE for details. Directly threatened asset(s): D.JCS_DATA. 6.3.5 DENIAL OF SERVICE T.RESOURCES An attacker prevents correct operation of the Java Card System through consumption of some resources of the card: RAM or NVRAM. See #.RESOURCES for details. Directly threatened asset(s): D.JCS_DATA. 6.3.6 CARD MANAGEMENT T.DELETION The attacker deletes an applet or a package already in use on the card, or uses the deletion functions to pave the way for further attacks (putting the TOE in an insecure state). See #.DELETION for details). Directly threatened asset(s): D.SEC_DATA and D.APP_CODE. T.INSTALL The attacker fraudulently installs post-issuance of an applet on the card. This concerns either the installation of an unverified applet or an attempt to induce a malfunction in the TOE through the installation process. See #.INSTALL for details. Directly threatened asset(s): D.SEC_DATA (any other asset may be jeopardized should this attack succeed, depending on the virulence of the installed application). 6.3.7 SERVICES T.OBJ-DELETION The attacker keeps a reference to a garbage collected object in order to force the TOE to execute an unavailable method, to make it to crash, or to gain access to a memory containing data that is now being used by another application. See #.OBJ-DELETION for further details. Directly threatened asset(s): D.APP_C_DATA, D.APP_I_DATA and D.APP_KEYs. 6.3.8 MISCELLANEOUS T.PHYSICAL The attacker discloses or modifies the design of the TOE, its sensitive data or application code by physical (opposed to logical) tampering means. This threat includes IC failure analysis, electrical probing, unexpected tearing, and DPA. That also includes the modification of the runtime execution of Java Card System or SCP software through alteration of the intended execution order of (set of) instructions through physical tampering techniques. This threatens all the identified assets. This threat refers to the point (7) of the security aspect #.SCP, and all aspects related to confidentiality and integrity of code and data. ID-ONE COSMO V8.2 Public Security Target 73 | 202 6.3.9 Additional threats T.CONFIGURATION The attacker tries to observe or modify configuration information exchanged between the TOE and 73nitializatment. The TOE in this phase must protect itself from modification or theft. Even the field is protected by assurance measures, each operations realised in this phase has to be protected. T.CONF_DATA_APPLET The attacker tries to observe the operation of comparison between two byte arrays in order to catch confidential information manipulated. T.PATCH_LOADING The attacker tries to avoid the loading of a genuine patch, alter a patch (during loading or once loaded), or to exploit the patch loading mechanism to load unauthenticated code on the TOE, in order to get access to the assets, the TSF data or the TOE user data, or to modify the TSF. 6.4 Organisational Security Policies This section describes the organizational security policies to be enforced with respect to the TOE environment. OSP.VERIFICATION This policy shall ensure the consistency between the export files used in the verification and those used for installing the verified file. The policy must also ensure that no modification of the file is performed in between its verification and the signing by the verification authority. See #.VERIFICATION for details. OE.VERIFICATION guarantees the correct integrity and authenticity evidences for each application, by means of elements provided by OE.CODE- EVIDENCE. 6.5 Assumptions This section introduces the assumptions made on the environment of the TOE. Due to the Protection Profile and Security Target definition, T.DELETION replaces A.DELETION as O.CARD_MANAGEMENT replaces OE.CARD_MANAGEMENT. A.APPLET Applets loaded post-issuance do not contain native methods. The Java Card specification explici“ly "does not include support for native met”ods" ([R8], §3.3) outside the API. A.VERIFICATION All the bytecodes are verified at least once, before the loading, before the installation or before the execution, depending on the card capabilities, in order to ensure that each bytecode is valid at execution time. ID-ONE COSMO V8.2 Public Security Target 74 | 202 7 Security Objectives 7.1 Security Objectives for the TOE This section defines the security objectives to be achieved by the TOE. 7.1.1 IDENTIFICATION O.SID The TOE shall uniquely identify every subject (applet, or package) before granting it access to any service. 7.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. O.RESOURCES The TOE shall control the availability of resources for the applications. See #.RESOURCES for details. ID-ONE COSMO V8.2 Public Security Target 75 | 202 7.1.3 SERVICES O.ALARM The TOE shall provide appropriate feedback information upon detection of a potential security violation. See #.ALARM for details. O.CIPHER The TOE shall provide a means to cipher sensitive data for applications in a secure way. In particular, the TOE must support cryptographic algorithms consistent with cryptographic usage policies and standards. See #.CIPHER for details. O.KEY-MNGT The TOE shall provide a means to securely manage cryptographic keys. This concerns the correct generation, distribution, access and destruction of cryptographic keys. See #.KEY- MNGT. O.PIN-MNGT The TOE shall provide a means to securely manage PIN objects. See #.PIN-MNGT for details. 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 cou’ter's value is as sensitive as that of the PIN. O.BIO-MNGT The TOE shall provide a means to securely manage biometric templates. This concerns the package javacardx.biometry of the Java Card platform. Application note: This objective is similar to O.PIN-MNGT. It answers to the same threats. O.TRANSACTION The TOE must provide a means to execute a set of operations atomically. See #.TRANSACTION for details. O.KEY-MNGT, O.PIN-MNGT, O.BIO-MNGT, O.TRANSACTION, O.PIN-MNGT, O.BIO-MNGT and O.CIPHER are actually provided to applets in the form of Java Card APIs. Vendor-specific libraries can also be present on the card and made available to applets; those may be built on top of the Java Card API or independently. These proprietary libraries will be evaluated together with the TOE. 7.1.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. ID-ONE COSMO V8.2 Public Security Target 76 | 202 7.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 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). 7.1.6 Additional security objectives for the TOE Four security objectives for the operational environment defined in the PP JCS have been transformed in security objectives for the TOE:  OE.SCP.IC  OE.SCP.SUPPORT  OE.SCP.RECOVERY  OE.CARD_MANAGEMENT O.SCP.SUPPORT The TOE shall support the following functionalities: o 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. o It provides secure low-level cryptographic processing to the Java Card System and Global Platform. o 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. o It allows the Java Card System to store data“in "persistent technology me”ory" 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). ID-ONE COSMO V8.2 Public Security Target 77 | 202 O.SCP.IC The SCP shall possess IC security features. It shall provide all IC security features against physical attacks. It is required that the IC is designed in accordance with a well-defined set of policies and standards (likely specified in another protection profile), and will be tamper resistant to actually prevent an attacker from extracting or altering security data (like cryptographic keys) by using commonly employed techniques (physical probing and sophisticated analysis of the chip). This especially matters to the management (storage and operation) of cryptographic keys. O.SCP.RECOVERY If there is a loss of power, or if the smart card is withdrawn from the CAD while an operation is in progress, the SCP must allow the TOE to eventually complete the interrupted operation successfully, or recover to a consistent and secure state. The smart card platform must be secure with respect to the SFRs. Then after a power loss or sudden card removal prior to completion of some communication protocol, the SCP will allow the TOE on the next power up to either complete the interrupted operation or revert to a secure state. O.RESIDENT_APPLICATION This objective concerns the resident application. It provides a native code application, with a basic main dispatcher to receive card commands and dispatch them to the application and module functions that implement the application commands. It also deals with the Card Manufacturer authentication and logical channels management. The dispatcher is always activated. Some card commands (for administration) are only available during prepersonalisation phase. It ensures the personaliser authentication before allowing operations in writing of the resident application. 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 is’uer's policy on the card. The card manager is an application with specific rights, which is responsible for the administration of the smart card. This component will in practice be tightly connected with the TOE, which in turn shall very likely rely on the card manager for the effective enforcing of some of its security functions. Typically the card manager shall be in charge of the life cycle of the whole card, as well as that of the installed applications (applets). The card manager should prevent that card content management (loading, installation, deletion) is carried out, for instance, at invalid states of the card or by non-authorized actors. It shall also enforce security policies established by the card issuer. O.SECURE_COMPARE The TOE shall provide to applet a means to securely compare two byte arrays. O.PATCH_LOADING The TOE shall provide a secure patch code loading mechanism. 7.2 Security objectives for the Operational Environment This section introduces the security objectives to be achieved by the environment. ID-ONE COSMO V8.2 Public Security Target 78 | 202 Four security objectives for the operational environment from the PP JCS have been transformed in security objectives for the TOE:  OE.SCP.SUPPORT  OE.SCP.IC  OE.SCP.RECOVERY  OE.CARD_MANAGEMENT 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 audited organizational measures must ensure that loaded application has not been changed since the code verifications required in OE.VERIFICATION. For application code loaded post-issuance and verified off-card according to the requirements of OE.VERIFICATION, the verification authority shall provide digital evidence to the TOE that the application code has not been modified after the code verification and that he is the actor who performed code verification. For application code loaded post-issuance and partially or entirely verified on-card, technical measures must ensure that the verification required in OE.VERIFICATION are performed. On-card bytecode verifier is out of the scope of this Security Target. Application Note: For application code loaded post-issuance and verified off-card, the integrity and authenticity evidence can be achieved by electronic signature of the application code, after code verification, by the actor who performed verification. 7.3 Security Objectives Rationale 7.3.1 Threats 7.3.1.1 CONFIDENTIALITY T.CONFID-APPLI-DATA This threat is countered by the security objective for the operational environment regarding bytecode verification (OE.VERIFICATION). It is also covered by the isolation commitments stated in the (O.FIREWALL) objective. It relies in its turn on the ID-ONE COSMO V8.2 Public Security Target 79 | 202 correct identification of applets stated in (O.SID). Moreover, as the firewall is dynamically enforced, it shall never stop operating, as stated in the (O.OPERATE) objective. As the firewall is a software tool automating critical controls, the objective O.ALARM asks for it to provide clear warning and error messages, so that the appropriate counter-measure can be taken. The objectives O.CARD_MANAGEMENT and OE.VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode, respectively. The objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the O.OPERATE and O.ALARM objectives of the TOE, so they are indirectly related to the threats that these latter objectives contribute to counter. As applets may need to share some data or communicate with the CAD, cryptographic functions are required to actually protect the exchanged information (O.CIPHER). Remark that even if the TOE shall provide access to the appropriate TSFs, it is still the responsibility of the applets to use them. Keys,’PIN's are particular cases of an applica’ion's sensitive data (the Java Card System may possess keys as well) that ask for appropriate management (O.KEY-MNGT, O.PIN-MNGT, O.BIO-MNGT, O.TRANSACTION). If the PIN/BIO 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/BIO between the applets. Other application data that is sent to the applet as clear text arrives to the APDU buffer, which is a resource shared by all applications. The disclosure of such data is prevented by the security objective O.GLOBAL_ARRAYS_CONFID. Finally, any attempt to read a piece of information that was previously used by an application but has been logically deleted is countered by the O.REALLOCATION objective. That objective states that any information that was formerly stored in a memory block shall be cleared before the block is reused. T.CONFID-JCS-CODE This threat is countered by the list of properties described in the (#.VERIFICATION) security aspect. Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. As none of those instructions enables reading a piece of code, no Java Card applet can therefore be executed to disclose a piece of code. Native applications are also harmless because of the objective O.NATIVE, so no application can be run to disclose a piece of code. The (#.VERIFICATION) security aspect is addressed in this PP 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. ID-ONE COSMO V8.2 Public Security Target 80 | 202 The objectives O.CARD_MANAGEMENT and OE.VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode, respectively. The objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the O.OPERATE and O.ALARM objectives of the TOE, so they are indirectly related to the threats that these latter objectives contribute to counter. 7.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 environment OE.VERIFICATION. The objectives O.CARD_MANAGEMENT and OE.VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode, respectively. The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that integrity and authenticity evidences exist for the application code loaded into the platform. T.INTEG-APPLI-CODE.LOAD This threat is countered by the security objective O.LOAD which ensures that the loading of packages is done securely and thus preserves the integrity of packages code. The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. By controlling the access to card management functions such as the installation, update or deletion of applets the objective O.CARD_MANAGEMENT contributes to cover this threat. T.INTEG-APPLI-DATA This threat is countered by bytecode verification (OE.VERIFICATION) and the isolation commitments stated in the (O.FIREWALL) objective. This latter objective also relies in its turn on the correct identification of applets stated in (O.SID). Moreover, as the firewall is dynamically enforced, it shall never stop operating, as stated in the (O.OPERATE) objective. As the firewall is a software tool automating critical controls, the objective O.ALARM asks for it to provide clear warning and error messages, so that the appropriate counter-measure can be taken. The objectives O.CARD_MANAGEMENT and OE.VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode, respectively. The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. The objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the O.OPERATE and O.ALARM objectives of the TOE, so they are indirectly related to the threats that these latter objectives contribute to counter. Concerning the confidentiality and integrity of application sensitive data, as applets may need to share some data or communicate with the CAD, cryptographic functions are required to actually protect the exchanged information (O.CIPHER). Remark that even if the TOE shall provide access to the appropriate TSFs, it is still the responsibility of the applets to use them. Keys and’PIN's are particular cases of an applica’ion's sensitive data (the Java Card System may ID-ONE COSMO V8.2 Public Security Target 81 | 202 possess keys as well) that ask for appropriate management (O.KEY-MNGT, O.PIN-MNGT, O.BIO-MNGT, O.TRANSACTION). If the PIN/BIO class of the Java Card API is used, the objective (O.FIREWALL) is also concerned. Other application data that is sent to the applet as clear text arrives to the APDU buffer, which is a resource shared by all applications. The integrity of the information stored in that buffer is ensured by the objective O.GLOBAL_ARRAYS_INTEG. Finally, any attempt to read a piece of information that was previously used by an application but has been logically deleted is countered by the O.REALLOCATION objective. That objective states that any information that was formerly stored in a memory block shall be cleared before the block is reused. T.INTEG-APPLI-DATA.LOAD This threat is countered by the security objective O.LOAD which ensures that the loading of packages is done securely and thus preserves the integrity of applications data. The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. By controlling the access to card management functions such as the installation, update or deletion of applets the objective O.CARD_MANAGEMENT contributes to cover this threat. T.INTEG-JCS-CODE This threat is countered by the list of properties described in the (#.VERIFICATION) security aspect. Bytecode verification ensures that each of the instructions used on the Java Card platform is used for its intended purpose and in the intended scope of accessibility. As none of these instructions enables modifying a piece of code, no Java Card applet can therefore be executed to modify a piece of code. Native applications are also harmless because of the objective O.NATIVE, so no application can be run to modify a piece of code. The (#.VERIFICATION) security aspect is addressed in this configuration by the objective for the environment OE.VERIFICATION. The objectives O.CARD_MANAGEMENT and OE.VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode, respectively. The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. T.INTEG-JCS-DATA This threat is countered by bytecode verification (OE.VERIFICATION) and the isolation commitments stated in the (O.FIREWALL) objective. This latter objective also relies in its turn on the correct identification of applets stated in (O.SID). Moreover, as the firewall is dynamically enforced, it shall never stop operating, as stated in the (O.OPERATE) objective. As the firewall is a software tool automating critical controls, the objective O.ALARM asks for it to provide clear warning and error messages, so that the appropriate counter-measure can be taken. The objectives O.CARD_MANAGEMENT and OE.VERIFICATION contribute to cover this threat by controlling the access to card management functions and by checking the bytecode, respectively. The objective OE.CODE-EVIDENCE contributes to cover this threat by ensuring that the application code loaded into the platform has not been changed after code verification, which ensures code integrity and authenticity. The objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the O.OPERATE and O.ALARM objectives of the TOE, so they are indirectly related to the threats that these latter objectives contribute to counter. 7.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 ID-ONE COSMO V8.2 Public Security Target 82 | 202 (O.SID) also participates to face this threat. It should be noticed that the AIDs, which are used for applet identification, are TSF data. In this configuration, usurpation of identity resulting from a malicious installation of an applet on the card is covered by the objective O.INSTALL. The installation parameters of an applet (like its name) are loaded into a global array that is also shared by all the applications. The disclosure of those parameters (which could be used to impersonate the applet) is countered by the objectives O.GLOBAL_ARRAYS_CONFID and O.GLOBAL_ARRAYS_INTEG. The objective O.CARD_MANAGEMENT contributes, by preventing usurpation of identity resulting from a malicious installation of an applet on the card, to counter this threat. T.SID.2 This is covered by integrity of TSF data, subject-identification (O.SID), the firewall (O.FIREWALL) and its good working order (O.OPERATE). The objective O.INSTALL contributes to counter this threat by ensuring that installing an applet has no effect on the state of other applets and thus’can't change the’TOE's attribution of privileged roles. The objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the O.OPERATE objective of the TOE, so they are indirectly related to the threats that this latter objective contributes to counter. 7.3.1.4 UNAUTHORIZED EXECUTION T.EXE-CODE.1 Unauthorized execution of a method is prevented by the objective OE.VERIFICATION. This threat particularly concerns the point (8) of the security aspect #VERIFICATION (access modifiers and scope of accessibility for classes, fields and methods). The O.FIREWALL objective is also concerned, because it prevents the execution of non-shareable methods of a class instance by any subject apart from the class instance owner. T.EXE-CODE.2 Unauthorized execution of a method fragment or arbitrary data is prevented by the objective OE.VERIFICATION. This threat particularly concerns those points of the security aspect related to control flow confinement and the validity of the method references used in the bytecodes. T.NATIVE This threat is countered by O.NATIVE which ensures that a Java Card applet can only access native methods indirectly that is, through an API. OE.APPLET also covers this threat by ensuring that no native applets shall be loaded in post-issuance. In addition to this, the bytecode verifier also prevents the program counter of an applet to jump into a piece of native code by confining the control flow to the currently executed method (OE.VERIFICATION). 7.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 ID-ONE COSMO V8.2 Public Security Target 83 | 202 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 Security Target, though. Finally, the objectives O.SCP.RECOVERY and O.SCP.SUPPORT are intended to support the O.OPERATE and O.RESOURCES objectives of the TOE, so they are indirectly related to the threats that these latter objectives contribute to counter. 7.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. 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. 7.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. 7.3.1.8 MISCELLANEOUS T.PHYSICAL Covered by O.SCP.IC. Physical protections rely on the underlying platform and are therefore an environmental issue. 7.3.1.9 Additional threats T.CONFIGURATION This threat is covered by O.RESIDENT_APPLICATION. This objective ensures that any operation in this phase need authentication, it ensures also that D.CONFIG is loaded protected from theft and modification suchs as an attacker can not observe or modify configuration information exchanged between the TOE and its environment. T.CONF_DATA_APPLET This threat is covered by the O.SECURE_COMPARE security objective. If an attacker tries to catch confidential informat“on "D.A”RAY", the objective O.SECURE_COMPARE ensures that no residual information is available to the attacker. T.PATCH_LOADING This threat is covered by O.PATCH_LOADING security objective. If an attacker tries to avoid the loading of a patch or alter a patch (during loading or once loaded), O.PATCH_LOADING ensures trustable identification and authentication (static signature) data of the loaded patch are returned by the TOE. This information enables to check the presence of the genuine patch. Moreover, O.PATCH_LOADING, ensures authentication of the entity loading the patch, as well as of the developer of the patch are successful before the patch is loaded in the TOE. This objective ensures patch loading can ID-ONE COSMO V8.2 Public Security Target 84 | 202 only be performed during a limited moment in the TOE life cycle (before phase 6) and once the TOE has reached phase 6, this feature is not available anymore. 7.3.2 Organisational 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. 7.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 verification. 7.3.4 SPD and Security Objectives Threats Security Objectives Rationale T.CONFID-APPLI-DATA OE.VERIFICATION, O.SID, O.OPERATE, O.FIREWALL, O.GLOBAL_ARRAYS_CONFID, O.ALARM, O.TRANSACTION, O.CIPHER, O.PIN- MNGT, O.BIO-MNGT, O.KEY-MNGT, O.REALLOCATION, O.SCP.RECOVERY, O.SCP.SUPPORT, O.CARD_MANAGEMENT Section 6.3.1 T.CONFID-JCS-CODE OE.VERIFICATION, O.NATIVE, O.CARD_MANAGEMENT Section 6.3.1 T.CONFID-JCS-DATA OE.VERIFICATION, O.SID, O.OPERATE, O.FIREWALL, O.ALARM, O.SCP.RECOVERY, O.SCP.SUPPORT, O.CARD_MANAGEMENT Section 6.3.1 T.INTEG-APPLI-CODE OE.VERIFICATION, O.NATIVE, OE.CODE- EVIDENCE, O.CARD_MANAGEMENT Section 6.3.1 T.INTEG-APPLI- CODE.LOAD O.LOAD, OE.CODE-EVIDENCE, O.CARD_MANAGEMENT Section 6.3.1 ID-ONE COSMO V8.2 Public Security Target 85 | 202 Threats Security Objectives Rationale T.INTEG-APPLI-DATA OE.VERIFICATION, O.SID, O.OPERATE, O.FIREWALL, O.GLOBAL_ARRAYS_INTEG, O.ALARM, O.TRANSACTION, O.CIPHER, O.PIN- MNGT, O.BIO-MNGT, O.KEY-MNGT, O.REALLOCATION, O.SCP.RECOVERY, O.SCP.SUPPORT, OE.CODE-EVIDENCE, O.CARD_MANAGEMENT Section 6.3.1 T.INTEG-APPLI- DATA.LOAD O.LOAD, OE.CODE-EVIDENCE, O.CARD_MANAGEMENT Section 6.3.1 T.INTEG-JCS-CODE OE.VERIFICATION, O.NATIVE, OE.CODE- EVIDENCE, O.CARD_MANAGEMENT Section 6.3.1 T.INTEG-JCS-DATA OE.VERIFICATION, O.SID, O.OPERATE, O.FIREWALL, O.ALARM, O.SCP.RECOVERY, O.SCP.SUPPORT, OE.CODE-EVIDENCE, O.CARD_MANAGEMENT Section 6.3.1 T.SID.1 O.FIREWALL, O.GLOBAL_ARRAYS_CONFID, O.GLOBAL_ARRAYS_INTEG, O.INSTALL, O.SID, O.CARD_MANAGEMENT Section 6.3.1 T.SID.2 O.SID, O.OPERATE, O.FIREWALL, O.INSTALL, O.SCP.RECOVERY, O.SCP.SUPPORT 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.SCP.RECOVERY, O.SCP.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.OBJ-DELETION O.OBJ-DELETION Section 6.3.1 T.PHYSICAL O.SCP.IC Section 6.3.1 T.CONFIGURATION O.RESIDENT_APPLICATION Section 6.3.1 T.CONF_DATA_APPLET O.SECURE_COMPARE Section 6.3.1 T.PATCH_LOADING O.PATCH_LOADING Section 6.3.1 Table 17: Threats and Security Objectives – Coverage ID-ONE COSMO V8.2 Public Security Target 86 | 202 Security Objectives Threats Rationale O.SID T.CONFID-APPLI-DATA, T.CONFID-JCS- DATA, T.INTEG-APPLI-DATA, T.INTEG-JCS- DATA, T.SID.1, T.SID.2 O.FIREWALL T.CONFID-APPLI-DATA, T.CONFID-JCS- DATA, T.INTEG-APPLI-DATA, T.INTEG-JCS- DATA, T.SID.1, T.SID.2, T.EXE-CODE.1 O.GLOBAL_ARRAYS_CONFID T.CONFID-APPLI-DATA, T.SID.1 O.GLOBAL_ARRAYS_INTEG T.INTEG-APPLI-DATA, T.SID.1 O.NATIVE T.CONFID-JCS-CODE, T.INTEG-APPLI-CODE, T.INTEG-JCS-CODE, T.NATIVE O.OPERATE T.CONFID-APPLI-DATA, T.CONFID-JCS- DATA, T.INTEG-APPLI-DATA, T.INTEG-JCS- DATA, T.SID.2, T.RESOURCES O.REALLOCATION T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA O.RESOURCES T.RESOURCES O.ALARM T.CONFID-APPLI-DATA, T.CONFID-JCS- DATA, T.INTEG-APPLI-DATA, T.INTEG-JCS- DATA O.CIPHER T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA O.KEY-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA O.PIN-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA O.BIO-MNGT T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA O.TRANSACTION T.CONFID-APPLI-DATA, T.INTEG-APPLI- DATA O.OBJ-DELETION T.OBJ-DELETION O.DELETION T.DELETION O.LOAD T.INTEG-APPLI-CODE.LOAD, T.INTEG-APPLI- DATA.LOAD, T.INSTALL O.INSTALL T.SID.1, T.SID.2, T.RESOURCES, T.INSTALL O.SCP.SUPPORT T.CONFID-APPLI-DATA, T.CONFID-JCS- DATA, T.INTEG-APPLI-DATA, T.INTEG-JCS- DATA, T.SID.2, T.RESOURCES O.SCP.IC T.PHYSICAL O.PATCH_LOADING T.PATCH_LOADING ID-ONE COSMO V8.2 Public Security Target 87 | 202 Security Objectives Threats Rationale O.SCP.RECOVERY T.CONFID-APPLI-DATA, T.CONFID-JCS- DATA, T.INTEG-APPLI-DATA, T.INTEG-JCS- DATA, T.SID.2, T.RESOURCES O.RESIDENT_APPLICATION T.CONFIGURATION 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 O.SECURE_COMPARE T.CONF_DATA_APPLET OE.APPLET T.NATIVE OE.VERIFICATION T.CONFID-APPLI-DATA, T.CONFID-JCS- CODE, T.CONFID-JCS-DATA, T.INTEG-APPLI- CODE, T.INTEG-APPLI-DATA, T.INTEG-JCS- CODE, T.INTEG-JCS-DATA, T.EXE-CODE.1, T.EXE-CODE.2, T.NATIVE 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 Table 18: Security Objectives and Threats – Coverage Organisational Security Policies Security Objectives Rationale OSP.VERIFICATION OE.VERIFICATION, OE.CODE-EVIDENCE Section 6.3.2 Table 19: OSPs and Security Objectives – Coverage Security Objectives Organisational Security Policies Rationale O.SID O.FIREWALL O.GLOBAL_ARRAYS_CONFID O.GLOBAL_ARRAYS_INTEG O.NATIVE O.OPERATE O.REALLOCATION ID-ONE COSMO V8.2 Public Security Target 88 | 202 Security Objectives Organisational Security Policies Rationale O.RESOURCES O.ALARM O.CIPHER O.KEY-MNGT O.PIN-MNGT O.BIO-MNGT O.TRANSACTION O.OBJ-DELETION O.DELETION O.LOAD O.INSTALL O.SCP.SUPPORT O.SCP.IC O.SCP.RECOVERY O.RESIDENT_APPLICATION O.CARD_MANAGEMENT O.SECURE_COMPARE OE.APPLET OE.VERIFICATION OSP.VERIFICATION OE.CODE-EVIDENCE OSP.VERIFICATION Table 20: Security Objectives and OSPs – Coverage Assumptions Security Objectives for the Operational Environment Rationale A.APPLET OE.APPLET Section 6.3.3 A.VERIFICATION OE.VERIFICATION, OE.CODE-EVIDENCE Section 6.3.3 Table 21: Assumptions and Security Objectives for the Operational Environment – Coverage Security Objectives for the Operational Environment Assumptions Rationale OE.APPLET A.APPLET OE.VERIFICATION A.VERIFICATION OE.CODE-EVIDENCE A.VERIFICATION Table 22: Security Objectives for the Operational Environment and Assumptions – Coverage ID-ONE COSMO V8.2 Public Security Target 89 | 202 8 Extended Requirements 8.1 Extended Families 8.1.1 Extended Family FCS_–NG - FCS_RNG: Random Number Generation 8.1.1.1 Description This family defines quality requirements for the generation of random numbers which are intended to be used for cryptographic purposes. Extended Component FCS_RNG.1 Description A physical random number generator (RNG) produces the random 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 principles of physical and deterministic RNGs. Family behaviour: This family defines quality requirements for the generation of random numbers which are intended to be use for cryptographic purposes. Component levelling: Generation of random numbers requires that random numbers meet a defined quality metric. Management: There are no management activities foreseen Audit: There are no actions defined to be auditable Hierarchical to: No other components Definition FCS_RNG.1 Random Number Generation FCS_RNG.1.1 The TSF shall provide a [selection: physical, non-physical true, deterministic hybrid] random number generator that implements: [assignment: list of security capabilities]. FCS_RNG.1.2 The TSF shall provide random numbers that meet [assignment: a defined quality metric]. Dependencies: No dependencies. ID-ONE COSMO V8.2 Public Security Target 90 | 202 9 Security Requirements 9.1 Security Functional Requirements This section states the security functional requirements for the Java Card Sys–em - Open configuration. For readability and for compatibility with the original Java Card System Protection Profile Collect–on - Standard 2.2 Configuration [R44], requirements are arranged into groups. All the groups defined in the table below apply to this Security Target. Group Description Core with Logical Channels (CoreG_LC) The CoreG_LC contains the requirements concerning the runtime environment of the Java Card System implementing logical channels. This includes the firewall policy and the requirements related to the Java Card API. Logical channels are a Java Card specification version 2.2 feature. This group is the union of requirements from the Core (CoreG) and the Logical channels (LCG) groups defined in [R44] (cf. Java Card System Protection Profile Collection [R44]). Installation (InstG) The InstG contains the security requirements concerning the installation of post-issuance applications. It does not address card management issues in the broad sense, but only those security aspects of the installation procedure that are related to applet execution. Applet deletion (ADELG) The ADELG contains the security requirements for erasing installed applets from the card, a feature introduced in Java Card specification version 2.2. Object deletion (ODELG) The ODELG contains the security requirements for the object deletion capability. This provides a safe memory recovering mechanism. This is a Java Card specification version 2.2 feature. Secure carrier (CarG) The CarG group contains minimal requirements for secure downloading of applications on the card. This group contains the security requirements for preventing, in those configurations that do not support on-card static or dynamic bytecode verification, the installation of a package that has not been bytecode verified, or that has been modified after bytecode verification. Subjects are active components of the TOE that (essentially) act on the behalf of users. The users of the TOE include people or institutions (like the applet developer, the card issuer, the verification authority), hardware (like the CAD where the card is inserted or the PCD) and software components (like the application packages installed on the card). Some of the users may just be aliases for other users. For instance, the verification authority in charge of the bytecode verification of the applications may be just an alias for the card issuer. Objects (prefixed with“a” "O") are described in the following table: Object Description O.APPLET Any installed applet, its code and data ID-ONE COSMO V8.2 Public Security Target 91 | 202 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 O.REMOTE_MTHD A method of a remote interface O.REMOTE_OBJ A remote object is an instance of a class that implements one (or more) remote interfaces. A remote interface is one that extends, directly or indirectly, the interface java.rmi.Remote ([R6]) O.ROR A remote object reference. It provides information concerning: (i) the identification of a remote object and (ii) the Implementation class of the object or the interfaces implemented by the class of the object. This is the ob’ect's information to which the CAD can access Information (prefixed with“a” "I") is described in the following table: Information Description I.APDU Any APDU sent to or from the card through the communication channel. I.DATA JCVM Reference Data: objectref addresses of APDU buffer, JCRE-owned instances of APDU class and byte array for install method. I.RORD Remote object reference descriptors which provide information concerning: (i) the identification of the remote object and (ii) the implementation class of the object or the interfaces implemented by the class of the object. The descriptor is the only ob’ect's information to which the CAD can access. Security attributes linked to these subjects, objects and information are described in the following table with their values: Security attribute Description/Value Active Applets The set of the active app’ets' AIDs. An active applet is an applet that is selected on at least one of the logical channels. Applet Selection Sta“us "Sele”ted"“or "Desele”ted". Ap’let's version number The version number of an applet (package) indicated in the export file. Class Identifies the implementation class of the remote object. Context Package AID“or "Java Car” RE". COD Context attribute Delimits the space occupied in volatile memory by the data of the CLEAR_ON_DESELECT transient arrays of a package COR Context attribute Delimits the space occupied in volatile memory by the data of the CLEAR_ON_RESET transient arrays of a package ID-ONE COSMO V8.2 Public Security Target 92 | 202 Security attribute Description/Value Current Frame Context The lower and upper Boundary of the local variables area on the stack frame for a method and the lower and upper Boundary of the operand stack area on the stack frame for a method Currently Active Context Package AID“or "Java Car” RE". Dependent package AID Allows the retrieval of the Package AID and Ap’let's version number ([R8], §4.5.2). ExportedInfo Boolean (indicates whether the remote object is exportable or not). Identifier The Identifier of a remote object or method is a number that uniquely identifies the remote object or method, respectively. LC Selection Status Multiselectable, Non-multiselectable“or "”one". LifeTime CLEAR_ON_DESELECT or PERSISTENT (*) or CLEAR_ON_RESET Object Boundary Delimits the space occupied by an object in the heap Owner The Owner of an object is either the applet instance that created the object or the package (library) where it has been defined (these latter objects can only be arrays that initialize static fields of the package). The owner of a remote object is the applet instance that created the object. Package AID The AID of each package indicated in the export file. Package Boundary Delimits the space occupied by the code and the static fields of a package Program Counter Position of the next Bytecode to execute Registered Applets The set of AID of the applet instances registered on the card. Remote An object is Remote if it is an instance of a class that directly or indirectly implements the interface java.rmi.Remote. Resident Packages The set of AIDs of the packages already loaded on the card. Returned References The set of remote object references that have been sent to the CAD during the applet selection session. This attribute is implementation dependent. Selected Applet Context Package AID“or "”one". Sharing Standards, SIO, Java Card RE entry point or global array. Stack Pointer Position of the next free slot in the stack Static Fields Static fields of a package Static References Static fields of a package may contain references to objects. The Static References attribute records those references. ID-ONE COSMO V8.2 Public Security Target 93 | 202 (*) Transient objects of type CLEAR_ON_DESELECT behave like persistent objects in that they can be accessed only when the Currently Active Context is the ob’ect's context. Operations (prefixed w“th”"OP") are described in the following table. Each operation has parameters given between brackets, among which there is “he "accessed ob”ect", the first one, when applicable. Parameters may be seen as security attributes that are under the control of the subject performing the operation. Operation Description OP.ARRAY_ACCESS (O.JAVAOBJECT, field) Read/Write an array component. OP.CREATE (Sharing, LifeTime) (*) Creation of an object (new or makeTransient call). OP.DELETE_APPLET (O.APPI,...) Delete an installed applet and its objects, either logically or physically. OP.DELETE_PCKG ( O.COIPKG,...) Delete a package, either logically or physically. OP.DELETE_PCKG_APPLET (OIDE_PKG,...) Delete a package and its installed applets, either logically or physically. OP.FLOW (O.CODE_PKG) Any operation that modify the execution flow OP.IMPORT_KEY Import of the keys OP.INSTANCE_FIELD (O.JAVAOBJECT, field) Read/Write a field of an instance of a class in the Java programming language. OP.INVK_INTERFACE (O.JAVAOBJECT, Ihod, arg1,...) Invoke an interface method. OP.INVK_VIRTUAL (O.JAVAOBJECImethod, arg1,...) Invoke a virtual method (either on a class instance or an array Iect). OP.JAVA (...) Any access in the sense of [R7], §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. OIOCAL_STACK_ACCESS (...) Any operation that read or write the local stack IOPERAND_STACK_ACCESS (...) Any operation that push or pop items on the operand stack OP.PUT (S1,S2,I) Transfer a piece of information I from S1 to S2. OP.RET_RORD (S.JCRE,S.CAD,I.RORD) Send a remote object reference descriptor to the CAD. OP.STATIC_FIELD (O.CODE_PKG, field) Read/Write a static field of a class in the JAVA programming language OP.THROW (O.JAVAOBJECT) Throwing of an object (athrow, see [R7], §6.2.8.7). ID-ONE COSMO V8.2 Public Security Target 94 | 202 Operation Description OP.TYPE_ACCESS (O.JAVAOBJECT, class) Invoke checkcast or instanceof on an object in order to access to classes (standard or shareable interfaces objects). Cardholder Authentication Authentication of the cardholder U.Card_Issuer authentication Authentication of U.Card_Issuer (*) For this operation, there is no accessed object. This rule enforces that shareable transient objects are not allowed, except some objects, such as COR. For more information refer to the Java Doc [R6]. For instance, during the creation of an object,’the JavaCardClass attribute's value is chosen by the creator. 9.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. 9.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: o OP.CREATE, o OP.INVK_INTERFACE, o OP.INVK_VIRTUAL, o OP.JAVA, o OP.THROW, o OP.TYPE_ACCESS. FDP_ACC.2.2/FIREWALL The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. Application Note: It should be ’oticed that accessing array's components of a static array, and more generally fields and methods of static objects, is an access to the corre“ponding O.JAVAOBJE”T. FDP_ACF.1/FIREWALL Security attribute based access control ID-ONE COSMO V8.2 Public Security Target 95 | 202 FDP_ACF.1.1/FIREWALL The TSF shall enforce the FIREWALL access control SFP to objects based on the following: Subject/Object Security attributes S.PACKAGE LC Selection Status S.JCVM Active Applets, Currently Active Context S.JCRE Selected Applet Context O.JAVAOBJECT Sharing, Context, LifeTime . FDP_ACF.1.2/FIREWALL The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: o R.JAVA.1 ([R7], §6.2.8): S.PACKAGE may freely perform OP.ARRAY_ACCESS, OP.INSTANCE_FIELD, OP.INVK_VIRTUAL, OP.INVK_INTERFACE, OP.THROW or OP.TYPE_ACCESS upon any O.JAVAOBJECT whose “haring attribute”has “alue "JCRE e”try point" or "global array". o R.JAVA.2 ([R7], §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 “haring a”tribute has value "Standard" and whose L“fetime att”ibute has value "PERS’STENT" only if O.JAVAOBJECT's Context attribute has the same value as the active context. o R.JAVA.3 ([R7], §6.2.8.10): S.PACKAGE may perform OP.TYPE_ACCESS upon an O.JAVAOBJECT whose “har”ng attribute has value "SIO" only if O.JAVAOBJECT is being cast into (checkcast) or is being verified as being an instance of (instanceof) an interface that extends the Shareable interface. o R.JAVA.4 ([R7], §6.2.8.6): S.PACKAGE may perform OP.INVK_INTERFACE upon an O.JAVAOBJECT whose Shar“ng ”ttribute has the value "SIO", and whose Cont“xt attribut” 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 “f the packa”e wh“se AID is "Pack”ge AID" is "Multiselectable",  b) The value of the attribute Selection Status “f the packa”e wh“se AID is "Package ”ID" is "Non-m“ltiselectab”e", and either "Package AID" is the value of the currently s“lected appl”t or otherwise "Package AID" does not occur in the attribute Active Applets. o R.JAVA.5: S.PACKAGE may perform OP.CREATE only if the value “f the Sh”ring parameter is "Standard". FDP_ACF.1.3/FIREWALL The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: o 1) The subject S.JCRE“can freely perform OP.JAVA(") and OP.CREATE, with the exception given in FDP_ACF.1.4/FIREWALL, provided it is the Currently Active Context. ID-ONE COSMO V8.2 Public Security Target 96 | 202 o 2) The only means that the subject S.JCVM shall provide for an application to execute native code is the invocation of a Java Card API method (through OP.INVK_INTERFACE or OP.INVK_VIRTUAL). FDP_ACF.1.4/FIREWALL The TSF shall explicitly deny access of subjects to objects based on the following additional rules: o 1) Any subject with OP.JAVA upon an O.JAVAOBJECT whose L“feTime attribute ”as value "CLEAR_’N_DESELECT" if O.JAVAOBJECT's Context attribute is not the same as the Selected Applet Context. o 2) Any subject attempting to create an object by t“e means of OP.CRE”TE 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 may render some O.JAVAOBJECT inaccessible, and the Java Card RE may be in charge of this aspect. This can be done, for instance, by ensuring that references to objects belonging to a deleted application are considered as a null reference. Such a mechanism is implementation-dependent. In the case of an array type, fields are components of the array ([R42], §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 communication,  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 discussion 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 ([R7], §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). ([R7], Glossary) Selected Applet Context. The Java Card RE keeps track of the currently selected Java Card applet. Upon receiving a SEL’CT 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 Co“text. While the express”on "Selected Applet Context" refers to a specific installed applet, the relevant aspect to the policy is the context (package AID) of the selected “pplet. In this policy, ”he "Selected Applet Context" is the AID of the selected package. ([R7], §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). ID-ONE COSMO V8.2 Public Security Target 97 | 202 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 act“ve context as ”ell 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 and version 3 Classic Edition, 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 being selected simultaneously. These applets are referred to as multiselectable applets. Applets that belong to a same package are either all multiselectable or not ([R8], §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 g“ven time. ([R7”, §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 S.JCVM, 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,“) operations a” 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: o An operation OP.PUT(S1, S.MEMBER, I.DATA) is allowed if and only if the “urrently Act”ve Context is "Java Card RE"; ID-ONE COSMO V8.2 Public Security Target 98 | 202 o other OP.PUT operations are allowed regardless of ’he Currently Active Context's value. FDP_IFF.1.3/JCVM The TSF shall enforce the none. FDP_IFF.1.4/JCVM The TSF shall explicitly authorise an information flow based on the following rules: none. FDP_IFF.1.5/JCVM The TSF shall explicitly deny an information flow based on the following rules: none. Application Note: The storage of temporary Java Card RE-owned objects references is runtime-enforced ([R7], §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 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 operat“on under this sch”me. 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 al“ocated [R42], ”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 should be performed in accordance with the rules given in [R“], §4 and [R8]” §3.4. ID-ONE COSMO V8.2 Public Security Target 99 | 202 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 should be performed in accordance with the rules given in [R“], §4 and [R8], §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 given as examples only. For instance, the last two rules are motivated by the fact that the Java Card API defines only transient arrays factory methods. Future versions may allow the creation of transient objects belonging to arbitrary classes; such evolution will na“urally change”the range of "secure values" for this component.  The Context attribute of an O.JAVAOBJECT must correspond to that o“ an installe” applet or be "Java Card RE".  An O.JAVAOBJECT whose Sharing attribute is a Java Card RE entry point or a g“obal array n”cessarily has "Java Card RE" as the value for its Context security attribute.  An O.JAVAOBJECT whose Sharing attribute value is a g“obal array necessarily ”as "array of primitive type" as a Java’ardClass security attribute's value.  Any O.JAVAOBJECT whose Sha“ing attr”bute value is not "Standard" has a P’RSISTENT-LifeTime attribute's value.  Any O.JAVAOBJECT whose LifeTime attribute value is not PERSISTENT has an array typ’ as JavaCardCl“ss attribute's val”e. FMT_MSA.99nitializationtic attribute initialisation FMT_MSA.3.1/FIREWALL The TSF shall enforce the FIREWALL access control SFP to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/FIREWALL [Editorially Refined] The TSF shall not allow any role to specify alternative initial values to override the default values when an object or information is created. Application Note: ID-ONE COSMO V8.2 Public Security Target 100 | 202 ’MT_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 parameters of the operation; on the contrary, its Context attribute has a default’value, which is its creator's Context attribute and AID respectively ([R7], §6.1.3). There is one default value for the Selected Applet Context that is t’e default applet identifier's Context, and one default value for the Curre“tly Active C”ntext 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_“SA.2.1/FIREWAL”_JCVM. FMT_100nitializationtic attribute initialisation FMT_MSA.3.1/JCVM The TSF shall enforce the JCVM information flow control SFP to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/JCVM [Editorially Refined] The TSF shall not allow any role to specify alternative initial values to override the default values when an object or i“formation”is created. FMT_SMF.1 Specification of Management Functions FMT_SMF.1.1 The TSF shall be capable of performing the following management functions: o modify the Currently Active Context, the Selected Applet Context a“d the Act”ve Applets. FMT_SMR.1 Security roles FMT_SMR.1.1 The TSF shall maintain the roles: o Java Card RE (JCRE), o Java Card VM (JCVM). FMT_SMR.1.2 The TSF shall be able to associate users with roles. 9.1.1.2 Application Programming Interface The following SFRs are related to the Java Card API. ID-ONE COSMO V8.2 Public Security Target 101 | 202 The whole set of cryptographic algorithms is generally not implemented because of limited memory resources and/or limitations due to exportation. Therefore, the following requirements only apply to the implemented subset. It should be noticed that the execution of the additional native code is not within the TSF. Nevertheless, access to API native methods from the Java Card System is controlled by TSF because there is no difference between native and interpreted methods in their interface or invocation mechanism. FCS_CKM.1 Cryptographic key generation FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm see table below and specified cryptographic key sizes see table below that meet the following: see table below: Cryptographic key generation algorithm Cryptographic key size List of standards TDES 112 bits or 168 bits FIPS PUB 46-3 (ANSI X3.92), FIPS PUB 81 ECKeyP from 160 to 521 bits IEEE Std 1363a-2004 [R27] RSA from 1024 to 4096 bits with a step of 256-bits ANSI X9.31 AES from 128 to 256 bits with a step of 64–bits FIPS PUB 197 GP Keys - TDES (ECB) 112 bits GP 2.2.1 GP Keys – AES (ECB) 128, 192, 256 bits GP 2.2.1 GP Keys – AES (ECB) 128 bits Standard SCP03 . Application Note:  The keys can be generated and diversified in accordance with [R6] specification in classes KeyBuilder and KeyPair (at least Session key generation).  This component shall be instantiated according to the version of the Java Card API applying to the security target and the implemented algorithms [R6].  This component shall be instantiated according to the version of the Globlal Platform G“ 2.2 [R12” and [R13]. ID-ONE COSMO V8.2 Public Security Target 102 | 202 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 setKey that meets the following: Java Card API [R6] specification and setEncKey/setMacKey in the class “SOSecureMessaging (Package "co”.oberthurcs.javacard.utilSM"). Application Note:  SetKey meets [R6] specification.  This component shall be instantiated according to the version of the Java Card API applying to the security target and the implemen“ed algori”hms ([R6]). FCS_CKM.3 Cryptographic key access o FCS_CKM.3.1 The TSF shall perform the following types of cryptographic key access in accordance with a specified cryptographic key access method see refinement below that me“ts the following:”Packa“es "javacard.se”urity" an“ "javacard.crypto" o Package "co”.oberthur“s.javacard.utilSM" o ”a“kage "org.Glob”l Platform" o "Java Card“JCRE" specification [JCR”] o "Global Platform Ca“d 2.2" specif”cation [R12] o "Java Card API" specification [R6]. Refinement: Type of cryptographic key access Cryptographic key access methods (or commands) DES The following commands: PUT_KEY, EXTERNAL AUTHENTICATE, INITIALIZE UPDATE. The following SecureChannel key access methods Unwrap, wrap, decryptData, encryptData, resetSecurity. The following ISOSecureMessaging key access methods: reset, setEncKey, setKeyFormat, setMacKey, unwrap_LDS, wrap_LDS, wrapLong, wrapLongFinal, wrapLongInit, wrapSW_LDS, s“tMACForma”. The following "APICrypto" key access methods: Key.clearKey, DES.getKey, DES.setKey, Signature.init, Signature.update, Signature.sign, Signature.verify, Cipher.init, Cipher.update, Cipher.doFinal AES The following commands: PUT_KEY, EXTERNAL AUTHENTICATE, INITIA“IZE UPDATE. The follo”ing "ProviderSecurityDomain" key access methods: decryptVerifyKey, openSecureChannel, unwrap, verifyExternalAuthenticate. The following SecureChannel key access methods Unwrap, wrap, decryptData, encryptData, resetSecurity. ID-ONE COSMO V8.2 Public Security Target 103 | 202 The following ISOSecureMessaging key access methods reset, setEncKey, setKeyFormat, setMacKey, unwrap_LDS, wrap_LDS, wrapLong, wrapLongFinal, wrapLongInit, wrapSW_LDS, s“tMACForma”. The following "APICrypto" key access methods: Key.clearKey, AES.getKey, AES.setKey, Signature.init, Signature.update, Signature.sign, Signature.verify, Cipher.init, Cipher.update, Cipher.doFinal RSA The following commands: PU“_KEY, LOAD. The follo”ing "ProviderSecurityDomain" key access methods: Decry“tVerifyKe”. The following "APICrypto" key access methods: Key.clearKey, RSAPrivateCRTKey.setP, RSAPrivateCRTKey.setQ, RSAPrivateCRTKey.setPQ, RSAPrivateCRTKey.setDP1, RSAPrivateCRTKey.setDQ1, RSAPrivateCRTKey.getP, RSAPrivateCRTKey.getQ, RSAPrivateCRTKey.getPQ, RSAPrivateCRTKey.getDP1, RSAPrivateCRTKey.getDQ1, RSAPrivateKey.setModulus, RSAPrivateKey.setExponent, RSAPrivateKey.getModulus, RSAPrivateKey.getExponent, RSAPublicKey.setModulus, RSAPublicKey.setExponent, RSAPublicKey.getModulus, RSAPublicKey.getExponent, Signature.init, Signature.update, Signature.sign, Signature.verify, Cipher.init, Cipher.update, Cipher.d“Final ECk”yP The following "APICrypto" key access methods: Key.clearKey, ECPrivateKey.setFieldFP, ECPrivateKey.setA, ECPrivateKey.setB, ECPrivateKey.setG, ECPrivateKey.setR, ECPrivateKey.setK, ECPrivateKey.getField, ECPrivateKey.getA, ECPrivateKey.getB, ECPrivateKey.getG, ECPrivateKey.getR, ECPrivateKey.getK, ECPrivateKey.setS, ECPrivateKey.getS, ECPublicKey.setFieldFP, ECPublicKey.setA, ECPublicKey.setB, ECPublicKey.setG, ECPublicKey.setR,ECPublicKey.setK, ECPublicKey.getField, ECPublicKey.getA, ECPublicKey.getB, ECPublicKey.getG, ECPublicKey.getR, ECPublicKey.getK, ECPublicKey.setW, ECPublicKey.getW, Signature.init, Signature.update, Signature.sign, Signature.verify KeyAgreement.init, KeyAgreement.generateSecret Application Note:  The keys can be accessed as specified in [R6] Key class.  This component shall be instantiated according to the version of the Java Card API applicable to the security target and the implemen“ed algori”hms ([R6]). 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 The keys are reset in accordance with [R6] in class Key with the method clearKey(). Any access to a cleared key attempting to use it for ciphering or signing shall throw an exceptio“ that meets t”e following: "Java Card API" specification [R6]. The keys used in class “SOSecureMessaging (Package "co”.oberthurcs.javacard.utilSM") are classes Ke“ that meets t”e following: "Java Card API" spec‘ficat’on [R‘]. The metho’s 'reset' and 'setKeyFormat' call the method key.clearKey() for clearing the value of each key. Application Note: ID-ONE COSMO V8.2 Public Security Target 104 | 202  The keys are reset as specified in [R6] Key class, with the method clearKey(). Any access to a cleared key for ciphering or signing sha“l throw a” exception. FCS_COP.1 Cryptographic operation FCS_COP.1.1 The TSF shall perform see table in accordance with a specified cryptographic algorithm see table and cryptographic key sizes see table that meet the following: see below: Cryptographic operation Cryptographic algorithm Key size List of sta’dards signature, signature's verification, en– ryption and decryption DES - TDES 56, 112 or 168 bits FIPS PUB 46-3, ANSI X3.92, FIPS PUB 81, ISO/IEC 9797(1999), Data integrity mechanism’[R17] signature, signature's verification, encryption and decryption AES from 128 to 256 bits with a step of 64 bits FIPS PUB 197 SP800-38B ’CMAC) signature, signature's verification, encryption and decryption RSA CRT, RSA SFM from 1024 to 4096 bits with a step of 256-bits ANSI X9.31, ISO/IEC 9796- 1, annex A, section A.4 and A.5, and annex C, PKCS#1 signature HMAC 64 bits up to 512 bits Hash functions SHA-1, SHA-224, SHA- 256, SHA-384 and SHA- 512,SHA3-224, SHA3-256, SHA3-384, SHA3-512 NA Secure Hash Standard, FIPS PUB’180-3 signature, signature's verification, encryption and decryption ECDSA 160 to 521 bits ANSI X9.62-1998 Key agreement ECDH 160 to 521 bits BSI TR 03111 v1.11 IEEE P1363 Checksum CRC 16 and 32 bits ISO3309_CRC16 ISO3309_CRC32 Refinement: TDES (IC)/IDEMIA has developed the algorithm using HW DES module/TDES encryption and decryption/Triple Data Encryption (TDES)/56/112/168-bits/E-D-E triple- encryption implementation of the Data Encryption Standard, FIPS PUB 46-3, 25 Oct. 1999 ID-ONE COSMO V8.2 Public Security Target 105 | 202 SHA /IDEMIA has developed the algorithm/Hash function/SHA-1/No cryptographic key/Secure Hash Standard, Federal Information Processing Standar105nitialication 180-3, 2008, october SHA /IDEMIA has developed the algorithm/Hash function/SHA-224/No cryptographic key/Secure Hash Standard, Federal Information Processing Standar105nitialication 180-3, 2008, october SHA /IDEMIA has developed the algorithm/Hash function/SHA-256/No cryptographic key/Secure Hash Standard, Federal Information Processing Standar105nitialication 180-3, 2008, october SHA /IDEMIA has developed the algorithm/Hash function/SHA-384/No cryptographic key/Secure Hash Standard, Federal Information Processing Standar105nitialication 180-3, 2008, october SHA /IDEMIA has developed the algorithm/Hash function/SHA-512/No cryptographic key/Secure Hash Standard, Federal Information Processing Standar105nitialication 180-3, 2008, october SHA /IDEMIA has developed the algorithm/Hash function/SHA3-224/No cryptographic key/Secure Hash Standard, Permutation-Based Hash and Extendable-Output Functions – August 2015 SHA /IDEMIA has developed the algorithm/Hash function/SHA3-256/No cryptographic key/Secure Hash S–andard, NIST FIPS PUB 202” - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions – August 2015 SHA /IDEMIA has developed the algorithm/Hash function/SHA3-384/No cryptographic key/Secure Hash S–andard, NIST FIPS PUB 202” - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions – August 2015 SHA /IDEMIA has developed the algorithm/Hash function/SHA3-512/No cryptographic key/Secure Hash S–andard, NIST FIPS PUB 202” - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions – August 2015 KG /IDEMIA has developed the algorithm using HW PK accelerator/Key Generator//Between 1024 bits to 4096 bits/ RSA without CRT /IDEMIA has developed the algorithm using HW PK accelerator/Data Encryption and Decryption/RSA Without CRT Data /Between 1024 bitst o 4096 bits/PKCS#1 V2.0; 1st October, 1998 RSA with CRT /IDEMIA has developed the algorithm using HW PK accelerator/Data Encryption and Decryption/RSA With CRT Data /Between 1024 bits an d 4096 bits/PKCS#1 V2.0; 1st October, 1998 RNG/IDEMIA has developed the algorithm using HW RNG as seed/Random generator//No cryptographic key/FIPS SP800-90, 2007, March AES/IDEMIA has developed the algorithm/Data encryption / decryption//128/192/256 bits/FIPS PUB 197, 2001, November Application Note:  The TOE shall provide a subset of cryptographic operations defined in [R6] (see javacardx.crypto.Cipher and javacardx.security packages).  This component shall be instantiated according to the version of the Java Card API applicable to the security target and the implemen“ed algorithms (”R6]). ID-ONE COSMO V8.2 Public Security Target 106 | 202 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 de“cribed in [R7]” §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 ap”let. 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 obj’ct 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 (FDP_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: ID-ONE COSMO V8.2 Public Security Target 107 | 202  The javacard.security & javacardx.crypto packages do provide secure interfaces to the cryptographic buffer in a transparent way. See javacard.security.KeyBuilder and “ey interface of [R6”. 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 [R7], §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 concurrent“y active ([R7], §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 [R7], §7.7, within the bounds of the Commit Capacity ([R7], §7.8), and those described in [R6]. 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 conditionally updated, as documented in [R6] (see for instance, PIN-blocking, PIN-checking, update of Transient objects). 9.1.1.3 Ca“d Securit” Management FAU_ARP.1 Security alarms ID-ONE COSMO V8.2 Public Security Target 108 | 202 FAU_ARP.1.1 The TSF shall take one of the following actions: o throw an exception, o lock the card session, o reinitialize the Java Card System and its data upon detection of a potential security“violation. Refinement: The "”otential 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,  violation of the Firewall or JCVM SFPs,  unavailability of res“urces,  ar”ay overflow FDP_SDI.2 Stored data integrity monitoring and action FDP_SDI.2.1 The TSF shall monitor user data stored in containers controlled by the TSF for integrity errors on all objects, based on the following attributes: integrityControlledData. FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall increase counter of the Killcard file. If the maximum is reached the killcard is launched. Application Note: The following data persistently stored by TOE h“ve the user data attribu“e "integrityControlledData ":  PINs (i.e. objects instance of class OwnerPin or subclass of interface PIN)  Keys (i.e. objects instance of classes implemented the interface Key)  SecureStores (i.e. objects instance of class SecureStore)  Packages Java Card  “atches  BI”METRIC_DATA FPR_UNO.1 Unobservability ID-ONE COSMO V8.2 Public Security Target 109 | 202 FPR_UNO.1.1 The TSF shall ensure that any user is unable to observe the operation Cardholder authentication on D.PIN and D.BIO by no user and no subject. Application Note: Although it is not required in [R7] specifications, the non-observability of operations on sensitive information such as keys appears as impossible to circumvent in the smart card world. The precise list of operations and objects is left unspecified, but should at least concern secret keys and PIN codes when they exists on the card, as well as the cryptographic operations and comparis“ns perfor”ed on them. 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 ([R7], §6.2.3) or after a proximity card (PICC) activation sequence ([R7]). Behaviour of the TOE on power loss and reset is described in [R7], §3.6 and §7.1. Behaviour of the TOE on RF signal loss is desc“ibed in [”7], §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 o the rules defined in [R8] specification, o the API tokens defined in the export files of reference implementation, 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 assumed that the TOE is developed consistently with the SCP functions, including memory management, I/O functions and cryptographic fun“tions. 9.1.1.4 AID Ma”agement FIA_ATD.1/AID User attribute definition ID-ONE COSMO V8.2 Public Security Target 110 | 202 FIA_ATD.1.1/AID The TSF shall maintain the following list of security attributes belonging to individua’ users: o Package AID, o Applet's version number, o Registered applet AID, o Applet Selection Statu“ ([R8], §6.5). R”finement: "Individual use“s" stand for ”pplets. 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 securit“ fun”tion rather than to a "user" of the CC terminology“ The Jav” Card RE does not "identify" itself to the TOE,“but it is par” 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: for each loaded package is associated an unique Package AID. 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: none. Application Note: The user is the applet and the subject is the S.PACKAGE. The“subject”security attribute "Context" shall hold “he user sec”rity at“ribute "packag” AID". FMT_MTD.1/JCRE Management of TSF data ID-ONE COSMO V8.2 Public Security Target 111 | 202 FMT_MTD.1.1/JCRE The TSF shall restrict the ability to modify th’ list of registered applets' AIDs to the JCRE. Application Note:  The installer and the Java Card RE manage other TSF data such as the applet life cycle or CAP files, but this management is implementation specific. Objects in the Java programming language may also try to query AIDs of installed apIts through the lookupAID(...) API method.  The installer, applet deletion manager or even the card manager may be granted the right to modify’the list of registered applets' AIDs in specific implementations (possibly needed for installation and deletion; see #“DELETION and #”INSTALL). FMT_MTD.3/JCRE Secure TSF data FMT_MTD.3.1/JCRE The TSF shall ensure that only secure values are acce’ted for the registered applets' AIDs. 9.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 Boundary of the firewall, and therefore requires specific treatment. In this PP, loading a p111nitialior installing an applet modeled as importation of user ’ata (that is, user application's data) with its security attributes (such as the parameters of the applet use“ in the firewall ru”es). 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 ([R8], §4.5.2).. ID-ONE COSMO V8.2 Public Security Target 112 | 202 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 [R8] specifications; it cont’ins the user 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 ([R8], §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 ([R8], §4.5.2): the dependent packages Versions and AIDs attributes allow the retrieval of these identifications. Implementation-dependent checks may occur on a case-by-case basis to indicate that package files are binary compatible. “owever, package files d” have "package Version Numbers" ([R8]) 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.  The intent of this rule is to ensure the binary compatibility of the package with those already on the card ([R8], §4.4).  The installati’n (the invocation of an applet's install method by the installer) is implementation dependent ([R7], §11.2).  Other rules governing the installation of an applet, that is, its registration to make it SELECTable by giving it a unique AID, are also implementation dependent (see,“for example, [R7], ”11). FMT_SMR.1/Installer Security roles FMT_SMR.1.1/Installer The TSF shall maintain the roles: S.INSTALLER. FMT_SMR.1.2/Installer The TSF shall be able to as“ociate users with r”les. ID-ONE COSMO V8.2 Public Security Target 113 | 202 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 [R7] §11.1.4. Application Note: The TOE may provide additional feedback information to the card manager in case of potential security vi“lations (see FAU_AR”.1). FPT_RCV.3/Installer Automated recovery without undue loss FPT_RCV.3.1/Installer When automated recovery from An applet (i.e. a package) is considered as loaded, once its reference is written in the list of the loaded packages (i.e. instantiated applets). This is the ultimate stage of the applet/package installation, done when everything has succeeded before (verification, initialization, object instantiation). If an error occurs before registration, everything must be rolled back. For package installation, the garbage collector will automatically remove the package code since we stopped installation before the package recording. For applet installation, we mainly relies on garbage collector, as it is done for package, to remove the applet instance and AID objects (since the applet is not on the root of persistence, these objects are unreachable). On applet installation, its install method is called which can lead to change the states of the VM objects. To rollback the modifications eventually made in field of other persistent objects, the installation is surrounded by a transaction (that is aborted). Finally, we have additional mechanisms to rollback modifications eventually done in the field of transient arrays since they are not covered but the transaction (volatile data is not in the scope of Java Card transaction) 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 installation of the applet, the TSF shall ensure the return of the TOE to a secure state using automated procedures. FPT_RCV.3.3/Installer The functions provided by the TSF to recover from failure or service discontinuity shall ensure that the secure initial state is restored without exceeding the loss of the Executable Load File being installed for loss of TSF data or objects under the control of the TSF. FPT_RCV.3.4/Installer The TSF shall provide the capability to determine the objects that were or were not capable of be ing recovered. Applicat ion Note: FPT_RCV.3.1/Installer:  This element is not within the scope of the Java Card specification, which only mandates the behaviour of the Java Card System in good working“order. Further d”tails ID-ONE COSMO V8.2 Public Security Target 114 | 202 on the "maintenance mode" shall be provided in specific implementations. 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 authorised 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 "consistent and secure state". The Java Card RE has some clean up duties as well; see [R7], §11.1.5 for possible scenarios. Precise behaviour is left to implementers. This component shall include among the listed failures the deletion of a package/applet. See ([R7], 11.3.4) for possible scenarios. Precise behaviour is left to implementers.  Other events such as the unexpected tearing of the card, power loss, and so on, are partially handled by the underlying hardware platfor’ (see [R24]) and, “rom the TOE's side, by event” "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:  The quantification is implementation dependent, but some facts can be recalled here. 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 (EEPROM). Data stored on the RAM and subject to such failure is intended to have a limited lifetime anyway (runtime data ’n the stack, transient objects' contents). According to this, the loss of data within the TSF scope should be limited to the same restrictions of the transaction mechanism. 9.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 f“lled by ST imp”ementers. FDP_ACC.2/ADEL Complete access control FDP_ACC.2.1/ADEL The TSF shall enforce the ADEL access control SFP on S.ADEL, S.JCRE, S.JCVM, O.JAVAOBJECT, O.APPLET and O.CODE_PKG and all operations among subjects and objects covered by the SFP. Refinement: The operations involved in the policy are: o OP.DELETE_APPLET, ID-ONE COSMO V8.2 Public Security Target 115 | 202 o OP.DELETE_PCKG, o OP.DELETE_PCKG_APPLET. FDP_ACC.2.2/ADEL The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered “y an access co”trol 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, Remote . FDP_ACF.1.2/ADEL The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: In the context of this policy, an object O is reachable if and only if one of the following conditions hold: o (1) the owner of O is a registered applet instance A (O is reachable from A), o (2) a static field of a resident package P contains a reference to O (O is reachable from P), o (3) there exists a valid remote reference to O (O is remote reachable’, o (4) there exists an object O' that is reachable according to eithe’ (1) or (2) or (3) above and O' contains a reference to O (the reacha’ility status of O is that of O'). The following access control rules determine when an operation among controlled subjects and objects is allowed by the policy: o R.JAVA.14 ([R7], §11.3.4.1, Applet Instance Deletion): S.ADEL may perform OP.DELETE_APPLET upon an O.APPLET only if,  (1) S.ADEL is currently selected,  (2) there is no instance in the context of O.APPLET that is active in any logical channel and  (3) there is no O.JAVAOBJECT owned by O.APPLET such that either O.JAVAOBJECT is reachable from an applet instance distinct from O.APPLET, or O.JAVAOBJECT is reachable from a package P, or ([R7], §8.5) O.JAVAOBJECT is remote reachable. o R.JAVA.15 ([R7], §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, ID-ONE COSMO V8.2 Public Security Target 116 | 202  (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 ([R7], §8.5) O.JAVAOBJECT is remote reachable. o R.JAVA.16 ([R7], §11.3.4.2, Applet/Library Package Deletion): S.ADEL may perform OP.DELETE_PCKG upon an O.CODE_PKG only if,  (1) S.ADEL is currently selected,  (2) no reachable O.JAVAOBJECT, from a package distinct from O.CODE_PKG that is an instance of a class that belongs to O.CODE_PKG, exists on the card and  (3) there is no resident package on the card that depends on O.CODE_PKG. o R.JAVA.17 ([R7], §11.3.4.3, Applet Package and Contained Instances Deletion): S.ADEL may perform OP.DELETE_PCKG_APPLET upon an O.CODE_PKG only if,  (1) S.ADEL is currently selected,  (2) no reachable O.JAVAOBJECT, from a package distinct from O.CODE_PKG, which is an instance of a class that belongs to O.CODE_PKG exists on the card,  (3) there is no package loaded on the card that depends on O.CODE_PKG, and  (4) for every O.APPLET of those being deleted it holds that: (i) there is no instance in the context of O.APPLET that is active in any logical channel and (ii) there is no O.JAVAOBJECT owned by O.APPLET such that either O.JAVAOBJECT is reachable from an applet instance not being deleted, or O.JAVAOBJECT is reachable from a package not being deleted, or ([R7], §8.5) O.JAVAOBJECT is remote reachable. FDP_ACF.1.3/ADEL The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/ADEL [Editorially Refined] The TSF shall explicitly deny access of any subject but S.ADEL to O.CODE_PKG or O.APPLET for the purpose of deleting them from the card. Application Note: FDP_ACF.1.2/ADEL:  This policy introduces the notion of reachability, which provides a general means to describe objects that are referenced from a certain applet instanc“ or packa”e.  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 Securi”y Target. FDP_RIP.1/ADEL Subset residual information protection ID-ONE COSMO V8.2 Public Security Target 117 | 202 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 [R7], §11.3.4.1,“§11.3.4.2 and ”11.3.4.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 Pack“ges to the Jav” Card RE. F117nitializationStatic attribute initialisation FMT_MSA.3.1/ADEL The TSF shall enforce the ADEL access control SFP to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/ADEL The TSF shall allow the following role(s): none, to specify alternative initial values to override the default values when an object o“ information i” 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. Application Note: The modification of the Active Applets security attribute should be performed in accordance with the“rules given in”[R7], §4. 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 as“ociate users w”th roles. ID-ONE COSMO V8.2 Public Security Target 118 | 202 FPT_FLS.1/ADEL Failure with preservation of secure state FPT_FLS.1.1/ADEL The TSF shall preserve a secure state when the following types of failures occur: the applet deletion manager fails to delete a package/applet as described in [R7], §11.3.4. Application Note:  The TOE may provide additional feedback information to the card manager in case of a potential security violation (see FAU_ARP.1).  The Package/applet instanc“ deletion mu”t be atomic. The "secure state" referred to in the requirement must comply with Java Card specification ([R7], §11.3.4.) 9.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 invoki“g a specific A”I method. FDP_RIP.1/ODEL Subset residual information protection FDP_RIP.1.1/ODEL The TSF shall ensure that any previous information content of a resource is made unavailable upon the deallocation of the resource from the following objects: the objects owned by the context of an applet instance which triggered the execution of the method javacard.framework.JCSystem.requestObjectDeletion(). Application Note:  Freed data resources resulting from the invocation of the method javacard.framework.JCSystem.requestObjectDeletion() may be reused. Requirements on de-allocation after the invocation of the method are described in [R6].  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 transa“tion 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: ID-ONE COSMO V8.2 Public Security Target 119 | 202 The TOE may provide additional feedback information to the card manager in case of potential security violation (see FAU_ARP.1). 9.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 aft“r bytecode v”rification. FCO_NRO.2/CM Enforced proof of origin FCO_NRO.2.1/CM The TSF shall enforce the generation of evidence of origin for transmitted application packages at all times. FCO_NRO.2.2/CM [Editorially Refined] The TSF shall be able to relate the identity of the originator of the information, and the application package contained in the information to which the evidence applies. FCO_NRO.2.3/CM The TSF shall provide a capability to verify the evidence of origin of information to recipient given immediate verification. Application Note: FCO_NRO.2.1/CM:  Upon reception of a new application package for installation, the card manager shall first check that it actually comes from the verification authority. The verification authority is the entity responsible for bytecode verification. FCO_NRO.2.3/CM:  The exact limitations on the evidence of origin are implementation dependent. In most of the implementations, the card manager performs an immediate verification of the origin of the package using an electronic signature mechanism, and no evidence is kept on the card “or future ve”ifications. 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: ID-ONE COSMO V8.2 Public Security Target 120 | 202  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 th“ communicati”n 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: LoadFile, Dap. FDP_IFF.1.2/CM The TSF shall permit an information flow between a controlled subject and controlled information via a controlled operation if the following rules hold: the rules describing the communication protocol used by the CAD and the card for transmitting a new package, see chapter 9.3.9 [R9]. FDP_IFF.1.3/CM The TSF shall enforce the none. FDP_IFF.1.4/CM The TSF shall explicitly authorise an information flow based on the following rules: none. FDP_IFF.1.5/CM The TSF shall explicitly deny an information flow based on the following rules: the rules describing the communication protocol used by the CAD and the card for transmitting a new package, see chapter 9.3.9 [R9]. Application Note: FDP_IFF.1.1/CM:  The security attributes used to enforce the PACKAGE LOADING SFP are implementation dependent. More precisely, they depend on the communication 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 Appendix D of [R12]. FDP_IFF.1.2/CM:  The precise set of rules to be enforced by the function is implementation dependent. The whole exchange of messages shall verify at least the following two rules: (1) the subject S.INSTALLER shall accept a message only if it comes from the subject S.CAD; ID-ONE COSMO V8.2 Public Security Target 121 | 202 (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 s“nt by the su”ject S.CAD. FDP_UIT.1/CM Data exchange integrity FDP_UIT.1.1/CM The TSF shall enforce the PACKAGE LOADING information flow control SFP to receive user data in a manner protected from deletion, insertion, replay and modification errors. FDP_UIT.1.2/CM [Editorially Refined] The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion, replay of some of the pieces of the application sent by the CAD has occurred. Application Note: Modification errors should be 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. FIA_UID.1/CM Timing of identification FIA_UID.1.1/CM The TSF shall allow Execution of Card Manager 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 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 th“ component F”T_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 modify the security attributes AS.KEYSET_VERSION, AS.KEYSET_VALUE, Default SELECTED Privileges, AS.C“LIFECYC to C”RD_MANAGER. 121nitializationStatic attribute initialisation ID-ONE COSMO V8.2 Public Security Target 122 | 202 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 Card manager to specify alternative initial values to override the default values when an object o“ 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: Modify the following security attributes: AS.KEYSET_VERSION, AS.KEYSET_VALUE, Default SELECTED “rivileges, A”.CMLIFECYC. FMT_SMR.1/CM Security roles FMT_SMR.1.1/CM The TSF shall maintain the roles Card manager. FMT_SMR.1.2/CM The TSF shall be able to as“ociate 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: New packages can be installed on the card only on demand of the card issuer. 9.1.5.1 Additional Security Funct“onal Requ”rements for CM FPT_TST.1 TSF testing ID-ONE COSMO V8.2 Public Security Target 123 | 202 FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up to demonstrate the correct operation of the TSF. FPT_TST.1.2 The TSF shall provide authorised users with the capability to verify the integrity of TSF data. FPT_TST.1.3 The TSF shall provide authorised users with the capability to verify the integrity of stored TSF executable code. Application Note: Namely, “stored TSF executable code” encompasses the patch. During startup, the TOE checks the integrity of the patch. Other self tests are described in AGD_PRE, chapter 8 [R39]. Namely, According to the protocol used Known Answer Test (or POST for Power On Self Tests) checks SHA, RSA, ECDSA either in startup or during 1st use. Those latter tests are configurable. RNG, CRC, DES and AES set of self tests can be performed in startup, rega“ding the configu”ation. FCO_NRO.2/CM_DAP Enforced proof of origin FCO_NRO.2.1/CM_DAP The TSF shall enforce the generation of evidence of origin for transmitted Loadfile at all times. FCO_NRO.2.2/CM_DAP The TSF shall be able to relate the AS.KEYSET_VALUE of the originator of the information, and the CAP file components of the information to which the evidence applies. FCO_NRO.2.3/CM_DAP The TSF shall provide a capability to verify the evidence of origin of information to recipient given“during CAP f”le loading. Application Note: This feature included in this st allows an Application Provider to require that their Application code to be loaded on the card shall be checked for integrity and authenticity. The DAP Verification Key is identi‘ie’ by the Key Version Numb‘r ’73' and the Key Identifier '01'. See description in §9.2.1 of GlobalPlatform Card Specification for more details [9]. In this implementation, DAPs are generated and verified according the one of the following schemes:  The RSA scheme (Variant 1) specified in appendix C.6.1 of [9] is supported. For this scheme, the DAP Verification Key shall be a 1024-bits RSA public key.  The RSA scheme (Variant 2) specified in § 5.2 of GlobalPlatform specification Amendment D. For this scheme, the DAP Verification Key shall be a 2048-bits RSA public key. The algorithm is RSASSA-PSS as defined in PKCS#1. ID-ONE COSMO V8.2 Public Security Target 124 | 202  The AES scheme specified in appendix C.6.1 of [9] is supported. For this scheme, the DAP Verification Key shall be a 128-bits AES key. FIA_AFL.1/CM Authentication failure handling FIA_AFL.1.1/CM The TSF shall detect when 1 unsuccessful authentication attempts occur related to U.Card_Issuer authentication. FIA_AFL.1.2/CM When the defined number of unsuccessful authentication attempts has been met and surpassed, the TSF shall slow down exponentially“the next aut”entication. FIA_UAU.1/CM Timing of authentication FIA_UAU.1.1/CM The TSF shall allow Get_Data, Initialize_Update, Select on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/CM The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated action“ on behalf of that u”er. FIA_UAU.4/CardIssuer Single-use authentication mechanisms FIA_UAU.4.1/CardIssuer The TSF shall prevent reuse of authentication data related to the Card Issuer “uthentication mechan”sm. FIA_UAU.7/CardIssuer Protected authentication feedback FIA_UAU.7.1/CardIssuer The TSF shall provide only the result of the authentication (NOK), the key set version, Secure channel identifier and the card random and the card cryptogram to the user while the authe“tication is in p”ogress. FPR_UNO.1/Key_CM Unobservability FPR_UNO.1.1/Key_CM The TSF shall ensure that all subjects are unable to observe the operation OP.IMPORT_“EY on Key by”D.JCS_KEYS. FPT_TDC.1/CM Inter-TSF basic TSF data consistency ID-ONE COSMO V8.2 Public Security Target 125 | 202 FPT_TDC.1.1/CM The TSF shall provide the capability to consistently interpret AS.KEYSET_VALUE, Packages when shared between the TSF and another trusted IT product. FPT_TDC.1.2/CM The TSF shall use the PUT KEY data format when interpreting the TSF data from an“ther trusted”IT product. FMT_SMR.2/CM Restrictions on security roles FMT_SMR.2.1/CM The TSF shall maintain the roles: see below. FMT_SMR.2.2/CM The TSF shall be able to associate users with roles. FMT_SMR.2.3/CM The TSF shall ensure that the conditions see details below: Roles Condition for this role R.personaliser Successful authentication (Card Issuer) using a key set of the Card Manager or Security Domain associates with CM life cycle phase from OP_READY to SECURED R.Card_Manager Successful authentication (of Card Issuer) using its key set, with CM life cycle phase from OP_READY to SECURED R.Security_Domain Successful authentication (of application provider) using its key set, with CM life cycle phase different from locked R.Use_API Successful identification (of Applet), with Applet life cycle phase after SELECTABLE R.Applet_privilege have the privilege to modify CM life cycle, ATR, and also Global Pin are satisfied. FCS_COP.1/CM Cryptographic operation FCS_COP.1.1/CM The TSF shall perform see table below in accordance with a specified cryptographic algorithm see table below and cryptographic key sizes see table below that meet the following: Cryptographic operation Algorithm Key length Standard TOE authentication key ISK/KMC SCP02 112 bits GP 2.2.1 TOE authentication key ISK/KMC SCP03 12–/192/256 bits GP 2.2.1 SCP02 - signature, verification of signature, encryption and decryption TDES 11– bits SCP02 – GP 2.2.1 SCP03 - signature, verification of signature, encryption and decryption AES 128/192/25– bits SCP03 – GP 2.2.1 ID-ONE COSMO V8.2 Public Security Target 126 | 202 Cryptographic operation Algorithm Key length Standard SCPF3 - signature, verification of signature, encryption and decryption AES 128 bits Proprietary 9.1.5.2 Additional Security Functional Requirements“for Resident”application FDP_ACC.2/PP Complete access control FDP_ACC.2.1/PP The TSF shall enforce the Access Control on See below and all operations among subjects and objects covered by the SFP Access Control Prepersonalisation Access Control S.Resident application and for all objects Patch & Locks Loading Access Control S.TOE and for all objects .FDP_ACC.2.2/PP The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. Application note: This SFR enforces the access control for the patch and locks loa“ing and the ”SK loading. FDP_ACF.1/PP Security attribute based access control FDP_ACF.1.1/PP The TSF shall enforce the Access Control on See below to objects based on the following: Access Control Prepersonalisation Access Control AS_AUTH_MSK_STATUS Patch & Locks Loading Access Control AS_AUTH_MSK_STATUS FDP_ACF.1.2/PP The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: AS.AUTH_MSK_STATUS=TRUE. FDP_ACF.1.3/PP The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/PP The TSF shall explicitly deny access of subjects to objects based on the followin“ additional ”ules: none. ID-ONE COSMO V8.2 Public Security Target 127 | 202 FDP_UCT.1/PP Basic data exchange confidentiality FDP_UCT.1.1/PP The TSF shall enforce the Prepersonalisation access control and Patch and Locks loading access control to receive user data in a manner protected from unauthorised disclosure. Application note: For the Prepersonalisation access control, the MSK is used to cipher the data transmitted (ISK). For the Patch and Locks loading access control, the LSK is used to cip“er the data ”ransmitted. FDP_ITC.1/PP Import of user data without security attributes FDP_ITC.1.1/PP The TSF shall enforce the Prepersonalisation access control and Patch and Locks loading access control when importing user data, controlled under the SFP, from outside of the TOE. FDP_ITC.1.2/PP The TSF shall ignore any security attributes associated with the user data when imported from outside the TOE. FDP_ITC.1.3/PP The TSF shall enforce the following rules when importing user data controlled under the SFP fr“m outside th” TOE: none. FIA_AFL.1/PP Authentication failure handling FIA_AFL.1.1/PP The TSF shall detect when 3 unsuccessful authentication attempts occur related to U.Card_manufacturer authentication. FIA_AFL.1.2/PP When the defined number of unsuccessful authentication attempts has been met, the TSF shal“ always retu”n an error. FIA_UAU.1/PP Timing of authentication FIA_UAU.1.1/PP The TSF shall allow INITIALIZE AUTHENTICATION PROCESS, GET DATA, MANAGE CHANNEL, SELECT APPLET, MANAGE PDC on behalf of the user to be performed before the user is authenticated. FIA_UAU.1.2/PP The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated action“ on behalf o” that user. FIA_UID.1/PP Timing of identification ID-ONE COSMO V8.2 Public Security Target 128 | 202 FIA_UID.1.1/PP The TSF shall allow INITIALIZE AUTHENTICATION PROCESS, GET DATA, MANAGE CHANNEL, SELECT APPLET, MANAGE PDC on behalf of the user to be performed before the user is identified. FIA_UID.1.2/PP The TSF shall require each user to be successfully identified before allowing any other TSF-mediated action“ on behalf o” that user. FMT_MSA.1/PP Management of security attributes FMT_MSA.1.1/PP The TSF shall enforce the Prepersonalisation access control to restrict the ability to modify the security attributes AS.AUTH_MSK_STA“US to R.Prep”rsonaliser. FMT_SMF.1/PP Specification of Management Functions FMT_SMF.1.1/PP The TSF shall be capable of performing the following management functions: mo“ify security attri”utes. FIA_ATD.1/CardManu User attribute definition FIA_ATD.1.1/CardManu The TSF shall maintain the following list of security attributes belonging to individual u“ers: AS.AUTH_MSK_S”ATUS. FIA_UAU.4/CardManu Single-use authentication mechanisms FIA_UAU.4.1/CardManu The TSF shall prevent reuse of authentication data related to the Card Manufacturer “uthentication mech”nism. FIA_UAU.7/CardManu Protected authentication feedback FIA_UAU.7.1/CardManu The TSF shall provide only the result of the authentication (NOK) and the random to the user while the authe“tication is ”n progress. FMT_MOF.1/PP Ma128nitialiof security functions behaviour FMT_MOF.1.1/PP The TSF shall restrict the ability to see below the functions see below to: Functions Role Disable INITIALIZE AUTHENTICATION PROCESS, EXTERNAL AUTHENTICATE, R.Prepersonaliser ID-ONE COSMO V8.2 Public Security Target 129 | 202 INSTALL, UPDATE SECURE, LOAD APPLET, GET DATA, MANAGE PDC Modify the behaviour of Self tests described in FPT_TST.1 R.Prepersonaliser Modify the behaviour of All functions R.Developer Application note: The first operation ensures the irreversible locking of the patch and locks loading features once in OP_READY, after pre production state. Once in OP_READY state, those APDU cannot be used. The second operation described the product configuration regarding self tests, as described in AGD_PRE, chapter 8 [R39]. The last operation permits the loading of patch and locks during phase 5. FMT_SMR.2/PP Restrictions on security roles FMT_SMR.2.1/PP The TSF shall maintain the roles: R.Prepersonaliser and R.Developer. FMT_SMR.2.2/PP The TSF shall be able to associate users with roles. FMT_SMR.2.3/PP The TSF shall ensure that the conditions see refinement below are satisfied. Refinement: Roles Condition for this role R.Prepersonaliser Successful authentication (of Card Manufacturer) using MSK and card still in prepersonalisation state, in phase 4-5. R.Developer Succesful authentication (of TOE developer“ using LSK i” phase 4-5 129nitializationStatic attribute initialisation FMT_MSA.3.1/PP The TSF shall enforce the Prepersonalisation access control to provide same rights by default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/PP The TSF shall allow the following role(s):none to specify alternative initial values to override the default values when an object o“ information”is created. FCS_COP.1/PP Cryptographic operation ID-ONE COSMO V8.2 Public Security Target 130 | 202 FCS_COP.1.1/PP The TSF shall perform see table below in accordance with a specified cryptographic algorithm see table below and cryptographic key sizes see table below that meet the following: Cryptographic operation Algorithm Key length Standard Decryption (MSK) and signature verification DES 112 bits FIPS-PUB 46-3 (ANSI X3.92), FIPS PUB 81 or ISO/IEC 9797, Data integrity mechanism Card Manufacturer authentication (MSK) DES 112 bits FIPS PUB 197 Card Manufacturer authentication (MSK) AES 128, 192 and 256 bits FIPS-PUB 46-3 (ANSI X3.92), FIPS PUB 81 or ISO/IEC 9797, Data integrity mechanism Decryption (of patch and locks ciphered with LSK) and signature verification TDES 112 bits FIPS-PUB 46-3 (ANSI X3.92), FIPS PUB 81 or ISO/IEC 9797, Data integrity mechanism TOE authentication key ISK/KMC TDE“ 112 bits FI”S PUB 197 FCS_CKM.4/PP Cryptographic key destruction FCS_CKM.4.1/PP The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method Key is set to NULL that meets the following: no. Application Note: In phase 5, reaching OP_READY state, this SFR ensures the secure erasing of the LSK and MSK keys. FDP_UIT.1/PP Data exchange integrity FDP_UIT.1.1/PP The TSF shall enforce the Patch and locks and Prepersonalisation loading access control SFP to receive user data in a manner protected from modification errors. FDP_UIT.1.2/PP [Editorially Refined] The TSF shall be able to determine on receipt of user data, whether modification of some of the pieces of the application sent by the TOE developer and Card Manufacturer has occurred. Application Note: Modification errors should be understood as modification, substitution, unrecoverable ordering change of data and any other integrity error that may cause the patch or the locks to be installed on the card to be different from the one sent by the TOE Developer. The Patch and locks ID-ONE COSMO V8.2 Public Security Target 131 | 202 loading is performed by the TOE Developer via the command UPDATE SECURE, its integrity is ensured by a MAC, described in FCS_COP.1/PP. The ISK loading is performed by the Card Manufacturer via the command PUT KEY, its integrity is ensured by a MAC, described in FCS_COP.1/PP. FCS_CKM.1/PP Cryptographic key generation FCS_CKM.1.1/PP The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm see table below and specified cryptographic key sizes see table below that meet the following: see table below: Cryptographic key generation algorithm Cryptographic key size List of standards TOE’s MSK derived from the MSK loaded in phase 1, using SHA-256 16, 24 and 32 bytes None Application Note: Key derivation algorithm is detailed in AGD_PRE, §5 [R39]. In phases 3-4, MSK is diversified during the first command, and then replaced by the new value generated by FCS_CKM.1/PP. FTP_ITC.1/PP Inter-TSF trusted channel FTP_ITC.1.1/PP 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/PP [Editorially Refined] The TSF shall permit the TOE Developer and Card Manufacturer to initiate communication via the trusted channel. FTP_ITC.1.3/PP The TSF shall initiate communication via the trusted channel for loading the patch code, locks and ISK on the card. FAU_STG.2 Guarantees of audit data availability FAU_STG.2.1 The TSF shall protect the stored audit records in the audit trail from unauthorized deletion. FAU_STG.2.2 The TSF shall be able to prevent unauthorized modifications to the stored audit records in the audit trail. FAU_STG.2.3 The TSF shall ensure that Patch code identification stored audit records will be maintained when the following conditions occur: audit storage exhaustion, failure and attack. Application Note: ID-ONE COSMO V8.2 Public Security Target 132 | 202 Patch code is loaded with its information and its CRC. Information on the Patch code is directly retrieved from itself (identication and static signature) and is provided by GET DATA command. This information is protected from modification because the interfaces that enable its modification are deactivated once in OP_READY state. More information is available in [R38]. 9.1.5.3 Additional Security Functional Requiremen“s for SmartCa”d Platform FPT_PHP.3/SCP Resistance to physical attack FPT_PHP.3.1/SCP The TSF shall resist physical manipulation and physical probing to the all TOE components implementing the TSF by responding automatically such that the SFRs are always enforced. Application Note: The physical manipulation and physical probing include: changing operational conditions every times: the frequency of the external clock, powe“ supply, and ”emperature FPT_FLS.1/SCP Failure with preservation of secure state FPT_FLS.1.1/SCP The TSF shall preserve a secure state when the following types of fail“res occur: cf”FAU_ARP.1. FPT_RCV.3/SCP Automated recovery without undue loss FPT_RCV.3.1/SCP When automated recovery from none 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 all cases, 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 the loss of the Executable Load File being installed for loss of TSF data or objects under the control of the TSF. FPT_RCV.3.4/SCP The TSF shall provide the capability to determine the objects that were or were not ca“able of being”recovered. FPT_RCV.4/SCP Function recovery FPT_RCV.4.1/SCP The TSF shall ensure that reading from an’ writing to static and objects' fields interrupted by power loss have the property that the function either ID-ONE COSMO V8.2 Public Security Target 133 | 202 completes successfully, or for the indicated failure scenarios, recovers to a con“istent and se”ure state. FRU_FLT.1/SCP Degraded fault tolerance FRU_FLT.1.1/SCP The TSF shall ensure the operation of Fault tolerance when the following failures occur: Lack of EEPROM. Application Note: The TOE implements a mechanism to detect a problem of EEPROM. During the life of the TOE, the Transaction area reduces its size to skip damaged EEPROM bytes. During the writing or erasing operations, up to 3 maximum attempts to get successful programming are done. Otherwise the EXCEPTIO“_EEPROM_ERROR is ”aised. FPR_UNO.1/USE_KEY Unobservability FPR_UNO.1.1/USE_KEY The TSF shall ensure that all subjects are unable to observe the operation “se on key by ”.JCS_KEYS. FCS_RNG.1/SCP Random Number Generation FCS_RNG.1.1/SCP The TSF shall provide a deterministic hybrid random number generator that implements: none. FCS_RNG.1.2/SCP The TSF shall provide random numbers that meet NIST SP 800-90 [R30]. 9.1.5.4 Additional Security Functional Req“irements for ”he applets FIA_AFL.1/PIN Authentication failure handling FIA_AFL.1.1/PIN The TSF shall detect when an administrator configurable positive integer within from 1 to 127 for OwnerPIN unsuccessful authentication attempts occur related to any user authentication using a PIN. FIA_AFL.1.2/PIN When the defined number of unsuccessful authentication attempts has been met, the“TSF shall block ”he PIN. FMT_MTD.2/GP_PIN Management of limits on TSF data ID-ONE COSMO V8.2 Public Security Target 134 | 202 FMT_MTD.2.1/GP_PIN The TSF shall restrict the specification of the limits for D.NB_REMAINTRYGLB, GlobalPIN to R.Card_Manager. FMT_MTD.2.2/GP_PIN The TSF shall take the following actions, if the TSF data are at, or exceed, the indicated limits: block D.PIN. R.Card_Manager Entity after Successful authentication (of Card Issuer) using its key set, with CM life cycle phase “rom OP_READY to ”ECURED FPR_UNO.1/Applet Unobservability FPR_UNO.1.1/Applet The TSF shall ensure that anybody is unable to observe the operation Comparison on two “ytes arrays b” S.APPLET. FMT_MTD.1/PIN Management of TSF data FMT_MTD.1.1/PIN The TSF shall restrict the ability to change_default, query and modify the O“nerPIN to applet”itself. FIA_AFL.1/GP_PIN Authentication failure handling FIA_AFL.1.1/GP_PIN The TSF shall detect when an administrator configurable positive integer within 3 to 15 unsuccessful authentication attempts occur related to any user authentication using a Global PIN. FIA_AFL.1.2/GP_PIN When the defined number of unsuccessful authentication attempts has been met, the TSF shall block the Global PIN. 9.1.5.5 Additional Security Functi“nal Requirements ”or BIO FIA_AFL.1/PIN_BIO Authentication failure handling FIA_AFL.1.1/PIN_BIO The TSF shall detect when an administrator configurable positive integer within user defined maximum from 1 to 254 for D.BIO unsuccessful authentication attempts occur related to any user authentication using MOC. FIA_AFL.1.2/PIN_BIO When the defined number of unsuccessful authentication attempts has been met, the“TSF shall block t”e MOC. FMT_MTD.1/PIN_BIO Management of TSF data ID-ONE COSMO V8.2 Public Security Target 135 | 202 FMT_MTD.1.1/PIN_BIO The TSF shall restrict the ability to change_default, query and modify the D.BIO to applet itself. 9.1.5.6 Additional Security Functional Requirements for Runtime V“rification Stack C”ntrol FDP_ACC.2/RV_Stack Complete access control FDP_ACC.2.1/RV_Stack The TSF shall enforce the Stack Access Control SFP on S.STACK and all operations among subjects and objects covered by the SFP. Refinement: The operations involved in the policy are: o OP.OPERAND_STACK_ACCESS o OP.LOCAL_STACK_ACCESS FDP_ACC.2.2/RV_Stack The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered “y an access contro” SFP. FDP_ACF.1/RV_Stack Security attribute based access control FDP_ACF.1.1/RV_Stack The TSF shall enforce the Stack Access Control to objects based on the following: Subject/Object Security attributes S.APPLET Active Applets, Applet Selection Status S.STACK Stack Pointer S.JCVM Current Frame Context FDP_ACF.1.2/RV_Stack The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: o An Active Applet selected may freely perform OP.LOCAL_STACK_ACCESS upon stack pointer only if the index of the local variable accessed matches the Current Frame Context attribute o An Active Applet selected may freely perform OP.OPERAND_STACK_ACCESS upon Stack Pointer only if the attribute Stack Pointer matches the attribute Current Frame Context of S.JCVM. ID-ONE COSMO V8.2 Public Security Target 136 | 202 FDP_ACF.1.3/RV_Stack The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/RV_Stack The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none. Application Note: Any bytecode accessing a local variable has an index in parameter (byte or short). The first rule aims at verifying that this index is always positive and inferior to the numbers of local variables defined for this stack frame. Then the local variable slot is accessed using the index that is relative to the base of local variables for this stack frame. Any bytecode accessing the operand stack for push or pop operations is under the control of rule 2. The second rule aims at verifying that the stack pointer is always in the range defined by the base-of-stack and top-of-stack values defined for this stack frame. The frame context attribute is made of the following elements:  number-of-local variables and base-of-local-variable  base-of-stack and top-of-stack The policies defined in this SFR are enforced dynamically, each time an operation is performed. Nevertheless, those verifications may be redundant with the ones made statically by the off-card verifier, during the a“plet verification ”tage. FMT_MSA.1/RV_Stack Management of security attributes FMT_MSA.1.1/RV_Stack The TSF shall enforce the Stack Access Control SFP to restrict the ability to modify the security attributes Current Frame Context and Stack Pointer to t“e Java Card VM (S.”CVM). FMT_MSA.2/RV_Stack Secure security attributes FMT_MSA.2.1/RV_Stack The TSF shall ensure that only secure values are accepted for Current Frame C“ntext and Stack Po”nter. FMT_MSA.3/RV_Stack attribute initialisation ID-ONE COSMO V8.2 Public Security Target 137 | 202 FMT_MSA.3.1/RV_Stack The TSF shall enforce the Stack Access Control SFP to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/RV_Stack The TSF shall allow the any role to specify alternative initial values to override the default values when an object o“ information is cr”ated. FMT_SMF.1/RV_Stack Specification of Management Functions FMT_SMF.1.1/RV_Stack The TSF shall be capable of performing the following management functions: Modify the Current Frame Context and modify the Stack Pointer. Application Note: The frame context attribute is modified on method invocation. In that case, the previous context attribute is saved on the stack. It will be restored on return of the in“oked method. Heap”Access FDP_ACC.2/RV_Heap Complete access control FDP_ACC.2.1/RV_Heap The TSF shall enforce the Heap Access Control SFP on O.CODE_PKG, O.JAVAOBJECT, S.JCVM, S.APPLET and all operations among subjects and objects covered by the SFP. Refinement: The operations involved in the policy are: o OP.ARRAY_ACCESS o OP.INSTANCE_FIELD o OP.STATIC_FIELD o OP.FLOW FDP_ACC.2.2/RV_Heap The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered “y an access contr”l SFP. FDP_ACF.1/RV_Heap Security attribute based access control FDP_ACF.1.1/RV_Heap The TSF shall enforce the Heap Access Control SFP to objects based on the following: Subject/Object Security attributes O.CODE_PKG Package Boundary O.JAVAOBJECT Object Boundary S.JCVM Program Counter ID-ONE COSMO V8.2 Public Security Target 138 | 202 S.APPLET Active Applets, Applet Selection Status . FDP_ACF.1.2/RV_Heap The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: o S.APPLET may freely perform OP.ARRAY_ACCESS and OP.INSTANCE_FIELD upon any O.JAVAOBJECT if the array cell index or the instance field index match the object boundary attribute of O.JAVAOBJECT o S.APPLET may freely perform OP.STATIC_FIELD upon any O.CODE_PKG if the static field index matches the Package Boundary attribute of O.CODE_PKG. o S.APPLET may freely perform OP.FLOW upon O.CODE_PKG if the Program Counter attribute of S.JCVM matches the Package Boundary attribute of O.CODE_PKG. FDP_ACF.1.3/RV_Heap The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/RV_Heap The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none. Application Note: The upper and lower boundaries of any object allocated on the heap are registered (Object Boundary Attribute). Each time an object is accessed, the first rule verifies that the accessed NVM location is comprised between those two boundaries. The second rule aims at verifying that when a static field is accessed, the index of this field is positive and inferior to the number of static fields of this package (part of Package Boundary attribute). The third rule aims at verifying that when a change of execution flow occurs, the computed value for the newly computed value for the Program Counter is comprised within the boundaries defined for this package (part of Package Boundary Attribute). This rule does not concern invocation bytecode. The policies defined in this SFR are enforced dynamically, each time an operation is performed. Nevertheless, those verifications may be redundant with the ones made statically by the off-card verifier, during the a“plet verification”stage. FMT_MSA.1/RV_Heap Management of security attributes FMT_MSA.1.1/RV_Heap The TSF shall enforce the Heap Access Control SFP to restrict the ability to modify the security attributes Package Boundary, Object Boundary and P“ogram Counter to ”.JCVM. ID-ONE COSMO V8.2 Public Security Target 139 | 202 FMT_MSA.2/RV_Heap Secure security attributes FMT_MSA.2.1/RV_Heap The TSF shall ensure that only secure values are accepted for Package Boundary, Object Boun“ary and Program C”unter. FMT_139nitializationStatic attribute initialisation FMT_MSA.3.1/RV_Heap The TSF shall enforce the Heap Access Control SFP to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/RV_Heap The TSF shall allow the no role to specify alternative initial values to override the default values when an object o“ information is c”eated. FMT_SMF.1/RV_Heap Specification of Management Functions FMT_SMF.1.1/RV_Heap The TSF shall be capable of performing the following management functions: to modify the Program Counter att“ibute. Transient Contr”l FDP_ACC.2/RV_Transient Complete access control FDP_ACC.2.1/RV_Transient The TSF shall enforce the Transient Access Control SFP on S.APPLET, S.JCVM and O.JAVAOBJECT and all operations among subjects and objects covered by the SFP. Refinement: The operation involved in the policy is: o OP.ARRAY_ACCESS FDP_ACC.2.2/RV_Transient The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered “y an access control SF”. FDP_ACF.1/RV_Transient Security attribute based access control FDP_ACF.1.1/RV_Transient The TSF shall enforce the Transient Access Control SFP to objects based on the following: Subject/Object Security Attributes S.APPLET Active Applets, Applet Selection Status S.JCVM COR Context, COD Context O.JAVAOBJECT LifeTime ID-ONE COSMO V8.2 Public Security Target 140 | 202 . FDP_ACF.1.2/RV_Transient The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: o S.APPLET may freely perform OP.ARRAY_ACCESS on O.JAVAOBJECT whos“ LifeTime attr”bute has value "CLEAR_ON_RESET" only if the targeted volatile memory space matches the COR Context attribute of S.JCVM o S.APPLET may freely perform OP.ARRAY_ACCESS on O.JAVAOBJECT whos“ LifeTime attribu”e has value "CLEAR_ON_DESELECT" only if the targeted volatile memory space matches the COD Context attribute of S.JCVM. FDP_ACF.1.3/RV_Transient The TSF shall explicitly authorise access of subjects to objects based on the following additional rules: none. FDP_ACF.1.4/RV_Transient The TSF shall explicitly deny access of subjects to objects based on the following additional rules: none. Application Note: Each time an applet accesses a Clear On Reset (resp. Clear On Deselect) transient, these rules verify that the accessed RAM area is in the range of the Clear On Reset transients space (resp. Clear On Deselect) allocated for all the transients created by the applets of this package. The COR context attribute represents the lower and upper limits for the Clear On Reset transient space of the active applet package. The COD context attribute represents the lower and upper limits for the Clear On Deselect transient space of the currently selected applet package. The policies defined in this SFR are enforced dynamically, each time an operation is performed. Nevertheless, those verifications may be redundant with the ones made statically by the off-card verifier, during the a“plet verification stag”. FMT_MSA.1/RV_Transient Management of security attributes FMT_MSA.1.1/RV_Transient The TSF shall enforce the Transient Access Control SFP to restrict the ability to modify the security attributes the security attributes COR Context and COD Context “o Java Card VM (S.JCVM”. FMT_MSA.2/RV_Transient Secure security attributes FMT_MSA.2.1/RV_Transient The TSF shall ensure that only secure values are accepted for COR Context and COD Context Security attributes of the Tran“ient Access Control SF”. ID-ONE COSMO V8.2 Public Security Target 141 | 202 FMT_MSA.3141nitializationStatic attribute initialisation FMT_MSA.3.1/RV_Transient The TSF shall enforce the Transient Access Control SFP to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2/RV_Transient The TSF shall allow the no role to specify alternative initial values to override the default values when an object o“ information is create”. FMT_SMF.1/RV_Transient Specification of Management Functions FMT_SMF.1.1/RV_Transient The TSF shall be capable of performing the following management functions: modify the COR Context and COD Context Security Attributes. 9.2 Security Assurance Requirements The Evaluation Assurance Level is EAL5 augmented with AVA_VAN.5 and ALC_DVS.2. 9.3 Security Requirements Rationale 9.3.1 Objectives 9.3.1.1 Security Objectives for the TO’ IDENTIFICATION O.SID Subjects' identity is AID-based (applets, packages), and is met by the following SFRs: FDP_ITC.2/Installer, FIA_ATD.1/AID, FMT_MSA.1/JCRE, FMT_MSA.1/JCVM, FMT_MSA.1/ADEL, FMT_MSA.1/CM, FMT_MSA.3/ADEL, FMT_MSA.3/FIREWALL, FMT_MSA.3/JCVM, FMT_MSA.3/CM, FMT_SMF.1/CM, FMT_SMF.1/ADEL, FMT_MTD.1/JCRE and FMT_MTD.3/JCRE. Lastly, installation procedures ensure protection against forgery (the AID of an applet is under the control of the TSFs) or re-use of identities (FIA_UID.2/AID, FIA_USB.1/AID). EXECUTION O.FIREWALL This objective is met by the FIREWALL access control policy FDP_ACC.2/FIREWALL and FDP_ACF.1/FIREWALL, the JCVM information flow control policy (FDP_IFF.1/JCVM, FDP_IFC.1/JCVM), the functional requirement FDP_ITC.2/Installer. The functional requirements of the class FMT (FMT_MTD.1/JCRE, FMT_MTD.3/JCRE, FMT_SMR.1/Installer, FMT_SMR.1, FMT_SMF.1, FMT_SMR.1/ADEL, FMT_SMF.1/ADEL, FMT_SMF.1/CM, FMT_MSA.1/CM, FMT_MSA.3/CM, FMT_SMR.1/CM, FMT_MSA.2/FIREWALL_JCVM, FMT_MSA.3/FIREWALL, FMT_MSA.3/JCVM, FMT_MSA.1/ADEL, FMT_MSA.3/ADEL, S, FMT_MSA.1/JCRE, FMT_MSA.1/JCVM,) also indirectly contribute to meet this objective. This objective is also covered by the following additional SFRs: - Stack control (*/RV_Stack): FDP_ACC.2/RV_Stack, FDP_ACF.1/RV_Stack, FMT_MSA.1/RV_Stack, FMT_MSA.2/RV_Stack, FMT_MSA.3/RV_Stack, ID-ONE COSMO V8.2 Public Security Target 142 | 202 FMT_SMF.1/RV_Stack - Heap control (*/RV_Heap): FDP_ACC.2/RV_Heap, FDP_ACF.1/RV_Heap, FMT_MSA.1/RV_Heap, FMT_MSA.2/RV_Heap, FMT_MSA.3/RV_Heap, FMT_SMF.1/RV_Heap - Transient control (*/RV_Transient): FDP_ACC.2/RV_Transient, FDP_ACF.1/RV_Transient, FMT_MSA.1/RV_Transient, FMT_MSA.2/RV_Transient, FMT_MSA.3/RV_Transient, FMT_SMF.1/RV_Transient For each of those control, the SFR define the access control (FDP_ACC and FDP_ACF), the operation (FMT_MSA) and the role (FMT_SMF). The Stack control enforces O.FIREWALL by defining additional rules, such as the control of the stack is more precise. Information is provided in the application note. The Heap control enforces O.FIREWALL by defining additional rules, such as the heap usage is improved. Information is provided in the application note. The Transient enforces O.FIREWALL by defining additional rules, such as the heap usage is improved. Information is provided in the application note. 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 ’arameter (bArray) to an applet's install method. The clearing requirement of these arrays is met by (FDP_RIP.1/APDU and FDP_RIP.1/bArray respectively). The JCVM information flow control policy (FDP_IFF.1/JCVM, FDP_IFC.1/JCVM) prevents an application from keeping a pointer to a shared buffer, which could be used to read its contents when the buffer is being used by another application. Protection of the array parameters of remotely invoked methods, which are global as well, is covered by the general initialization of method parameters (FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_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, FDP_IFC.1/JCVM), which prevents an application from keeping a pointer to the APDU buffer of the card or to the ’lobal 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 ’n various ways against applets' actions (FPT_TDC.1), the FIREWALL access control policy FDP_ACC.2/FIREWALL and FDP_ACF.1/FIREWALL, and is able to detect and block various failures or security violations during usual working (FPT_FLS.1/ADEL, FPT_FLS.1, FPT_FLS.1/ODEL, FPT_FLS.1/Installer, FAU_ARP.1). Its security-critical parts and procedures are also protected: safe recovery from failure is ensured’(FPT_RCV.3/Installer), applets' installation may be cleanly aborted (FDP_ROL.1/FIREWALL), communication with external users and their internal subjects is ID-ONE COSMO V8.2 Public Security Target 143 | 202 well-controlled (FDP_ITC.2/Installer, FIA_ATD.1/AID, FIA_USB.1/AID) to prevent alteration of TSF data (also protected by components of the FPT class). Almost every objective and/or functional requirement indirectly contributes to this one too. Application note: Startup of the TOE (TSF-testing) can be covered by FPT_TST.1. This SFR component is not mandatory in [R7], but appears in most of security requirements documents for masked applications. Testing could also occur randomly. Self-tests may become mandatory in order to comply to FIPS certification [FIPS 140-2]. O.REALLOCATION This security objective is satisfied by the following SFRs: FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FDP_RIP.1/TRANSIENT, FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/ADEL, which imposes that the contents of the re-allocated block shall always be cleared before delivering the block. O.RESOURCES The TSFs detects stack/memory overflows during execution of applications (FAU_ARP.1, FPT_FLS.1/ADEL, FPT_FLS.1, FPT_FLS.1/ODEL, FPT_FLS.1/Installer). Failed installations are not to create memory leaks (FDP_ROL.1/FIREWALL, FPT_RCV.3/Installer) as well. Memory management is controlled by the TSF (FMT_MTD.1/JCRE, FMT_MTD.3/JCRE, FMT_SMR.1/Installer, FMT_SMR.1, FMT_SMF.1 FMT_SMR.1/ADEL, FMT_SMF.1/ADEL, FMT_SMF.1/CM and FMT_SMR.1/CM). SERVICES O.ALARM This security objective is met by FPT_FLS.1/Installer, FPT_FLS.1, FPT_FLS.1/ADEL, FPT_FLS.1/ODEL which guarantee that a secure state is preserved by the TSF when failures occur, and FAU_ARP.1 which defines TSF reaction upon detection of a potential security violation. O.CIPHER This security objective is directly covered by FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FCS_COP.1 and FCS_COP.1/PP. FPR_UNO.1 and FPR_UNO.1/USE_KEY contributes in covering this security objective and controls the observation of the cryptographic operations which may be used to disclose the keys. O.KEY-MNGT This relies on the same security functional requirements as O.CIPHER, plus FDP_RIP.1 and FDP_SDI.2 as well. Precisely it is met by the following components: FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FCS_COP.1, FCS_COP.1/PP, FPR_UNO.1, FPR_UNO.1/USE_KEY, FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL and FDP_RIP.1/TRANSIENT. O.PIN-MNGT This security objective is ensured by FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT, FPR_UNO.1, FDP_ROL.1/FIREWALL and FDP_SDI.2 security functional requirements. The TSFs behind these are implemented by API classes. The firewall security functions FDP_ACC.2/FIREWALL and FDP_ACF.1/FIREWALL shall protect the access to private and internal data of the objects. FIA_AFL1.1/CM, FIA_AFL.1/PIN, FIA_AFL.1/GP_PIN and FIA_AFL.1/CM ensure the ID-ONE COSMO V8.2 Public Security Target 144 | 202 objective regarding authentications failures. FMT_MTD.1/PIN ensures the objective regarding the management of the TSF data. O.BIO-MNGT This security objective is ensured by FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT, FPR_UNO.1, FDP_ROL.1/FIREWALL and FDP_SDI.2 security functional requirements. The TSFs behind these are implemented by API classes. The firewall security functions FDP_ACC.2/FIREWALL and FDP_ACF.1/FIREWALL shall protect the access to private and internal data of the objects. FIA_AFL.1/CM and FIA_AFL.1/PIN_BIO ensure the objective regarding authentications failures. FMT_MTD.1/PIN_BIO ensures the objective regarding the management of the TSF data. . O.TRANSACTION Directly met by FDP_ROL.1/FIREWALL, FDP_RIP.1/ABORT, FDP_RIP.1/ODEL, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT and FDP_RIP.1/OBJECTS (more precisely, by the element FDP_RIP.1.1/ABORT). OBJECT DELETION O.OBJ-DELETION This security objective specifies that deletion of objects is secure. The security objective is met by the security functional requirements FDP_RIP.1/ODEL and FPT_FLS.1/ODEL. APPLET MANAGEMENT O.DELETION This security objective specifies that applet and package deletion must be secure. The non-introduction of security holes is ensured by the ADEL access control policy (FDP_ACC.2/ADEL, FDP_ACF.1/ADEL). The integrity and confidentiality of data that does not belong to the deleted applet or package is a by-product of this policy as well. Non- accessibility of deleted data is met by FDP_RIP.1/ADEL and the TSFs are protected against possible failures of the deletion procedures (FPT_FLS.1/ADEL, FPT_RCV.3/Installer). The security functional requirements of the class FMT (FMT_MSA.1/ADEL, FMT_MSA.3/ADEL, FMT_SMR.1/ADEL) included in the group ADELG also contribute to meet this objective. O.LOAD This security objective specifies that the loading of a package into the card must be secure. Evidence of the origin of the package is enforced (FCO_NRO.2/CM) and the integrity of the corresponding data is under the control of the PACKAGE LOADING information flow policy (FDP_IFC.2/CM, FDP_IFF.1/CM) and FDP_UIT.1/CM. Appropriate identification (FIA_UID.1/CM) and transmission mechanisms are also enforced (FTP_ITC.1/CM). O.INSTALL This security objective specifies that installation of applets must be secure. Security attributes of installed data are under the control of the FIREWALL access control ID-ONE COSMO V8.2 Public Security Target 145 | 202 policy (FDP_ITC.2/Installer), and the TSFs are protected against possible failures of the installer (FPT_FLS.1/Installer, FPT_RCV.3/Installer). Additional security objectives for the TOE O.SCP.SUPPORT The components FPT_RCV.3/SCP and FPT_RCV.4/SCP (SCP stands for smart card platform) are used to support the objective O.SCP.SUPPORT to assist the TOE to recover in the event of a power failure. 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. O.SCP.IC This objective is met by the component FPT_PHP.3/SCP and FCS_RNG.1/SCP. O.SCP.RECOVERY The component FPT_RCV.3/SCP is used to support the objective O.SCP.RECOVERY to assist the TOE to recover in the event of a power failure. 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. This objective is met by the components FPT_FLS.1, FPT_FLS.1/SCP, FPT_RCV.3/SCP, FPT_RCV.4/SCP FAU_ARP.1 and FRU_FLT.1/SCP. O.RESIDENT_APPLICATION This objective is covered by the following set of SFR: o Access control: FDP_ACC.2/PP, FDP_ACF.1/PP, FDP_UCT.1/PP and FDP_ITC.1/PP o Rules for authentication: FIA_AFL.1/PP, FIA_UAU.1/PP, FIA_UAU.1/CM, and FIA_UID.1/PP o Security Management: FMT_MSA.1/PP, FMT_SMF.1/PP, FMT_MOF.1/PP, FMT_SMR.2/PP, FMT_MSA.3/PP and FMT_SMR.2/CM o Cryptographic Key Destruction: FCS_CKM.4/PP O.CARD_MANAGEMENT This objective is fulfilled by the following set of SFR: o Access control: FDP_IFF.1/CM and FDP_IFC.2/CM o Rules for authentication: FIA_UID.1/CM, FIA_UAU.7/CardIssuer, FIA_UAU.4/CardIssuer, FIA_ATD.1/CardManu, FIA_UAU.4/CardManu, FIA_UAU.7/CardManu o Security Management: FMT_MSA.1/CM, FMT_MSA.3/CM, FMT_SMR.2/PP, FMT_SMF.1/PP, FMT_SMR.2/CM, FMT_SMF.1/CM and FMT_SMR.1/CM o Non repudiation: FCO_NRO.2/CM and FCO_NRO.2/CM_DAP o Trusted Path Channels: FTP_ITC.1/CM o Protection of the TSF: FPT_TDC.1/CM o Non observability: FPR_UNO.1/Key_CM O.SECURE_COMPARE This objective is fulfilled by FPR_UNO.1/Applet. It ensures that comparison is confidential. O.PATCH_LOADING Authentication of the entity loading the patch by the TOE ID-ONE COSMO V8.2 Public Security Target 146 | 202 FDP_ACC.2/PP, FDP_ACF.1/PP, FIA_UAU.1/PP and FIA_UID.1/PP provide access control for patch loading. The subject entitled to load the–patch – the card manufacturer - is authenticated by the TOE thanks to FCS_COP.1/PP. Wrong authentication of the Card manufacturer agent are detected thanks to FIA_AFL.1/PP Authentication of the TOE To avoid impersonation of the TOE by a fake chip, the TOE authenticates itself ; from phase 6 (after patch loading) with FTP_ITC.1/CM and FCS_COP.1/CM thanks to the TOE authentication key (ISK/KMC). From phase 6, the TOE authentication is required prior to any trusted channel establishment with FTP_ITC.1/CM (data sent by the TOE must be decrypted to carry on the authentication). The TOE authentication key (ISK/KMC) is securely loaded in phase 4/5 protected in confidentiality with FDP_UCT.1/PP and integrity with FDP_UIT.1/PP through the trusted channel established by the Card Manufacturer with FDP_ITC.1/PP. The trusted channel and the TOE authentication key (ISK/KMC) encryption is supported by FCS_COP.1/PP that relies on the TOE’s MSK which is the first key present in the TOE. Diversification of keys The TOE’s MSK used to authenticate the Card manufacturer is derived from the MSK thanks to FCS_CKM.1/PP before the first use. The MSK is loaded in the TOE in phase 1 (covered by [ALC]). Integrity, confidentiality and authenticity of the patch during loading During patch loading, FTP_ITC.1/PP provides a trusted channel between the TOE developer and the TOE, used to load the patch in a confidential manner with FDP_UCT.1/PP and protected in integrity and confidentiality with FDP_UIT.1/PP. Confidentiality, integrity and authenticity of the patch loading is supported by cryptographic mechanisms supported by FCS_COP.1/PP . The patch is loaded together with its static signature. This static signature is protected in the same manner as the patch itself; It is used in further step enable the TOE to check that the patch is still integer. Irreversible locking of the patch loading features The patch can be loaded in phase 4 and 5 of the TOE’s life cycle. At the end of phase 5, FMT_MOF.1/PP ensures this feature is not available anymore Erasure of the key used FCS_CKM.4/PP ensures the secure destruction of the keys involved in the patch loading mechanism (LSK and MSK) at the end of phase 5. Identification of the patch after loading ID-ONE COSMO V8.2 Public Security Target 147 | 202 Once loaded and during the rest of the TOE life cycle, the identification and authentication (static signature of the code) of the patch, being a part of the TOE is provided by FAU_STG.2. When requested, the identification and authentication data are dynamically retrieved from the patch code stored in the non volatile memory of the TOE. Integrity check before usage of the patch At start up, the integrity of the patch is checked by the TOE through self tests provided by FPT_TST.1. The static signature of the patch stored in the non volatile memory of the TOE is computed and compared with the one affixed to it. In case they differ, an integrity error is detected, and a killcard is raised. ID-ONE COSMO V8.2 Public Security Target 148 | 202 9.3.2 Rationale tables of Security Objectives and SFRs Security Objectives Security Functional Requirements Rationale O.SID FIA_ATD.1/AID, FIA_UID.2/AID, FMT_MSA.1/JCRE, , FMT_MSA.1/ADEL, FMT_MSA.3/ADEL, FMT_MSA.3/FIREWALL, FMT_MSA.1/CM, FMT_MSA.3/CM, FDP_ITC.2/Installer, FMT_SMF.1/CM, FMT_SMF.1/ADEL, , FMT_MTD.1/JCRE, FMT_MTD.3/JCRE, FIA_USB.1/AID, FMT_MSA.1/JCVM, FMT_MSA.3/JCVM Section 4.3.1 O.FIREWALL FDP_IFC.1/JCVM, FDP_IFF.1/JCVM, FMT_SMR.1/Installer, FMT_MSA.1/CM, FMT_MSA.3/CM, FMT_SMR.1/CM, FMT_MSA.3/FIREWALL, FMT_SMR.1, FMT_MSA.1/ADEL, FMT_MSA.3/ADEL, FMT_SMR.1/ADEL, FMT_MSA.1/JCRE, FDP_ITC.2/Installer, FDP_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL, FMT_SMF.1/ADEL, , FMT_SMF.1/CM, FMT_SMF.1, FMT_MSA.2/FIREWALL_JCVM, FMT_MTD.1/JCRE, FMT_MTD.3/JCRE, FMT_MSA.1/JCVM, FMT_MSA.3/JCVM, FDP_ACC.2/RV_Stack, FDP_ACF.1/RV_Stack, FMT_MSA.1/RV_Stack, FMT_MSA.2/RV_Stack, FMT_MSA.3/RV_Stack, FMT_SMF.1/RV_Stack, FDP_ACC.2/RV_Heap, FDP_ACF.1/RV_Heap, FMT_MSA.1/RV_Heap, FMT_MSA.2/RV_Heap, FMT_MSA.3/RV_Heap, FMT_SMF.1/RV_Heap, FDP_ACC.2/RV_Transient, FDP_ACF.1/RV_Transient, FMT_MSA.1/RV_Transient, FMT_MSA.2/RV_Transient, FMT_MSA.3/RV_Transient, FMT_SMF.1/RV_Transient Section 4.3.1 O.GLOBAL_ARRAYS_CONFID FDP_IFC.1/JCVM, FDP_IFF.1/JCVM, FDP_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, FDP_RIP.1/TRANSIENT Section 4.3.1 O.GLOBAL_ARRAYS_INTEG FDP_IFC.1/JCVM, FDP_IFF.1/JCVM Section 4.3.1 O.NATIVE FDP_ACF.1/FIREWALL Section 4.3.1 O.OPERATE FAU_ARP.1, FDP_ROL.1/FIREWALL, FIA_ATD.1/AID, FPT_FLS.1/ADEL, FPT_FLS.1, FPT_FLS.1/ODEL, FPT_FLS.1/Installer, FDP_ITC.2/Installer, FPT_RCV.3/Installer, FDP_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL, FPT_TDC.1, FIA_USB.1/AID, FPT_TST.1 Section 4.3.1 O.REALLOCATION FDP_RIP.1/ABORT, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/KEYS, FDP_RIP.1/TRANSIENT, FDP_RIP.1/ADEL, FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS Section 4.3.1 ID-ONE COSMO V8.2 Public Security Target 149 | 202 Security Objectives Security Functional Requirements Rationale O.RESOURCES FAU_ARP.1, FDP_ROL.1/FIREWALL, FMT_SMR.1/Installer, FMT_SMR.1, FMT_SMR.1/ADEL, , FPT_FLS.1/Installer, FPT_FLS.1/ODEL, FPT_FLS.1, FPT_FLS.1/ADEL, FPT_RCV.3/Installer, FMT_SMR.1/CM, FMT_SMF.1/ADEL, , FMT_SMF.1/CM, FMT_SMF.1, FMT_MTD.1/JCRE, FMT_MTD.3/JCRE Section 4.3.1 O.ALARM FPT_FLS.1/Installer, FPT_FLS.1, FPT_FLS.1/ADEL, FPT_FLS.1/ODEL, FAU_ARP.1 Section 4.3.1 O.CIPHER FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FCS_COP.1, FPR_UNO.1, FPR_UNO.1/USE_KEY, FCS_COP.1/PP Section 4.3.1 O.KEY-MNGT FCS_CKM.1, FCS_CKM.2, FCS_CKM.3, FCS_CKM.4, FCS_COP.1, FPR_UNO.1, FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FDP_SDI.2, FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT, FPR_UNO.1/USE_KEY, FCS_COP.1/PP Section 4.3.1 O.PIN-MNGT FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FPR_UNO.1, FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT, FDP_ROL.1/FIREWALL, FDP_SDI.2, FDP_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL, FIA_AFL.1/CM, FIA_AFL.1/PIN, FMT_MTD.2/GP_PIN, FMT_MTD.1/PIN, FIA_AFL.1/GP_PIN Section 4.3.1 O.BIO-MNGT FDP_RIP.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/ABORT, FDP_RIP.1/KEYS, FPR_UNO.1, FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT, FDP_ROL.1/FIREWALL, FDP_SDI.2, FDP_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL, FIA_AFL.1/CM, FIA_AFL.1/PIN_BIO, FMT_MTD.1/PIN_BIO Section 4.3.1 O.TRANSACTION FDP_ROL.1/FIREWALL, FDP_RIP.1/ABORT, FDP_RIP.1/ODEL, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/KEYS, FDP_RIP.1/ADEL, FDP_RIP.1/TRANSIENT, FDP_RIP.1/OBJECTS Section 4.3.1 O.OBJ-DELETION FDP_RIP.1/ODEL, FPT_FLS.1/ODEL Section 4.3.1 O.DELETION FDP_ACC.2/ADEL, FDP_ACF.1/ADEL, FDP_RIP.1/ADEL, FPT_FLS.1/ADEL, FPT_RCV.3/Installer, FMT_MSA.1/ADEL, FMT_MSA.3/ADEL, FMT_SMR.1/ADEL Section 4.3.1 ID-ONE COSMO V8.2 Public Security Target 150 | 202 Security Objectives Security Functional Requirements Rationale O.LOAD FCO_NRO.2/CM, FDP_IFC.2/CM, FDP_IFF.1/CM, FDP_UIT.1/CM, FIA_UID.1/CM, FTP_ITC.1/CM Section 4.3.1 O.INSTALL FDP_ITC.2/Installer, FPT_RCV.3/Installer, FPT_FLS.1/Installer, Section 4.3.1 O.SCP.SUPPORT FPT_RCV.3/SCP, FPT_RCV.4/SCP Section 4.3.1 O.SCP.IC FPT_PHP.3/SCP, FCS_RNG.1/SCP Section 4.3.1 O.SCP.RECOVERY FPT_RCV.3/SCP, FRU_FLT.1/SCP, FAU_ARP.1, FPT_FLS.1, FPT_FLS.1/SCP FPT_RCV.4/SCP Section 4.3.1 O.RESIDENT_APPLICATION FDP_ACC.2/PP, FDP_ACF.1/PP, FDP_UCT.1/PP, FDP_ITC.1/PP, FIA_AFL.1/PP, FIA_UAU.1/PP, FIA_UID.1/PP, FMT_MSA.1/PP, FMT_SMF.1/PP, FMT_MOF.1/PP, FMT_SMR.2/PP, FMT_MSA.3/PP, FCS_CKM.4/PP, FMT_SMR.2/CM, FIA_UAU.1/CM Section 4.3.1 O.CARD_MANAGEMENT FIA_UID.1/CM, FDP_IFF.1/CM, FMT_MSA.1/CM, FMT_MSA.3/CM, FMT_SMR.2/PP, FMT_SMF.1/PP, FTP_ITC.1/CM, FCO_NRO.2/CM, FMT_SMR.2/CM, FDP_IFC.2/CM, FCO_NRO.2/CM_DAP, FIA_UAU.7/CardIssuer, FPR_UNO.1/Key_CM, FIA_UAU.4/CardIssuer, FPT_TDC.1/CM, FIA_ATD.1/CardManu, FIA_UAU.4/CardManu, FIA_UAU.7/CardManu, FMT_SMF.1/CM, FMT_SMR.1/CM Section 4.3.1 O.SECURE_COMPARE FPR_UNO.1/Applet Section 4.3.1 O.PATCH_LOADING FDP_ACC.2/PP, FDP_ACF.1/PP, FIA_UAU.1/PP, FIA_UID.1/PP, FCS_COP.1/PP, FTP_ITC.1/CM, FCS_COP.1/CM, FDP_UIT.1/PP, FDP_ITC.1/PP, FCS_CKM.1/PP, FTP_ITC.1/PP, FDP_UCT.1/PP, FMT_MOF.1/PP, FCS_CKM.4/PP, FAU_STG.2, FIA_AFL.1/PP, FPT_TST.1 Section 4.3.1 Table 23– Security Objectives and SFRs - Coverage ID-ONE COSMO V8.2 Public Security Target 151 | 202 Security Functional Requirements Security Objectives Rationale FDP_ACC.2/FIREWALL O.FIREWALL, O.OPERATE, O.PIN-MNGT,O.BIO-MNGT FDP_ACF.1/FIREWALL O.FIREWALL, O.NATIVE, O.OPERATE, O.PIN-MNGT, O.BIO-MNGT FDP_IFC.1/JCVM O.FIREWALL, O.GLOBAL_ARRAYS_CONFID, O.GLOBAL_ARRAYS_INTEG FDP_IFF.1/JCVM O.FIREWALL, O.GLOBAL_ARRAYS_CONFID, O.GLOBAL_ARRAYS_INTEG FDP_RIP.1/OBJECTS O.GLOBAL_ARRAYS_CONFID, O.REALLOCATION, O.KEY-MNGT, O.PIN-MNGT, O.TRANSACTION FMT_MSA.1/JCRE O.SID, O.FIREWALL FMT_MSA.1/JCVM O.SID, O.FIREWALL FMT_MSA.2/FIREWALL_JCVM O.FIREWALL 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.REALLOCATION, O.KEY-MNGT, O.PIN-MNGT, O.BIO- MNGT, O.TRANSACTION ID-ONE COSMO V8.2 Public Security Target 152 | 202 Security Functional Requirements Security Objectives Rationale FDP_RIP.1/APDU O.GLOBAL_ARRAYS_CONFID, O.REALLOCATION, O.KEY-MNGT, O.PIN-MNGT, O.BIO- MNGT, O.TRANSACTION FDP_RIP.1/bArray O.GLOBAL_ARRAYS_CONFID, O.REALLOCATION, O.KEY-MNGT, O.PIN-MNGT, O.BIO- MNGT, O.TRANSACTION FDP_RIP.1/KEYS O.GLOBAL_ARRAYS_CONFID, O.REALLOCATION, O.KEY-MNGT, O.PIN-MNGT, O.BIO- MNGT, O.TRANSACTION FDP_RIP.1/TRANSIENT O.GLOBAL_ARRAYS_CONFID, O.REALLOCATION, O.KEY-MNGT, O.PIN-MNGT, O.BIO- MNGT, O.TRANSACTION FDP_ROL.1/FIREWALL O.OPERATE, O.RESOURCES, O.PIN-MNGT, O.BIO-MNGT, O.TRANSACTION FAU_ARP.1 O.OPERATE, O.RESOURCES, O.ALARM, O.SCP.RECOVERY FDP_SDI.2 O.KEY-MNGT, O.PIN-MNGT, O.BIO-MNGT FPR_UNO.1 O.CIPHER, O.KEY-MNGT, O.PIN-MNGT, O.BIO-MNGT FPT_FLS.1 O.OPERATE, O.RESOURCES, O.ALARM, O.SCP.RECOVERY FPT_TDC.1 O.OPERATE FIA_ATD.1/AID O.SID, O.OPERATE FIA_UID.2/AID O.SID FIA_USB.1/AID O.SID, O.OPERATE FMT_MTD.1/JCRE O.SID, O.FIREWALL, O.RESOURCES FMT_MTD.3/JCRE O.SID, O.FIREWALL, O.RESOURCES FDP_ITC.2/Installer O.SID, O.FIREWALL, O.OPERATE, O.INSTALL FMT_SMR.1/Installer O.FIREWALL, O.RESOURCES ID-ONE COSMO V8.2 Public Security Target 153 | 202 Security Functional Requirements Security Objectives Rationale FPT_FLS.1/Installer O.OPERATE, O.RESOURCES, O.ALARM, O.INSTALL FPT_RCV.3/Installer O.OPERATE, O.RESOURCES, O.DELETION, O.INSTALL FDP_ACC.2/ADEL O.DELETION FDP_ACF.1/ADEL O.DELETION FDP_RIP.1/ADEL O.GLOBAL_ARRAYS_CONFID, O.REALLOCATION, O.KEY-MNGT, O.PIN-MNGT, O.BIO- MNGT, O.TRANSACTION, O.DELETION FMT_MSA.1/ADEL O.SID, O.FIREWALL, O.DELETION FMT_MSA.3/ADEL O.SID, O.FIREWALL, O.DELETION FMT_SMF.1/ADEL O.SID, O.FIREWALL, O.RESOURCES FMT_SMR.1/ADEL O.FIREWALL, O.RESOURCES, O.DELETION FPT_FLS.1/ADEL O.OPERATE, O.RESOURCES, O.ALARM, O.DELETION FMT_MTD.1/PIN_BIO O.BIO-MNGT FDP_RIP.1/ODEL O.GLOBAL_ARRAYS_CONFID, O.REALLOCATION, O.KEY-MNGT, O.PIN-MNGT, O.BIO- MNGT, O.TRANSACTION, O.OBJ-DELETION FPT_FLS.1/ODEL O.OPERATE, O.RESOURCES, O.ALARM, O.OBJ-DELETION FCO_NRO.2/CM O.LOAD, O.INSTALL, O.CARD_MANAGEMENT FDP_IFC.2/CM O.LOAD, O.CARD_MANAGEMENT FDP_IFF.1/CM O.LOAD, O.CARD_MANAGEMENT FDP_UIT.1/CM O.LOAD FIA_UID.1/CM O.LOAD, O.CARD_MANAGEMENT ID-ONE COSMO V8.2 Public Security Target 154 | 202 Security Functional Requirements Security Objectives Rationale FMT_MSA.1/CM O.SID, O.FIREWALL, O.CARD_MANAGEMENT FMT_MSA.3/CM O.SID, O.FIREWALL, O.CARD_MANAGEMENT FMT_SMF.1/CM O.SID, O.FIREWALL, O.RESOURCES, O.CARD_MANAGEMENT FMT_SMR.1/CM O.FIREWALL, O.RESOURCES, O.CARD_MANAGEMENT FTP_ITC.1/CM O.LOAD, O.INSTALL, O.CARD_MANAGEMENT, O.PATCH_LOADING FPT_TST.1 O.OPERATE, O.PATCH_LOADING FCO_NRO.2/CM_DAP O.CARD_MANAGEMENT FIA_AFL.1/CM O.PIN-MNGT, O.BIO-MNGT FIA_UAU.1/CM O.RESIDENT_APPLICATION FIA_UAU.4/CardIssuer O.CARD_MANAGEMENT FIA_UAU.7/CardIssuer O.CARD_MANAGEMENT FPR_UNO.1/Key_CM O.CARD_MANAGEMENT FPT_TDC.1/CM O.CARD_MANAGEMENT FMT_SMR.2/CM O.RESIDENT_APPLICATION, O.CARD_MANAGEMENT FDP_ACC.2/PP O.RESIDENT_APPLICATION, O.PATCH_LOADING FDP_ACF.1/PP O.RESIDENT_APPLICATION, O.PATCH_LOADING FDP_UCT.1/PP O.RESIDENT_APPLICATION, O.PATCH_LOADING FDP_ITC.1/PP O.RESIDENT_APPLICATION, O.PATCH_LOADING FIA_AFL.1/PP O.RESIDENT_APPLICATION, O.PATCH_LOADING FIA_UAU.1/PP O.RESIDENT_APPLICATION, O.PATCH_LOADING ID-ONE COSMO V8.2 Public Security Target 155 | 202 Security Functional Requirements Security Objectives Rationale FIA_UID.1/PP O.RESIDENT_APPLICATION, O.PATCH_LOADING FMT_MSA.1/PP O.RESIDENT_APPLICATION FMT_SMF.1/PP O.RESIDENT_APPLICATION, O.CARD_MANAGEMENT FIA_ATD.1/CardManu O.CARD_MANAGEMENT FIA_UAU.4/CardManu O.CARD_MANAGEMENT FIA_UAU.7/CardManu O.CARD_MANAGEMENT FMT_MOF.1/PP O.RESIDENT_APPLICATION, O.PATCH_LOADING FMT_SMR.2/PP O.RESIDENT_APPLICATION, O.CARD_MANAGEMENT FMT_MSA.3/PP O.RESIDENT_APPLICATION FCS_COP.1/PP O.CIPHER, O.KEY-MNGT, O.PATCH_LOADING FCS_CKM.4/PP O.RESIDENT_APPLICATION, O.PATCH_LOADING FPT_PHP.3/SCP O.SCP.IC FPT_FLS.1/SCP O.SCP.RECOVERY FPT_RCV.3/SCP O.SCP.SUPPORT, O.SCP.RECOVERY FPT_RCV.4/SCP O.SCP.SUPPORT FRU_FLT.1/SCP O.SCP.RECOVERY FPR_UNO.1/USE_KEY O.CIPHER, O.KEY-MNGT FCS_RNG.1/SCP O.SCP.IC FIA_AFL.1/PIN O.PIN-MNGT FMT_MTD.2/GP_PIN O.PIN-MNGT ID-ONE COSMO V8.2 Public Security Target 156 | 202 Security Functional Requirements Security Objectives Rationale FPR_UNO.1/Applet O.SECURE_COMPARE FMT_MTD.1/PIN O.PIN-MNGT FIA_AFL.1/GP_PIN O.PIN-MNGT FIA_AFL.1/PIN_BIO O.BIO-MNGT FDP_ACC.2/RV_Stack O.FIREWALL FDP_ACF.1/RV_Stack O.FIREWALL FMT_MSA.1/RV_Stack O.FIREWALL FMT_MSA.2/RV_Stack O.FIREWALL FMT_MSA.3/RV_Stack O.FIREWALL FMT_SMF.1/RV_Stack O.FIREWALL FDP_ACC.2/RV_Heap O.FIREWALL FDP_ACF.1/RV_Heap O.FIREWALL FMT_MSA.1/RV_Heap O.FIREWALL FMT_MSA.2/RV_Heap O.FIREWALL FMT_MSA.3/RV_Heap O.FIREWALL FMT_SMF.1/RV_Heap O.FIREWALL FDP_ACC.2/RV_Transient O.FIREWALL FDP_ACF.1/RV_Transient O.FIREWALL FMT_MSA.1/RV_Transient O.FIREWALL FMT_MSA.2/RV_Transient O.FIREWALL ID-ONE COSMO V8.2 Public Security Target 157 | 202 Security Functional Requirements Security Objectives Rationale FMT_MSA.3/RV_Transient O.FIREWALL FMT_SMF.1/RV_Transient O.FIREWALL FCS_COP.1/CM O.PATCH_LOADING FDP_UIT.1/PP O.PATCH_LOADING FCS_CKM.1/PP O.PATCH_LOADING FTP_ITC.1/PP O.PATCH_LOADING FAU_STG.2 O.PATCH_LOADING Table 24: SFRs and Security Objectives 9.3.3 Dependencies 9.3.3.1 SFRs Dependencies Requirements CC Dependencies Satisfied Dependencies FDP_ITC.2/Installer (FDP_ACC.1 or FDP_IFC.1) and (FPT_TDC.1) and (FTP_ITC.1 or FTP_TRP.1) FDP_IFC.2/CM, FTP_ITC.1/CM, FPT_TDC.1 FMT_SMR.1/Installer (FIA_UID.1) FPT_FLS.1/Installer No Dependencies FPT_RCV.3/Installer (AGD_OPE.1) AGD_OPE.1 FDP_ACC.2/ADEL (FDP_ACF.1) FDP_ACF.1/ADEL FDP_ACF.1/ADEL (FDP_ACC.1) and (FMT_MSA.3) FDP_ACC.2/ADEL, FMT_MSA.3/ADEL ID-ONE COSMO V8.2 Public Security Target 158 | 202 Requirements CC Dependencies Satisfied Dependencies FDP_RIP.1/ADEL No Dependencies FMT_MSA.1/ADEL (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FDP_ACC.2/ADEL, FMT_SMF.1/ADEL, FMT_SMR.1/ADEL FMT_MSA.3/ADEL (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/ADEL, FMT_SMR.1/ADEL FMT_SMF.1/ADEL No Dependencies FMT_SMR.1/ADEL (FIA_UID.1) FPT_FLS.1/ADEL No Dependencies FMT_MTD.1/PIN_BIO (FMT_SMF.1) and (FMT_SMR.1) FMT_SMF.1/CM, FMT_SMR.2/CM 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 (FTP_ITC.1 or FTP_TRP.1) FDP_IFC.2/CM, FTP_ITC.1/CM FIA_UID.1/CM No Dependencies FMT_MSA.1/CM (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FDP_IFC.2/CM, FMT_SMF.1/CM, FMT_SMR.1/CM FMT_MSA.3/CM (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/CM, FMT_SMR.1/CM FMT_SMF.1/CM No Dependencies ID-ONE COSMO V8.2 Public Security Target 159 | 202 Requirements CC Dependencies Satisfied 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/FIREWALL FDP_ACF.1/FIREWALL (FDP_ACC.1) and (FMT_MSA.3) FDP_ACC.2/FIREWALL, FMT_MSA.3/FIREWALL FDP_IFC.1/JCVM (FDP_IFF.1) FDP_IFF.1/JCVM FDP_IFF.1/JCVM (FDP_IFC.1) and (FMT_MSA.3) FDP_IFC.1/JCVM, FMT_MSA.3/JCVM FDP_RIP.1/OBJECTS No Dependencies FMT_MSA.1/JCRE (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FDP_ACC.2/FIREWALL, FMT_SMR.1 FMT_MSA.1/JCVM (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FDP_ACC.2/FIREWALL, FDP_IFC.1/JCVM, FMT_SMF.1, FMT_SMR.1 FMT_MSA.2/FIREWALL_JCVM (FDP_ACC.1 or FDP_IFC.1) and (FMT_MSA.1) and (FMT_SMR.1) FDP_ACC.2/FIREWALL, FDP_IFC.1/JCVM, FMT_MSA.1/JCRE, FMT_MSA.1/JCVM, FMT_SMR.1 FMT_MSA.3/FIREWALL (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/JCRE, FMT_MSA.1/JCVM, FMT_SMR.1 FMT_MSA.3/JCVM (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/JCVM, FMT_SMR.1 FMT_SMF.1 No Dependencies FMT_SMR.1 (FIA_UID.1) FIA_UID.2/AID FCS_CKM.1 (FCS_CKM.2 or FCS_COP.1) and (FCS_CKM.4) FCS_CKM.2, FCS_CKM.4 FCS_CKM.2 (FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2) and (FCS_CKM.4) FCS_CKM.1, FCS_CKM.4 ID-ONE COSMO V8.2 Public Security Target 160 | 202 Requirements CC Dependencies Satisfied Dependencies FCS_CKM.3 (FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2) and (FCS_CKM.4) FCS_CKM.1, FCS_CKM.4 FCS_CKM.4 (FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2) FCS_CKM.1 FCS_COP.1 (FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2) and (FCS_CKM.4) FCS_CKM.1, FCS_CKM.4 FDP_RIP.1/ABORT No Dependencies FDP_RIP.1/APDU No Dependencies FDP_RIP.1/bArray No Dependencies FDP_RIP.1/KEYS No Dependencies FDP_RIP.1/TRANSIENT No Dependencies FDP_ROL.1/FIREWALL (FDP_ACC.1 or FDP_IFC.1) FDP_ACC.2/FIREWALL, FDP_IFC.1/JCVM FAU_ARP.1 (FAU_SAA.1) FDP_SDI.2 No Dependencies FPR_UNO.1 No Dependencies FPT_FLS.1 No Dependencies FPT_TDC.1 No Dependencies FIA_ATD.1/AID No Dependencies FIA_UID.2/AID No Dependencies FIA_USB.1/AID (FIA_ATD.1) FIA_ATD.1/AID 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 ID-ONE COSMO V8.2 Public Security Target 161 | 202 Requirements CC Dependencies Satisfied Dependencies FPT_TST.1 No Dependencies FCO_NRO.2/CM_DAP (FIA_UID.1) FIA_UID.1/PP FIA_AFL.1/CM (FIA_UAU.1) FIA_UAU.1/CM FIA_UAU.1/CM (FIA_UID.1) FIA_UID.1/CM FIA_UAU.4/CardIssuer No Dependencies FIA_UAU.7/CardIssuer (FIA_UAU.1) FIA_UAU.1/CM FPR_UNO.1/Key_CM No Dependencies FPT_TDC.1/CM No Dependencies FMT_SMR.2/CM (FIA_UID.1) FIA_UID.1/PP FDP_ACC.2/PP (FDP_ACF.1) FDP_ACF.1/PP FDP_ACF.1/PP (FDP_ACC.1) and (FMT_MSA.3) FDP_ACC.2/PP, FMT_MSA.3/PP FDP_UCT.1/PP (FDP_ACC.1 or FDP_IFC.1) and (FTP_ITC.1 or FTP_TRP.1) FTP_ITC.1/PP, FDP_ACC.2/PP FDP_ITC.1/PP (FDP_ACC.1 or FDP_IFC.1) and (FMT_MSA.3) FDP_ACC.2/PP, FMT_MSA.3/PP FIA_AFL.1/PP (FIA_UAU.1) FIA_UAU.1/PP FIA_UAU.1/PP (FIA_UID.1) FIA_UID.1/PP FIA_UID.1/PP No Dependencies FMT_MSA.1/PP (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FDP_ACC.2/PP, FMT_SMF.1/PP, FMT_SMR.2/PP FMT_SMF.1/PP No Dependencies ID-ONE COSMO V8.2 Public Security Target 162 | 202 Requirements CC Dependencies Satisfied Dependencies FIA_ATD.1/CardManu No Dependencies FIA_UAU.4/CardManu No Dependencies FIA_UAU.7/CardManu (FIA_UAU.1) FIA_UAU.1/PP FMT_MOF.1/PP (FMT_SMF.1) and (FMT_SMR.1) FMT_SMF.1/PP, FMT_SMR.2/PP FMT_SMR.2/PP (FIA_UID.1) FIA_UID.1/PP FMT_MSA.3/PP (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/PP, FMT_SMR.2/PP FCS_COP.1/PP (FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2) and (FCS_CKM.4) FDP_ITC.1/PP, FCS_CKM.4/PP FCS_CKM.4/PP (FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2) FDP_ITC.1/PP FPT_PHP.3/SCP No Dependencies FPT_FLS.1/SCP No Dependencies FPT_RCV.3/SCP (AGD_OPE.1) AGD_OPE.1 FPT_RCV.4/SCP No Dependencies FRU_FLT.1/SCP (FPT_FLS.1) FPT_FLS.1/SCP FPR_UNO.1/USE_KEY No Dependencies FCS_RNG.1/SCP No Dependencies FIA_AFL.1/PIN (FIA_UAU.1) FIA_UAU.1/CM FMT_MTD.2/GP_PIN (FMT_MTD.1) and (FMT_SMR.1) FMT_SMR.2/PP, FMT_MTD.1/PIN FPR_UNO.1/Applet No Dependencies FMT_MTD.1/PIN (FMT_SMF.1) and (FMT_SMR.1) FMT_SMF.1/CM, FMT_SMR.2/CM FIA_AFL.1/GP_PIN (FIA_UAU.1) FIA_UAU.1/CM ID-ONE COSMO V8.2 Public Security Target 163 | 202 Requirements CC Dependencies Satisfied Dependencies FIA_AFL.1/PIN_BIO (FIA_UAU.1) FIA_UAU.1/PP FDP_ACC.2/RV_Stack (FDP_ACF.1) FDP_ACF.1/RV_Stack FDP_ACF.1/RV_Stack (FDP_ACC.1) and (FMT_MSA.3) FDP_ACC.2/RV_Stack, FMT_MSA.3/RV_Stack FMT_MSA.1/RV_Stack (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FMT_SMR.1, FDP_ACC.2/RV_Stack, FMT_SMF.1/RV_Stack FMT_MSA.2/RV_Stack (FDP_ACC.1 or FDP_IFC.1) and (FMT_MSA.1) and (FMT_SMR.1) FMT_SMR.1, FDP_ACC.2/RV_Stack, FMT_MSA.1/RV_Stack FMT_MSA.3/RV_Stack (FMT_MSA.1) and (FMT_SMR.1) FMT_SMR.1, FMT_MSA.1/RV_Stack FMT_SMF.1/RV_Stack No Dependencies FDP_ACC.2/RV_Heap (FDP_ACF.1) FDP_ACF.1/RV_Heap FDP_ACF.1/RV_Heap (FDP_ACC.1) and (FMT_MSA.3) FDP_ACC.2/RV_Heap, FMT_MSA.3/RV_Heap FMT_MSA.1/RV_Heap (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FMT_SMR.1, FDP_ACC.2/RV_Heap, FMT_SMF.1/RV_Heap FMT_MSA.2/RV_Heap (FDP_ACC.1 or FDP_IFC.1) and (FMT_MSA.1) and (FMT_SMR.1) FMT_SMR.1, FDP_ACC.2/RV_Heap, FMT_MSA.1/RV_Heap FMT_MSA.3/RV_Heap (FMT_MSA.1) and (FMT_SMR.1) FMT_SMR.1, FMT_MSA.1/RV_Heap FMT_SMF.1/RV_Heap No Dependencies FDP_ACC.2/RV_Transient (FDP_ACF.1) FDP_ACF.1/RV_Transient FDP_ACF.1/RV_Transient (FDP_ACC.1) and (FMT_MSA.3) FDP_ACC.2/RV_Transient, FMT_MSA.3/RV_Transient ID-ONE COSMO V8.2 Public Security Target 164 | 202 Requirements CC Dependencies Satisfied Dependencies FMT_MSA.1/RV_Transient (FDP_ACC.1 or FDP_IFC.1) and (FMT_SMF.1) and (FMT_SMR.1) FDP_ACC.2/RV_Transient, FMT_SMR.1, FMT_SMF.1/RV_Transient FMT_MSA.2/RV_Transient (FDP_ACC.1 or FDP_IFC.1) and (FMT_MSA.1) and (FMT_SMR.1) FDP_ACC.2/RV_Transient, FMT_SMR.1, FMT_MSA.1/RV_Transient FMT_MSA.3/RV_Transient (FMT_MSA.1) and (FMT_SMR.1) FMT_MSA.1/RV_Transient, FMT_SMR.1 FMT_SMF.1/RV_Transient No Dependencies FCS_COP.1/CM (FCS_CKM.1 or FDP_ITC.1 or FDP_ITC.2) and (FCS_CKM.4) FCS_CKM.1, FCS_CKM.4 FDP_UIT.1/PP (FDP_ACC.1 or FDP_IFC.1) and (FTP_ITC.1 or FTP_TRP.1) FDP_ACC.2/PP, FTP_ITC.1/PP FCS_CKM.1/PP (FCS_CKM.2 or FCS_COP.1) and (FCS_CKM.4) FCS_COP.1/PP, FCS_CKM.4/PP FTP_ITC.1/PP No Dependencies FAU_STG.2 (FAU_GEN.1) Table 25: SFRs Dependencies ID-ONE COSMO V8.2 Public Security Target 165 | 202 Rationale for the exclusion of Dependencies The dependency FIA_UID.1 of FMT_SMR.1/Installer is discarded. This PP does not req“ire the i”entification of the "installer" since it can be considered as part of the TSF. The dependency FIA_UID.1 of FMT_SMR.1/ADEL is discarded. This PP does not req“ire the identifi”ation of the "deletion manager" since it can be considered as part of the TSF. The dependency FMT_SMF.1 of FMT_MSA.1/JCRE is discarded. The dependency between FMT_MSA.1/JCRE and FMT_SMF.1 is not satisfied because no management functions are required for the Java Card RE. The dependency FAU_SAA.1 of FAU_ARP.1 is discarded. The dependency of FAU_ARP“1 on FAU_SAA.1 assumes that ” "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 PP. The dependency FAU_GEN.1 of FAU_STG.2 is discarded. The TOE posseses a Kill Card area, where failures are recorded. 9.3.3.2 SARs Dependencies Requirements CC Dependencies Satisfied Dependencies ADV_ARC.1 (ADV_FSP.1) and (ADV_TDS.1) ADV_FSP.5, ADV_TDS.4 ADV_FSP.5 (ADV_IMP.1) and (ADV_TDS.1) ADV_IMP.1, ADV_TDS.4 ADV_IMP.1 (ADV_TDS.3) and (ALC_TAT.1) ADV_TDS.4, ALC_TAT.2 ADV_TDS.4 (ADV_FSP.5) ADV_FSP.5 ADV_INT.2 (ADV_IMP.1) and (ADV_TDS.3) and (ALC_TAT.1) ADV_IMP.1, ADV_TDS.4, ALC_TAT.2 AGD_OPE.1 (ADV_FSP.1) ADV_FSP.5 AGD_PRE.1 No Dependencies ALC_CMC.4 (ALC_CMS.1) and (ALC_DVS.1) and (ALC_LCD.1) ALC_CMS.5, ALC_DVS.2, ALC_LCD.1 ALC_CMS.5 No Dependencies ALC_DEL.1 No Dependencies ALC_DVS.2 No Dependencies ALC_LCD.1 No Dependencies ALC_TAT.2 (ADV_IMP.1) ADV_IMP.1 ASE_CCL.1 (ASE_ECD.1) and (ASE_INT.1) and (ASE_REQ.1) ASE_ECD.1, ASE_INT.1, ASE_REQ.2 ASE_ECD.1 No Dependencies ID-ONE COSMO V8.2 Public Security Target 166 | 202 Requirements CC Dependencies Satisfied Dependencies ASE_INT.1 No Dependencies ASE_OBJ.2 (ASE_SPD.1) ASE_SPD.1 ASE_REQ.2 (ASE_ECD.1) and (ASE_OBJ.2) ASE_ECD.1, ASE_OBJ.2 ASE_SPD.1 No Dependencies ASE_TSS.1 (ADV_FSP.1) and (ASE_INT.1) and (ASE_REQ.1) ADV_FSP.5, ASE_INT.1, ASE_REQ.2 ATE_COV.2 (ADV_FSP.2) and (ATE_FUN.1) ADV_FSP.5, ATE_FUN.1 ATE_DPT.3 (ADV_ARC.1) and (ADV_TDS.4) and (ATE_FUN.1) ADV_ARC.1, ADV_TDS.4, ATE_FUN.1 ATE_FUN.1 (ATE_COV.1) ATE_COV.2 ATE_IND.2 (ADV_FSP.2) and (AGD_OPE.1) and (AGD_PRE.1) and (ATE_COV.1) and (ATE_FUN.1) ADV_FSP.5, AGD_OPE.1, AGD_PRE.1, ATE_COV.2, ATE_FUN.1 AVA_VAN.5 (ADV_ARC.1) and (ADV_FSP.4) and (ADV_IMP.1) and (ADV_TDS.3) and (AGD_OPE.1) and (AGD_PRE.1) and (ATE_DPT.1) ADV_ARC.1, ADV_FSP.5, ADV_IMP.1, ADV_TDS.4, AGD_OPE.1, AGD_PRE.1, ATE_DPT.3 Table 26: SARs Dependencies 9.3.4 Rationale for the Security Assurance Requirements The ID-One Cosmo V8.2 product claims a conformance to the Common Criteria level EAL5, augmented with the component ALC_DVS.2 (sufficiency of security measures), AVA_VAN.5 (advanced methodical vulnerability analysis). 9.3.5 AVA_VAN.5 Advanced methodical vulnerability analysis The TOE is intended to operate in h“stile environments. AVA_VAN.5 "Advanced me”hodical vulnerability 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. 9.3.6 ALC_DVS.2 Sufficiency of security measures Development security is concerned with physical, procedural, personnel and other technical measures that may be used in the development environment to protect the TOE and the embedding product. The standard ALC_DVS.1 requirement mandated by EAL5 is not enough. Due to the nature of the TOE and embedding product, it is necessary to justify the sufficiency of these procedures to protect their confidentiality and integrity. ALC_DVS.2 has no dependencies. ID-ONE COSMO V8.2 Public Security Target 167 | 202 10TOE Summary Specification 10.1TOE Summary Specification SF_ATOMIC_TRANSACTION This TSF provides means to execute a sequence of modifications and allocations on the persistent memory so that either all of them are completed, or the TOE behaves as if none of them had been attempted. The transaction mechanism is used for updating internal TSF data as well as for performing different functions of the TOE, like installing a new package on the card. This TSF is also available for applet instances through the javacard.framework.JCSystem, javacard.framework.Util and javacardx.framework.util.ArrayLogic classes. The first class provides the applet instances with methods for starting, aborting and committing a sequence of modifications of the persistent memory. The other classes provide methods for atomically copying arrays. This TSF ensures that the following data is never updated conditionally: o The validated flag of the PINs o The validated flag of the BIO template o The reason code of the CardException and CardRuntimeException o Transient objects o Global arrays, like the APDU buffer and the buffer that the applet instances use to store installation data o Any intermediate result state in the implementation instance of the Checksum, Signature, Cipher, and Message Digest classes of the JavaCard API. This TSF also performs the actions necessary to roll back to a safe state upon interruption of the following procedures, for example because of a card withdrawal or an unexpected fatal error: o Loading and linking of a package o Installing a new applet instance o Deleting a package o Deleting an applet instance o Collecting unreachable objects o Reading from and writing to a static field, instance field or array position o Populating, updating or clearing a cryptographic key o Modifying a PIN value Finally, this TSF ensures that no transaction is in progress when a method of an applet instance is invoked for installing, deselecting, selecting or processing an APDU sent to the applet instance. Concerning memory limitations on the transaction journal, this TSF guarantees that an exception is thrown when the maximal capacity is reached. The TSF preserves a secure state when such limit is reached. Atomic Transactions are detailed in the chapter Atomicity and Transactions of the [R7] and in the documentation associated to the JCSystem class in the [R6]. SF_CARD_CONTENT_MANAGEMENT This TSF ensures the following functionalities: ID-ONE COSMO V8.2 Public Security Target 168 | 202 o Loading (Section 9.3.5 of [R12]): This function allows the addition of code to mutable persistent memory in the card. During card content loading, this TSF checks that the required packages are already installed on the card. If one of the required packages does not exist, or if the version installed on the card is not binary compatible with the version required, then the loading of the package is rejected. Loading is also rejected if the version of the CAP format of the package is newer than the one supported by the TOE. If any of those checks fails, a suitable error message is returned to the CAD. o Installation (Section 9.3.6 of [R12]): This function allows the Installer to create an instance of a previously loaded Applet subclass and make it selectable. In order to do this, the install() method of the Applet subclass is invoked using the context of that new instance as the currently active context. If this method returns with an exception, the exception is trapped and the smart card rolls back to the state before starting the installation procedure. o Deletion (Section 9.5 of [R12]): This function allows the Applet Deletion Manager to remove the code of a package from the card, or to definitely deactivate an applet instance, so that it becomes no longer selectable. This TSF performs physical removal of those packages and applet data stored in NVRAM, while only logical removal is performed for packages in ROM. This TSF checks that the package or applet actually exists, and that no other package or applet depends on it for its execution. In this case, the entry of the package or applet is removed from the registry, and all the objects on which they depend are garbage collected. Otherwise, a suitable error is returned to the CAD. The deletion of the Applet Deletion Manager, the Installer or any of the packages required for implementing the Java Card platform Application Programming Interface (Java Card API) is not allowed. o Extradition (Section 9.4.1 of): This function allows the Installer to associate load files or applet instances to a Security Domain different than their currently associated Security Domain. It is also used to associate a Security Domain to another Security Domain or to itself thus creating Security Domains hierarchies. If this method returns with an exception, the exception is trapped and the smart card rolls back to the state before starting the extradition procedure. o Registry update (Section 9.4.2 of): This function allows the Installer to populate, modify or delete elements of the Registry entry of applet instances. If this method returns with an exception, the exception is trapped and the smart card rolls back to the state before starting the extradition procedure. SF_CARD_MANAGEMENT_ENVIRONMENT This TSF is in charge of initializing and managing the internal data structures of the Card Manager. During the initialization phase of the card, this TSF creates the Installer and the Applet Deletion Manager and initializes their internal data structures. The internal data structures of the Card Manager includes the Package and Applet Registries, which respectively contains the currently loaded packages and the currently installed applet instances, together with their associated AIDs. This TSF is also in charge of dispatching the APDU commands to the applets instances installed on the card and keeping traces of which are the currently active ones. It therefore handles sensitive TSF data of other security functions, like the Firewall or the Remote Access Control function. SF_CARDHOLDER_VERIFICATION ID-ONE COSMO V8.2 Public Security Target 169 | 202 This TSF enables applet instances to authenticate the sender of a request as the true cardholder. Applet instances have access to these services through the OwnerPIN class. Cardholder authentication is performed using the following security attributes: o A secret enabling to authenticate the cardholder o The maximum number of consecutive unsuccessful comparison attempts that are admitted o A counter of the number of consecutive unsuccessful comparison attempts that have been performed so far o The current life cycle state of the secret (reference value). This state is always updated, even if the modification is in the scope of an open transaction. Each time an attempt is made to compare a value to the reference value, and prior to the comparison being actually performed, if the reference is blocked, then the comparison fails and the reference value is not accessed. Otherwise, the try counter is decremented by one. This operation is always performed, even if it is in the scope of an open transaction. If the comparison is successful, then the try counter is reset to the try limit. When the try counter reaches zero, the reference enters into a blocked state, and cannot be used until it is unblocked. Cardholder Verification Method services are implemented to resist to environmental stress and glitches and include measures for preventing information leakage through covert channels. In particular, unsuccessful authentication attempts consume the same power and execution time than successful ones. The Cardmanager uses the class OwnerPin to provide the services to the Applet that want benefit of the Shared GP_PIN. SF_CLEARING_OF_SENSITIVE_INFORMATION This TSF clears all the data containers that hold sensitive information when that information is no longer used. This includes: o The contents of the memory blocks allocated for storing class instances, arrays, static field images and local variables, before allocating a fresh block o The objects reclaimed by the Java Card VM garbage collector o The code of the deleted packages o The objects accessible from a deleted applet instance o All the information contained in the packages that is not necessary for executing the code of the applets, like the Descriptor Component, the Reference Location Component and the Constant Pool of the CAP files o The contents of the APDU buffer after processing an APDU command o The content of the bArray argument of the Applet.install method after a new applet instance is installed o The content of CLEAR ON DESELECT transient objects owned by an applet instance that has been deselected when no other applets from the same package are active on the card o The content of all transient objects after a card reset o The reason code contained in the instances of a CardException or CardRuntimeException classes after a card reset o The validated flag of the PINs after a card reset o The validated flag of the BIO templates after a card reset o The contents of the cryptographic buffer after performing cryptographic operations o The content of the input parameters of a remote method invocation after returning the response to the terminal ID-ONE COSMO V8.2 Public Security Target 170 | 202 Application Note: This function is in charge of clearing the information contained in the objects that are no longer accessible from the installed packages and applet instances. Clearing is performed on demand of an applet instance through the JCSystem.requestObjectDeletion() method. SF_DAP_VERIFICATION An Application Provider may require that its Application code to be loaded on the card is checked for integrity and authen ticity. The DAP Verification privil’ge of the Application Provider's Security Domain detailed in Section 9.2.1 of provides this service on behalf of an Application Provider. A Controlling Authority may require that all Application code to be loaded onto the card shall be checked for integrity and authenticity. The Mandated DAP Verification privile’e of the Controlling Authority's Security Domain detailed in Section 9.2.1 of provides this service on behalf of the Controlling Authority. The keys and algorithms to be used for DAP Verification or Mandated DAP Verification are implicitly known by the corresponding Security domain. SF_DATA_COHERENCY As coherency of data should be maintained, and as power is provided by the CAD and might be stopped at all moment (by tearing or attacks), a transaction mechanism is provided. When updating data, before writing the new ones, the old ones are saved in a specific memory area. If a failure appears, at the next start-up, if old data are valid in the transaction area, the system restores them for staying in a coherent state. SF_DATA_INTEGRITY Some of the data in non volatile memory can be protected. Keys, PIN, BIO templates package and patch, if any code are protected with integrity value. When reading and writing operation are, the integrity value is checked and maintained valid. In case of incoherency, an exception is raise to prevent the bad use of the data. SecureStore is a mean for protecting JavaCard data in integrity. SF_ENCRYPTION_AND_DECRYPTION This TSF provides the applet instances with mechanisms for encrypting and decrypting the contents of a byte array. The ciphering algorithms are available to the applets through the Cipher class of the Java Card API, ISOSecureMessaging class and SecureChannel class. The length of the key to be used for the ciphering operation is defined by the applet instance when the key is generated. Before encrypting or decrypting the byte array, the TSF verifies that the specified key has been previously initialized, and that is in accordance with the specified ciphering algorithm (DES, RSA, etc). The TSF also checks that it has been provided with all the information necessary for the encryption/decryption operation. Once the ciphering operation is performed, the internal TSF data used for the operation like the ICV is cleared. Ciphering operations are implemented to resist to environmental stress and glitches and include measures for preventing information leakage through covert channels. Mechanisms of encrypting and decrypting for Secure Messaging are available to the applets through the SecureChannel (Global Platform Card 2.2" specification) and ISOSecureMessaging (Proprietary API) classes. SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL ID-ONE COSMO V8.2 Public Security Target 171 | 202 Off-card entity authentication is achieved by initiating a Secure Channel and provides assurance to the card that it is communicating with an authenticated off-card entity. If any step in the off-card authentication process fails, the process shall be restarted (i.e. new session keys generated). The Secure Channel initiation and off-card entity authentication implies the creation of session keys derived from card static key(s). SF_EXCEPTION In case of abnormal event: data unavailable on an allocation, illegal access to a data, the system owns an internal mechanism that allows to stop the code execution and raise “n exception” SF_FIREWALL This TSF enforces the Firewall security policy and the information flow control policy at runtime. The former policy controls object sharing between different applet instances, and between applet instances and the Java Card RE. The latter policy controls the access to global data containers shared by all applet instances. This TSF is enforced by the Java Card platform Virtual Machine (Java Card VM). During the execution of an applet, the Java Card VM keeps track of the applet instance that is currently performing an action. This information is known as the currently active context. Two kinds of contexts are considered: applet instances contexts and the Java Card RE context, which has special privileges for accessing objects. The TSF makes no difference between instances of applets defined in the same package: all of them belong to the same active context. On the contrary, instances of applets defined in different packages belong to different contexts. Each object belongs to the context that was active when the object was allocated. Initially, when the Java Card VM is launched, the context corresponding to the applet instance selected for execution becomes the first active context. Each time an instance method is invoked on an object, a context switch is performed, and the owner of the object becomes the new active context. On the contrary, the invocation of a static method does not entail a context switch. Before executing a bytecode that accesses an object, the object's owner is checked against the currently active context in order to determine if access is allowed. Access is determined by the Firewall access control rules specified in the chapter Applet Isolation and Object Sharing of the [R7]. Those rules enable controlled sharing of objects through interface methods that the object's owner explicitly exports to other applet instance, and provided that the object's owner explicitly accepts to shar it upon request of the method's invoker. SF_GP_DISPATCHER While a Security Domain is selected, this function tests for every command, according to the Security Domain life cycle state and the Card life cycle state, if security requirements are needed (if a Secure Channel is require). SF_HARDWARE_OPERATING When needed, at each start up or before first use, a self test of each hardware functional module is done, i.e.: DES, RSA, RNG implements a know calculus and checks if the result is correct. When executing, external hardware event can be trigged to prevent attacks or bad use. Temperature, frequency, voltage, light, glitch are considered as abnormal environmental conditions and put the card in frozen state. The TOE shall monitor IC detectors (e.g. out-of-range voltage, temperature, frequency, active shield, memory aging) and shall provide automatic answers to potential security violations through interruption routines that leave the device in a secure state. ID-ONE COSMO V8.2 Public Security Target 172 | 202 The TOE with the IC has detectors of operational conditions. It shall resist to attackers with high-attack potential according to [R36] characterisation, in particular, to leakage attacks, intrusive (e.g. probing, fault injection) and non-intrusive (e.g. SPA, DPA, EMA) attacks, operational conditions manipulation (voltage, clock, temperature, etc) and physical attacks aiming at modification of the IC content or behaviour. To be compliant to related SUN Protection Profile [R5], the off-card verifier is mandatory in this ST; however, this TOE runs some additional verification at execution time. These verifications ensure that: 1. No read accesses are made to Java Card System code, data belonging to another application, data belonging to the Java Card System, 2. No write accesses ’re made to another application's code, Java Card System code, another application's data Java Card System or API data, 3. No execution of code is done from a method or from a method fragment belonging to another package (including execution on arbitary data). SF_KEY_ACCESS This TSF enforces secure access to all cryptographic keys of the card: RSA keys, DES keys, EC keys, AES keys SF_KEY_AGREEMENT This TSF provides the applet instances with a mechanism for supporting key agreement algorithms such as Diffie-Hellman and EC Diffie-Hellman [IEEE P363]. SF_KEY_DESTRUCTION This TSF disables the use of a key both logically and physically. When a key is cleared, the internal life cycle of the key container is moved to a state in which no operation is allowed. Applet instances may invoke this TSF through the interfaces declared in the javacard.security package of the Java Card API. SF_KEY_DISTRIBUTION This TSF enforces the distribution of all the cryptographic keys of the card using the method specified in that SFR. SF_KEY_GENERATION This TSF enforces the creation and/or the oncard generation of all the cryptographic keys of the card using the method specified in that SFR. SF_KEY_MANAGEMENT This function enables key sets management (PIN, BIO). It allows creating updating and deleting key sets. It is used to load keys to the card. It also implements verification of Key sets attributes: key lengths, key types... and enforces the loaded keys integrity SF_MANUFACTURER_AUTHENTICATION At prepersonalisation phase, manufacturer authentication at the beginning of a communication session is mandatory prior to any relevant data being transferred to the TOE. SF_MESSAGE_DIGEST This TSF provides the applet instances with a mechanism for generating an (almost) unique value for a byte array content. That value can be used as a short representative of the information contained in the whole byte array. The hashing algorithms are available to the ID-ONE COSMO V8.2 Public Security Target 173 | 202 applets through the MessageDigest class of the Java Card API. Before generating the hash value, the TSF verifies that it has been provided with all the information necessary for the hashing operation. For those algorithms that do not pad the messages, the TSF checks that the information is block aligned before computing its hash value. Message digest generation is implemented to resist to environmental stress and glitches and include measures for preventing information leakage through covert channels. SF_MEMORY_FAILURE When using the non volatile memory, in case of a bad writing, internal mechanisms are implemented to prevent an incoherency of the written data. In case of an impossible writing, an exception is raised. SF_PREPERSONALISATION This function is in charge of pre-initializing the internal data structures, loading the configuration of the card and loading patch code if needed. SF_RANDOM_NUMBER This TSF provides to card manager, resident application, applets a mechanism for generating challenges and key values. Random number generators are available to the applets through the RandomData class of the Java Card API. Off-card entity authentication is achieved through the process of initiating a Secure Channel and provides assurance to the card that it is communicating with an authenticated off-card entity. If any step in the off- card authentication process fails, the process shall be restarted (i.e. new session keys generated). The Secure Channel initiation and off-card entity authentication implies the creation of session keys derived from card static key(s). SF_RESIDENT_APPLICATION_DISPATCHER During prepersonalisation phase, this function tests for every command if manufacturer authentication is required. SF_RUNTIME_VERIFIER This security functionality ensures the secure processing of information by ensuring the following elements: o Stack Control o Heap Control o Transient Control Information on the processing is described on the related FDP_ACF.1. SF_SECURITY_FUNCTIONS_OF_THE_IC The TOE uses the security functions of the IC. The list of the security function is presented in the ST lite of the IC component. SF_SIGNATURE This TSF provides the applet instances with a mechanism for generating an electronic signature of a byte array content and verifying an electronic signature contained in a byte array. An electronic signature is made of a hash value of the information to be signed ID-ONE COSMO V8.2 Public Security Target 174 | 202 encrypted with a secret key. The verification of the electronic signature includes decrypting the hash value and checking that it actually corresponds to the block of signed bytes. The signature algorithms are available to the applets through the javacard.Signature class of the Java Card API, ISOSecureMesssaging class and SecureChannel class. The length of the key to be used for the signature is defined by the applet instance when the key is created. Before generating the signature, the TSF verifies that the specified key is suitable for the operation (secret keys for signature generation), that it has been previously initialized, and that is in accordance with the specified signature algorithm (DES, RSA, etc). The TSF also checks that it has been provided with all the information necessary for the signature operation. For those algorithms that do not pad the messages, the TSF checks that the information to be signed is block aligned before performing the signature operation. Once the signature operation is performed, the internal TSF data used for the operation like the ICV is cleared. Signature operations are implemented to resist to environmental stress and glitches and include measures for preventing information leakage through covert channels. Mechanisms of signature for Secure Messaging are available to the applets through the SecureChannel (Global Platform Card 2.2 specification) and ISOSecureMessaging (Proprietary API) classes. The signature is included in Data Objects. SF_UNOBSERVABILITY This function assures that processing based on secure elements of the TOE does not reveal any information on those elements. For example, observation of a PIN verification cannot reveal the PIN value, observation a cryptographic computation cannot give information on the key. 10.2SFRs and TSS 10.2.1 SFRs and TSS - Rationale CoreG_LC Security Functional Requirements Firewall Policy FDP_ACC.2/FIREWALL The access control policy is ensured by SF_FIREWALL, it controls whether an instance of an applet class declared in a package (subject) may read, write or execute an instance method (operations) of an object (object). FDP_ACF.1/FIREWALL FIREWALL Security attribute based access control -which security attributes is attached to which subject/object of the policy- is specified in the SF_FIREWALL. FDP_IFC.1/JCVM This requirement is fulfilled by SF_FIREWALL, this TSF enforces the information flow control rules of Firewall security policy. It controls whether an applet instance or javacard RE (subject) may store into persistent memory a reference of a global shared data container (objects). FDP_IFF.1/JCVM This requirement is fulfilled by SF_FIREWALL. This TSF controls operations, based on current active context implemented in SF_FIREWALL. FDP_RIP.1/OBJECTS SF_CLEARING_OF_SENSITIVE_INFORMATION. The TSF clears the contents of the freshly allocated objects before releasing the object to the applet. On ID-ONE COSMO V8.2 Public Security Target 175 | 202 the TSF, memory is cleared when the object is removed during Garbage Collection. All this TSFI lead to Garbage Collection FMT_MSA.1/JCRE SF_FIREWALL When an instance method is applied to an object, this TSF is in charge of performing a context switch to the context of the object's owner. The TSF is also in charge of dispatching the APDU commands to the applets instances installed on the card and keeping trace of which are the currently active ones. FMT_MSA.1/JCVM SF_FIREWALL When an instance method is applied to an object, this TSF is in charge of performing a context switch to the context of the object's owner. The TSF is also in charge of dispatching the APDU commands to the applets instances installed on the card and keeping traces of which are the currently active ones. FMT_MSA.2/FIREWALL_JCVM SF_FIREWALL When an applet instance is selected for execution, this TSF initializes the currently active context with (the context of) that instance. Applet selection includes the verification that the instance actually exists on the card. Then, during the execution of the Java Card VM, this TSF propagates that secure value the other security attributes involved in the Firewall policy (object's owner). FMT_MSA.3/FIREWALL SF_FIREWALL The TSF initializes the security attributes of the Firewall and Java Card VM security policies when an applet instance is selected for execution, when an instance method is invoked and when an object is allocated. This TSF does not provide means for a subject to override those initial values. FMT_MSA.3/JCVM SF_FIREWALL. The TSF initializes the security attributes of the Firewall and Java Card VM security policies when an applet instance is selected for execution, when ID-ONE COSMO V8.2 Public Security Target 176 | 202 an instance method is invoked and when an object is allocated. This TSF does not provide means for a subject to override those initial values. FMT_SMF.1 This SFR is fulfilled by SF_CARD_CONTENT_MANAGEMENT, when an instance method is applied to an object; this TSF is in charge of performing a context switch to the context of the object's owner. FMT_SMR.1 This requirement is full filled by SF_FIREWALL, this TSF uses a special value for the currently active context that identifies the Java Card RE (JCRE) and Java Card VM (JCVM). Application Programming Interface FCS_CKM.1 This requirement is fulfilled by SF_KEY_GENERATION. It enforces the creation and/or the oncard generation of all the cryptographic keys of the card. FCS_CKM.2 This SFR is fulfilled by SF_KEY_DISTRIBUTION. It enforces the distribution of all the cryptographic keys of the card using the method specified in that SFR. FCS_CKM.3 This SFR is implemented by SF_KEY_ACCESS. It enforces the access of all the cryptographic keys of the card using the method specified in that SFR FCS_CKM.4 SF_KEY_DESTRUCTION fulfils this SFR, it enforces the destruction of all the cryptographic keys of the card using the method specified in that SFR. FCS_COP.1 This SFR is verified by the following set of Security functionalities: o All signature and verification operation by RSA, TDES and AES are fulfilled by SF_SIGNATURE, also fulfilled by SF_KEY_AGREEMENT by providing the applet instances with a mechanism for supporting key agreement algorithms such EC Diffie-Hellman [R27]. o This requirement by using SF_ENCRYPTION_AND_DECRYPTION provides the applet instances with a mechanism for encrypting and decrypting the contents of a byte array. o SF_SIGNATURE permits to hash functions with SHA-1, SHA-224, SHA-256, SHA- 384 and SHA-512. It is also fulfilled by SF_MESSAGE_DIGEST by providing applet instances with a mechanism for generating an (almost) unique value for the contents of a byte array. Also fulfilled by SF_KEY_AGREEMENT by providing the applet instances with a mechanism for supporting key agreement algorithms such as EC Diffie-Hellman [R27]. ID-ONE COSMO V8.2 Public Security Target 177 | 202 FDP_RIP.1/ABORT Any reference to an object instance created during an aborted transaction- see SF_ATOMIC_TRANSACTIONS- is cleaned by using SF_CLEARING_OF_SENSITIVE_INFORMATION. FDP_RIP.1/APDU The TSF SF_CLEARING_OF_SENSITIVE_INFORMATION enforces the clearing of the previous contents of the APDU buffer before processing a new APDU. FDP_RIP.1/bArray The TSF SF_CLEARING_OF_SENSITIVE_INFORMATION enforces the clearing of the previous contents of the buffer containing the installation data of an applet instance before installing a new one. FDP_RIP.1/KEYS In order to perform a cryptographic operation, the key involved in the operation has to be copied out of its secure container into the cryptographic buffer of the IC co-processor. This function is in charge of ensuring that such buffer is cleared immediately after completing the operation, the clearing is done by SF_CLEARING_OF_SENSITIVE_INFORMATION. FDP_RIP.1/TRANSIENT This function is in charge of clearing the information contained in the transient objects when a clearing event arrives (deselection or card reset), invoked by SF_CLEARING_OF_SENSITIVE_INFORMATION. FDP_ROL.1/FIREWALL SF_ATOMIC_TRANSACTION, when the operations specified are not completed, this TSF is in charge of setting back the state of the persistent memory as it was before they were started. As required in chapter 7 of the [R7] and the [R6], this TSF does not undo those modifications performed on the RAM, like the modification of the APDU buffer, the installation buffer, the transient objects, the try counters of the PINs and the reason code of the card exceptions. If the commit capacity is reached, this TSF prevents any further modification of the persistent memory Card Security Management FAU_ARP.1 The SF_FIREWALL throws an instance of the SecurityException class when an attempt to violate a security policy rule is detected. FDP_SDI.2 The TSF SF_DATA_INTEGRITY ensures integrity of PIN, Keys (CRC 16) and application code (package and patch, if any) using CRC 32. A loss of integrity increases killcard counter. FPR_UNO.1 The TSF SF_DATA_INTEGRITY ensures integrity of PIN, Keys (CRC 16) and application code (package and patch, if any) using CRC 32. A loss of integrity increases killcard counter. FPT_FLS.1 This SFR is enforced by the following TSF: o SF_ATOMIC_TRANSACTIONS: card tearing and power failures and abortion of a transaction in an unexpected context o SF_FIREWALL: violations of the Firewall access control rules, o SF_CARD_CONTENT_MANAGEMENT: insufficient resources to install a package and CAP file inconsistency errors. ID-ONE COSMO V8.2 Public Security Target 178 | 202 FPT_TDC.1 This SFR is fulfilled by SF_CARD_CONTENT_MANAGEMENT_ENVIRONMENT. It interprets cap files: bytes code and data arguments. AID Management FIA_ATD.1/AID This SFR is fulfilled by SF_ARD_CONTENT_MANAGEMENT: It controls the addition of new entries in the Applet Registry. Each time a new entry is added, the TSF controls that it contains the information specified in that SFR. This is done on package loading and applet installation. FIA_UID.2/AID The TSF SF_FIREWALL identifies the applet instance requesting access to objects through the currently active context. Retrieving the currently active context always precedes the execution of the bytecodes under the control of the Firewall, as this information is required for checking the premises of its access control rules. FIA_USB.1/AID The TSF SF_FIREWALL uses the security attribute introduced in the SFR to check whether an applet instance (subject) representing an Application Provider (user) may access an object through the firewall. FMT_MTD.1/JCRE SF_CARD_CONTENT_MANAGEMENT fulfils this SFR, it controls the creation of new applet instances on the card. Each time an applet instance is created, the Installer adds an entry for it in the Applet Registry FMT_MTD.3/JCRE This SFR is fulfilled by SF_CARD_CONTENT_MANAGEMENT: it controls that only secure values are assigned as attributes of an applet instance. Invalid AIDs for the applet instances, like an AID that is already in use, are also rejected InstG Security Functional Requirements FDP_ITC.2/Installer This SFR is implemented by SF_CARD_CONTENT_MANAGEMENT: The SF ensures safe package loading and applet installation process. It modifies the CAP files to produce the TOE intern representation of the loaded package. It also performs coherency checks on the CAP files and verifies the export references. FMT_SMR.1/Installer This SFR is implemented by SF_CARD_CONTENT_MANAGEMENT: The TSF is in charge of creating the applet instance that plays the role of the Applet Installation Manager. FPT_FLS.1/Installer This SFR is fulfilled by the following SF: o The SF_CARD_CONTENT_MANAGEMENT: is in charge of checking that all the conditions for safely installing a package or an applet instance are fulfilled during the installation procedure. If conditions cannot be verified the installation is deemed unsuccessful and either an exception is thrown or the card is frozen, depending of the failure severity. Card tearing or reset also cause an installation failure. o SF_ATOMIC_TRANSACTIONS is in charge of rolling back to a secure state when the installation of a package or an applet instance is aborted ID-ONE COSMO V8.2 Public Security Target 179 | 202 FPT_RCV.3/Installer This SFR is fulfilled by the following SF: o SF_Card Content Management: In case of severe failure during package or applet installation, the card is frozen (KillCard). Such failures (for example the loading of a CAP file with an invalid format) are considered as security problems. The maintenance mode is represented by the frozen state of the card. The secure state is then reached on next card reset where Garbage Collector is launch to retrieve lost memory and where the transaction mechanism allows retrieving the initial state. o SF_Atomic Transactions: The TSF is in charge of rolling back to a secure state when the installation of a package or an applet instance is aborted ADELG Security Functional Requirements FDP_ACC.2/ADEL The access control policy for deletion is made by SF_CARD_CONTENT_MANAGEMENT, it controls whether the Applet Deletion Manager (subject) may delete (operation) a package or an applet instance (object). FDP_ACF.1/ADEL The access control policy for deletion is made by SF_CARD_CONTENT_MANAGEMENT, it controls whether the Applet Deletion Manager (subject) may delete (operation) a package or an applet instance (object). FDP_RIP.1/ADEL The TSF SF_CLEARING_OF_SENSITIVE_INFORMATION renders inaccessible the code of a deleted package and the class instances and arrays allocated by a deleted applet instance. FMT_MSA.1/ADEL The ADEL access policy is implemented in SF_CARD_MANAGEMENT_ENVIRONMENT, this TSF keeps track of which applet instances are currently active on which logical channels. Only the Card Manager (which in [R5] is identified with the Java Card RE role) is allowed to associate or remove the association between an applet instance and a logical channel. These actions are performed as part of command dispatching FMT_MSA.3/ADEL The SF_CARD_CONTENT_MANAGEMENT enforces the assignment of restrictive values for the security attributes of the Applet Deletion policy. FMT_SMF.1/ADEL Modifying the active applet security context is done by SF_CARD_MANAGEMENT_ENVIRONMENT, it's allowed to card manager. FMT_SMR.1/ADEL This SFR is fulfilled by SF_CARD_MANAGEMENT_ENVIRONMENT: it keeps track of which applet instances are currently active on which logical channels. Only the Card Manager is allowed to associate or remove the association between an applet instance and a logical channel. FPT_FLS.1/ADEL This SFR is ensured by the following TSF: o SF_CARD_CONTENT_MANAGEMENT is in charge of checking that all the conditions for safely deleting a package or an applet instance are fulfilled before starting the deletion procedure. o SF_ATOMIC_TRANSACTION: This TSF is in charge of rolling back to a secure state when the deletion of a package or an applet instance is aborted. ID-ONE COSMO V8.2 Public Security Target 180 | 202 FMT_MTD.1/PIN_BIO The SFR is implemented by the following TSF: o SF_CARDHOLDER_VERIFICATION provides a complete PIN_BIO mechanism: change_default, query and modify to applets. ODELG Security Functional Requirements FDP_RIP.1/ODEL This SFR is met by: o SF_CLEARING_OF_SENSITIVE_INFORMATION: This TSF renders inaccessible the code of a deleted package and the class instances and arrays allocated by a deleted applet instance. FPT_FLS.1/ODEL The TSF SF_CLEARING_OF_SENSITIVE_INFORMATION is in charge of checking that all the conditions for safely deleting a package or an applet instance are fulfilled before starting the deletion procedure. CarG Security Functional Requirements FCO_NRO.2/CM During the loading phase, the SF_CARD_CONTENT_MANAGEMENT: controls card content loading, it verifies the proof of the origin of the Load File. Before to start the loading, the open checks that the user is authenticated, checks the presence of the < DAPBlock > in the < LoadFile >, requires the Security Domain Verifier to verify it. FDP_IFC.2/CM The rule of the package loading flow control policy is specified by SF_CARD_CONTENT_MANAGEMENT: it verifies that all the loading commands are issued in the Secure Channel session. It compares the Load File Data Block Hash present in the command install for load against the received. It also requires the Dap verification of all entities committed in the loading phase, ensured by SF_DAP_VERIFICATION. FDP_IFF.1/CM This SFR is implemented by SF_DAP_VERIFICATION, it controls the communication protocol used by the CAD and the card for transmitting packages. FDP_UIT.1/CM This SFR is implemented by SF_DAP_VERIFICATION, it controls imported data from modification, deletion, insertion, replay of some of the pieces of the application sent by the CAD. The verification is made by using: Encryption and decryption operations by SF_ENCRYPTION_AND_DECRYPTION function. FIA_UID.1/CM The Security Functionality SF_GP_DISPATCHER met this SFR: While the Card manager (ISD) or Supplementary Security domain is selected, these functions test for every command if the secure channel is open. When the secure channel is not open then only these commands are available: Get_data() and Initialize_Update(). The initialize Update returns to the user the key set version, Secure Channel identifier and the card random and the card cryptogram. FMT_MSA.1/CM This SFR is implemented by two security functions: SF_KEY_MANAGEMENT: The TSF controls that only the CM can modify its key set and can change the card life cycle and set the default application SF_CARD_CONTENT_MANAGEMENT: This TSF controls whether the active entity has the privilege and the pre-authorization for make the Card Content Management operations, ID-ONE COSMO V8.2 Public Security Target 181 | 202 and that operation still available on the card. Its controls also that the card state allows the operations. FMT_MSA.3/CM The TSF SF_CARD_CONTENT_MANAGEMENT provides the way to lock the Security Domain with Authorized Management privilege in order to restrict its card content management ability. This TSF provides also to disable permanently the Card Content Management operations for all entities on the card. FMT_SMF.1/CM The TSF SF_CARD_CONTENT_MANAGEMENT controls whether the active entity has the privilege and the pre-authorization for making the Card Content Management operations - modify security attributes. -, and that operation still available on the card. Its controls also that the card state allows the operations. FMT_SMR.1/CM The TSF SF_CARD_CONTENT_MANAGEMENT verifies that authentication is successful and the active entity has loading privilege (Authorized Management privilege) before processes any Card Content management command. The successful authentication proves the user identity and role. FTP_ITC.1/CM Installing a new package is verified by SF_CARD_CONTENT_MANAGEMENT: the SF_GP_Dispatcher tests if secure channel is required, and verification is made by SF_DAP_VERIFICATION. Additional Security Functional Requirements Additional Security Functional Requirements for CM FCO_NRO.2/CM_DAP During the loading phase, SF_DAP_VERIFICATION verifies the proof of the origin of the Load File. Before to start the loading, the open checks that the user is authenticated, checks the presence of the < DAPBlock > in the < LoadFile >, requires the Security Domain Verifier to verify it. FIA_AFL.1/CM This Requirement is fulfilled by SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL. It tests the result of authentication. By default the authentication result is assumed unsuccessful, so the authentication failure is recorded, the associated counter and the slowdown counter are incremented. If the authentication is successful, the authentication failure counter is decremented and the slowdown counter is reset. FIA_UAU.1/CM This SFR is implemented by the following TSF: o SF_GP_DISPATCHER: While the Card manager (ISD) or Supplementary Security domain is selected, these functions test for every command by SF_GP_Dispatcher if the secure channel is open. o SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL: When the secure channel is not open then only the command available are GET DATA Initialize Update. ID-ONE COSMO V8.2 Public Security Target 182 | 202 FIA_UAU.4/CardIssuer Present the use of CardIssuer authentication, function implemented in SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL, is given by using a RNG defined in SF_RANDOM_NUMBER. FIA_UAU.7/CardIssuer This SFR is implemented by the following TSF: o SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL: It uses the key set version, Secure channel identifier and the card random and the card cryptogram for authentication. - SF_RANDOM_NUMBER: It permits CardIssuer Protected authentication feedback, no other information is given while the authentication is in progress. FPR_UNO.1/Key_CM Import of keys are not observable by all subjects. This requirement is ensured by SF_KEY_MANAGEMENT. FPT_TDC.1/CM Key set and packages when imported are consistently interpreted by implementation of SF_KEY_MANAGEMENT. FMT_SMR.2/CM The TSF SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL verifies that authentication is successful and the active entity has loading privilege before processes any Card Content management command. The successful authentication proves the user identity and role. FCS_COP.1/CM The TSF SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL covers this SFR. It requires the cryptographic operations for the creation and management of secure channel. Additional Security Functional Requirements for Resident application FDP_ACC.2/PP The SFR is implemented by the following TSF: o SF_RESIDENT_APPLICATION_DISPATCHER: This TSF implements Access control policy for the resident application, o SF_MANUFACTURER_AUTHENTICATION: This TSF is in charge of the card manufacturer authentication. o SF_PREPERSONALISATION: This TSF is in charge of enforcing the access control policy for the personalisation stage, including the patch loading, if any. These TSF controls all access to all objects and all operations. FPT_TST.1 This SFR is supported by the following TSF: o SF_HARDWARE_OPERATING: At each start up, security function SF_Hardware_Operating is done. Random, DES, and CRC functional modules systematically tested: a known calculus is implemented and the result is checked. SHA, RSA, AES and ECC functional modules are tested at each start up or at first use, using the same method. o SF_DATA_INTEGRITY: At each start up, the patch code integrity, if any is checked. FDP_ACF.1/PP This SFR is met by the following TSF: o SF_MANUFACTURER_AUTHENTICATION: The rules garanting access rights are made by SF_MANUFACTURER_AUTHENTICATION, it guarantees once the ID-ONE COSMO V8.2 Public Security Target 183 | 202 Prepersonalisation is authenticated, the card verifies for each action that the authentication is successful FDP_UCT.1/PP This SFR is met by the following TSF: o SF_MANUFACTURER_AUTHENTICATION: To transmit the InitKey (ISK) to Card Manager, user or subject must be successfully authenticated with the MSK. The transmitted InitKey is protected from disclosure by being ciphered by the MSK o SF_PREPERSONALISATION: This TSF is in charge of the prepersonalisation stage, this includes the patch loading, if any. FDP_ITC.1/PP The SFR is implemented by the following TSF: o SF_MANUFACTURER_AUTHENTICATION enables trusted channel establishment thanks to authentication with the MSK. o SF_PREPERSONALISATION enables to load patchs and locks in prepersonalisation. FIA_AFL.1/PP The SFR is implemented by the following TSF: o SF_MANUFACTURER_AUTHENTICATION: After 3 consecutive unsuccessful authentications a status error is always returned by the card. FIA_UAU.1/PP The SFR is met by the following SF: o SF_RESIDENT_APPLICATION_DISPATCHER: The set of command (INITIALIZE AUTHENTICATION PROCESS, GET DATA, MANAGE CHANNEL, SELECT APPLET, MANAGE PDC) of the resident application can be performed without authentication. FIA_UID.1/PP This SFR is implemented by the following TSF: o SF_RESIDENT_APPLICATION_DISPATCHER: The set of command (INITIALIZE AUTHENTICATION PROCESS, GET DATA, MANAGE CHANNEL, SELECT APPLET, MANAGE PDC) of the resident application can be performed without authentication. FMT_MSA.1/PP This SFR is implemented by the following TSF: o SF_PREPERSONALISATION: The MSK keys of the Card Manufacturer can be modified in Prepersonalisation phase after a successful authentication with the MSK. FMT_SMF.1/PP This SFR is implemented by the following TSF: o SF_PREPERSONALISATION: The MSK keys of the Card Manufacturer can be modified in Prepersonalisation phase after a successful authentication with the MSK. FIA_ATD.1/CardManu This SFR is implemented by the following TSF: o SF_MANUFACTURER_AUTHENTICATION: The TSF shall maintain the following list of security attributes belonging to individual users: AS.AUTH_MSK_STATUS ID-ONE COSMO V8.2 Public Security Target 184 | 202 FIA_UAU.4/CardManu This SFR is implemented by the following TSF: o SF_MANUFACTURER_AUTHENTICATION: Random numbers are used to ensure that authentication data is used once. FIA_UAU.7/CardManu This SFR is implemented by the following SFR: o SF_MANUFACTURER_AUTHENTICATION: During authentication, the command "INITIALIZE AUTHENTICATION PROCESS" is used to provide a random number. FMT_MOF.1/PP This SFR is implemented by the following TSF: o SF_CARD_MANAGEMENT_ENVIRONMENT: Some commands and features of the resident application are active only during the Prepersonalisation Phase, such as the patch and lock loading. As soon as the Card Manager status is set to OP_READY this phase stops, and the commands and features are irreversibly disabled. o SF_PREPERSONALISATION: This function permits on Prepersonalisation phase to load patch code on the card. FMT_SMR.2/PP This SFR is implemented by the following TSF: o SF_PREPERSONALISATION: This function permits on Prepersonalisation phase to load patch code on the card. o SF_MANUFACTURER_AUTHENTICATION: After a successful authentication (of Card Manufacturer) using MSK, the TSF and card stay still in Prepersonalisation state. FMT_MSA.3/PP This SFR is implemented by the following TSF: o SF_MANUFACTURER_AUTHENTICATION: This TSF implements Access control policy in preperso phase. o SF_PREPERSONALISATION: This TSF, once authenticated, implements prepersonalisations operations. FCS_COP.1/PP At prepersonalisation phase, authentication cryptogram (signature computation and verification) are used by SF_MANUFACTURER_AUTHENTICATION. Data decryption (of patch, locks or keys), integrity pattern verification (signature/MAC) are used by SF_PREPERSONALISATION. These functions call Cryptographic ones defined in previous FCS_COP operation SF_MANUFACTURER_AUTHENTICATION: This TSF implements Access control policy in preperso phase. FCS_CKM.4/PP This SFR is implemented by the following TSF: o SF_KEY_DESTRUCTION: As soon as the Card Manager status is set to OP_READY, the MSK and LSK key is set to null (as the checksum is also to null) the key is not useful. The MSK after the first use is diversified, according to AGD_PRE [R39]. The new version of the key replaces the previous one. FTP_ITC.1/PP This SFR is implemented by the following TSF: o SF_PREPERSONALISATION: The TOE developer shall be authenticated prior to any data loading, patch or locks or ISK, in the TOE in personalisation. For the patch or locks loading, the TOE developer is authenticated thanks to the signature ID-ONE COSMO V8.2 Public Security Target 185 | 202 computed with the LSK, which is affixed to the data sent to the TOE. For the ISK loading, the TOE developer is authenticated with the MSK. FDP_UIT.1/PP The SFR is implemented by the following TSF: o SF_PREPERSONALISATION: The data (patch or locks) sent to the TOE are protected in integrity thanks to a signature computed by the TOE developer with the LSK (PUT KEY command). The ISK is loaded ciphered with the MSK, and requires an authentication with the MSK. FCS_CKM.1/PP The SFR is implemented by the following TSF: o SF_PREPERSONALISATION: During first command, the individual MSK of the TOE is generated from the master MSK. FAU_STG.2 The SFR is implemented by the following TSF: o SF_PREPERSONALISATION: Upon request, the identification of the patch is returned. Additional Security Functional Requirements for SmartCard Platform FPT_PHP.3/SCP When executing, SF_HARDWARE_OPERATING shall resist changing operational conditions every times, external hardware event can be trigged to prevent attacks or bad use. Temperature, frequency, voltage, light, glitch are considered as abnormal environmental conditions and put the card in frozen state. FPT_FLS.1/SCP When failures occur detected by SF_DATA_INTEGRITY, SF_DATA_COHERENCY and SF_MEMORY_FAILURE, the TOE sends a specific exception status or doesn't start SF_EXCEPTION FPT_RCV.3/SCP This requirement is fulfilled by two security functions: SF_MEMORY_FAILURE and SF_DATA_COHERENCY. In case of a bad writing, internal mechanisms are implemented to prevent an incoherency of the written data. The TSF have the capacity to determine if the objects were capable of being recovered. In case of an impossible writing, an exception is raised. FPT_RCV.4/SCP The TSF SF_DATA_COHERENCY shall ensure that reading from and writing to static and objects' fields interrupted by power loss have the property that the function either completes successfully, or for the indicated failure scenarios, recovers to a consistent and secure state. FRU_FLT.1/SCP When there is a lack of EEPROM, in case of bad in case of a bad writing, the SF_MEMORY_FAILURE implements internal mechanisms to prevent an incoherency of the written data. In case of an impossible writing, an exception is raised. FPR_UNO.1/USE_KEY This SFR is implemented by the following TSF: o SF_UNOBSERVABILITY: No user are able to observe keys whether the keys are in use. ID-ONE COSMO V8.2 Public Security Target 186 | 202 FCS_RNG.1/SCP This SFR is implemented by the following TSF: o SF_SECURITY_FUNCTIONS_OF_THE_IC: This TSF ensures that the security functionalities from the chip are provided to the software, and in particular RNG based on AIS31. o SF_RANDOM_NUMBER: This TSF is in charge of providing random numbers. Additional Security Functional Requirements for the applets FIA_AFL.1/PIN This SFR is implemented by the following TSF: o SF_CARDHOLDER_VERIFICATION: The TSF detects that the number of PIN presentations exceeds the maximum value previously configured. It blocks the PIN in this case. The entire OwnerPin class in involved in the process since it is used to set the PIN size and the maximum of successful tries, to verify the PIN, to reset the validation flag. FMT_MTD.2/GP_PIN This SFR is implemented by the following TSF: o SF_CARDHOLDER_VERIFICATION: The TOE ensures that the GlobalPin is blocked when its associated PIN try counter at reach the PIN try limit value. FPR_UNO.1/Applet This SFR is implemented by the following SFR: o SF_UNOBSERVABILITY: Unobservability of Comparison on two byte arrays is a service provided to the applet. FMT_MTD.1/PIN The SFR is implemented by the following TSF: o SF_CARDHOLDER_VERIFICATION provides a complete PIN mechanism: change_default, query and modify to applets. FIA_AFL.1/GP_PIN This SFR is implemented by the following TSF: o SF_CARDHOLDER_VERIFICATION: The TOE checks that only the Card Manager and privileged application can change the pin try limit and Update the global Pin. Additional Security Functional Requirements for BIO FIA_AFL.1/PIN_BIO This SFR is implemented by the following TSF: o SF_CARDHOLDER_VERIFICATION: The TSF detects that the number of PIN_BIO presentations using the MOC algorithm exceeds the maximum value previously configured. It blocks the PIN_BIO in this case. Additional Security Functional Requirements for Runtime Verification FDP_ACC.2/RV_Stack This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: The Firewall mechanism possesses additional security rules which guarantee the protection of the Stack. FDP_ACF.1/RV_Stack This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: The Firewall mechanism possesses additional security rules which guarantee the protection of the Stack. ID-ONE COSMO V8.2 Public Security Target 187 | 202 FMT_MSA.1/RV_Stack This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: This TSF implements additional operations performed by the firewall mechanism over the Stack. FMT_MSA.2/RV_Stack This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: This TSF implements additional operations performed by the firewall mechanism over the Stack. FMT_MSA.3/RV_Stack This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: This TSF implements additional operations performed by the firewall mechanism over the Stack. FMT_SMF.1/RV_Stack This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: The TSF directly controls the Stack and is able to change the associated parameter. FDP_ACC.2/RV_Heap This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: The Firewall mechanism possesses additional security rules which guarantee the protection of the Heap. FDP_ACF.1/RV_Heap This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: The Firewall mechanism possesses additional security rules which guarantee the protection of the Heap. FMT_MSA.1/RV_Heap This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: This TSF implements additional operations performed by the firewall mechanism over the Heap. FMT_MSA.2/RV_Heap This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: This TSF implements additional operations performed by the firewall mechanism over the Heap. FMT_MSA.3/RV_Heap This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: This TSF implements additional operations performed by the firewall mechanism over the Heap. FMT_SMF.1/RV_Heap This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: The TSF directly controls the Heap and is able to change the associated parameter. FDP_ACC.2/RV_Transient This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: The Firewall mechanism possesses additional security rules which guarantee the protection of Transient objects. FDP_ACF.1/RV_Transient This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: The Firewall mechanism possesses additional security rules which guarantee the protection of Transient objects. ID-ONE COSMO V8.2 Public Security Target 188 | 202 FMT_MSA.1/RV_Transient This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: This TSF implements additional operations performed by the firewall mechanism over the Transient. FMT_MSA.2/RV_Transient This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: This TSF implements additional operations performed by the firewall mechanism over the Transient. FMT_MSA.3/RV_Transient This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: This TSF implements additional operations performed by the firewall mechanism over the Transient. FMT_SMF.1/RV_Transient This SFR is implemented by the following TSF: o SF_RUNTIME_VERIFIER: The TSF directly controls the Transient and is able to change the associated parameter. ID-ONE COSMO V8.2 Public Security Target 189 | 202 10.2.2 Association tables of SFRs and TSS Security Functional Requirements TOE Summary Specification FDP_ACC.2/FIREWALL SF_FIREWALL FDP_ACF.1/FIREWALL SF_FIREWALL FDP_IFC.1/JCVM SF_FIREWALL FDP_IFF.1/JCVM SF_FIREWALL FDP_RIP.1/OBJECTS SF_CLEARING_OF_SENSITIVE_INFORMATION FMT_MSA.1/JCRE SF_FIREWALL FMT_MSA.1/JCVM SF_FIREWALL FMT_MSA.2/FIREWALL_JCVM SF_FIREWALL FMT_MSA.3/FIREWALL SF_FIREWALL FMT_MSA.3/JCVM SF_FIREWALL FMT_SMF.1 SF_CARD_CONTENT_MANAGEMENT FMT_SMR.1 SF_FIREWALL FCS_CKM.1 SF_KEY_GENERATION FCS_CKM.2 SF_KEY_DISTRIBUTION FCS_CKM.3 SF_KEY_ACCESS FCS_CKM.4 SF_KEY_DESTRUCTION FCS_COP.1 SF_KEY_AGREEMENT, SF_MESSAGE_DIGEST, SF_ENCRYPTION_AND_DECRYPTION, SF_SIGNATURE ID-ONE COSMO V8.2 Public Security Target 190 | 202 Security Functional Requirements TOE Summary Specification FDP_RIP.1/ABORT SF_CLEARING_OF_SENSITIVE_INFORMATION, SF_ATOMIC_TRANSACTION FDP_RIP.1/APDU SF_CLEARING_OF_SENSITIVE_INFORMATION FDP_RIP.1/bArray SF_CLEARING_OF_SENSITIVE_INFORMATION FDP_RIP.1/KEYS SF_CLEARING_OF_SENSITIVE_INFORMATION FDP_RIP.1/TRANSIENT SF_CLEARING_OF_SENSITIVE_INFORMATION FDP_ROL.1/FIREWALL SF_ATOMIC_TRANSACTION FAU_ARP.1 SF_FIREWALL FDP_SDI.2 SF_DATA_INTEGRITY FPR_UNO.1 SF_DATA_INTEGRITY FPT_FLS.1 SF_FIREWALL, SF_ATOMIC_TRANSACTION, SF_CARD_CONTENT_MANAGEMENT FPT_TDC.1 SF_CARD_MANAGEMENT_ENVIRONMENT FIA_ATD.1/AID SF_CARD_CONTENT_MANAGEMENT FIA_UID.2/AID SF_FIREWALL FIA_USB.1/AID SF_FIREWALL FMT_MTD.1/JCRE SF_CARD_CONTENT_MANAGEMENT FMT_MTD.3/JCRE SF_CARD_CONTENT_MANAGEMENT FDP_ITC.2/Installer SF_CARD_CONTENT_MANAGEMENT FMT_SMR.1/Installer SF_CARD_CONTENT_MANAGEMENT FPT_FLS.1/Installer SF_CARD_CONTENT_MANAGEMENT, SF_ATOMIC_TRANSACTION FPT_RCV.3/Installer SF_CARD_CONTENT_MANAGEMENT, SF_ATOMIC_TRANSACTION ID-ONE COSMO V8.2 Public Security Target 191 | 202 Security Functional Requirements TOE Summary Specification FDP_ACC.2/ADEL SF_CARD_CONTENT_MANAGEMENT FDP_ACF.1/ADEL SF_CARD_CONTENT_MANAGEMENT FDP_RIP.1/ADEL SF_CLEARING_OF_SENSITIVE_INFORMATION FMT_MSA.1/ADEL SF_CARD_MANAGEMENT_ENVIRONMENT FMT_MSA.3/ADEL SF_CARD_CONTENT_MANAGEMENT FMT_SMF.1/ADEL SF_CARD_MANAGEMENT_ENVIRONMENT FMT_SMR.1/ADEL SF_CARD_MANAGEMENT_ENVIRONMENT FPT_FLS.1/ADEL SF_CLEARING_OF_SENSITIVE_INFORMATION, SF_ATOMIC_TRANSACTION FMT_MTD.1/PIN_BIO SF_CARDHOLDER_VERIFICATION FDP_RIP.1/ODEL SF_CLEARING_OF_SENSITIVE_INFORMATION FPT_FLS.1/ODEL SF_CLEARING_OF_SENSITIVE_INFORMATION FCO_NRO.2/CM SF_CARD_CONTENT_MANAGEMENT FDP_IFC.2/CM SF_CARD_CONTENT_MANAGEMENT, SF_DAP_VERIFICATION FDP_IFF.1/CM SF_DAP_VERIFICATION FDP_UIT.1/CM SF_DAP_VERIFICATION, SF_ENCRYPTION_AND_DECRYPTION FIA_UID.1/CM SF_GP_DISPATCHER FMT_MSA.1/CM SF_CARD_CONTENT_MANAGEMENT, SF_KEY_MANAGEMENT FMT_MSA.3/CM SF_CARD_CONTENT_MANAGEMENT FMT_SMF.1/CM SF_CARD_CONTENT_MANAGEMENT FMT_SMR.1/CM SF_CARD_CONTENT_MANAGEMENT ID-ONE COSMO V8.2 Public Security Target 192 | 202 Security Functional Requirements TOE Summary Specification FTP_ITC.1/CM SF_CARD_CONTENT_MANAGEMENT, SF_DAP_VERIFICATION, SF_GP_DISPATCHER, SF_PREPERSONALISATION FPT_TST.1 SF_HARDWARE_OPERATING, SF_DATA_INTEGRITY FCO_NRO.2/CM_DAP SF_DAP_VERIFICATION FIA_AFL.1/CM SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL FIA_UAU.1/CM SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL, SF_GP_DISPATCHER FIA_UAU.4/CardIssuer SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL, SF_RANDOM_NUMBER FIA_UAU.7/CardIssuer SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL, SF_RANDOM_NUMBER FPR_UNO.1/Key_CM SF_KEY_MANAGEMENT FPT_TDC.1/CM SF_KEY_MANAGEMENT FMT_SMR.2/CM SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL FDP_ACC.2/PP SF_RESIDENT_APPLICATION_DISPATCHER, SF_MANUFACTURER_AUTHENTICATION, SF_PREPERSONALISATION FDP_ACF.1/PP SF_MANUFACTURER_AUTHENTICATION FDP_UCT.1/PP SF_MANUFACTURER_AUTHENTICATION, SF_PREPERSONALISATION FDP_ITC.1/PP SF_MANUFACTURER_AUTHENTICATION, SF_PREPERSONALISATION FIA_AFL.1/PP SF_MANUFACTURER_AUTHENTICATION FIA_UAU.1/PP SF_RESIDENT_APPLICATION_DISPATCHER FIA_UID.1/PP SF_RESIDENT_APPLICATION_DISPATCHER FMT_MSA.1/PP SF_PREPERSONALISATION ID-ONE COSMO V8.2 Public Security Target 193 | 202 Security Functional Requirements TOE Summary Specification FMT_SMF.1/PP SF_PREPERSONALISATION FIA_ATD.1/CardManu SF_MANUFACTURER_AUTHENTICATION FIA_UAU.4/CardManu SF_MANUFACTURER_AUTHENTICATION FIA_UAU.7/CardManu SF_MANUFACTURER_AUTHENTICATION FMT_MOF.1/PP SF_CARD_MANAGEMENT_ENVIRONMENT, SF_PREPERSONALISATION FMT_SMR.2/PP SF_MANUFACTURER_AUTHENTICATION, SF_PREPERSONALISATION FMT_MSA.3/PP SF_MANUFACTURER_AUTHENTICATION, SF_PREPERSONALISATION FCS_COP.1/PP SF_PREPERSONALISATION, SF_MANUFACTURER_AUTHENTICATION FCS_CKM.4/PP SF_KEY_DESTRUCTION, FPT_PHP.3/SCP SF_HARDWARE_OPERATING FPT_FLS.1/SCP SF_MEMORY_FAILURE, SF_EXCEPTION, SF_DATA_INTEGRITY, SF_DATA_COHERENCY FPT_RCV.3/SCP SF_DATA_COHERENCY, SF_MEMORY_FAILURE FPT_RCV.4/SCP SF_DATA_COHERENCY FRU_FLT.1/SCP SF_MEMORY_FAILURE FPR_UNO.1/USE_KEY SF_UNOBSERVABILITY FCS_RNG.1/SCP SF_RANDOM_NUMBER, SF_SECURITY_FUNCTIONS_OF_THE_IC FIA_AFL.1/PIN SF_CARDHOLDER_VERIFICATION FMT_MTD.2/GP_PIN SF_CARDHOLDER_VERIFICATION FPR_UNO.1/Applet SF_UNOBSERVABILITY FMT_MTD.1/PIN SF_CARDHOLDER_VERIFICATION ID-ONE COSMO V8.2 Public Security Target 194 | 202 Security Functional Requirements TOE Summary Specification FIA_AFL.1/GP_PIN SF_CARDHOLDER_VERIFICATION FIA_AFL.1/PIN_BIO SF_CARDHOLDER_VERIFICATION FDP_ACC.2/RV_Stack SF_RUNTIME_VERIFIER FDP_ACF.1/RV_Stack SF_RUNTIME_VERIFIER FMT_MSA.1/RV_Stack SF_RUNTIME_VERIFIER FMT_MSA.2/RV_Stack SF_RUNTIME_VERIFIER FMT_MSA.3/RV_Stack SF_RUNTIME_VERIFIER FMT_SMF.1/RV_Stack SF_RUNTIME_VERIFIER FDP_ACC.2/RV_Heap SF_RUNTIME_VERIFIER FDP_ACF.1/RV_Heap SF_RUNTIME_VERIFIER FMT_MSA.1/RV_Heap SF_RUNTIME_VERIFIER FMT_MSA.2/RV_Heap SF_RUNTIME_VERIFIER FMT_MSA.3/RV_Heap SF_RUNTIME_VERIFIER FMT_SMF.1/RV_Heap SF_RUNTIME_VERIFIER FDP_ACC.2/RV_Transient SF_RUNTIME_VERIFIER FDP_ACF.1/RV_Transient SF_RUNTIME_VERIFIER FMT_MSA.1/RV_Transient SF_RUNTIME_VERIFIER FMT_MSA.2/RV_Transient SF_RUNTIME_VERIFIER FMT_MSA.3/RV_Transient SF_RUNTIME_VERIFIER FMT_SMF.1/RV_Transient SF_RUNTIME_VERIFIER ID-ONE COSMO V8.2 Public Security Target 195 | 202 Security Functional Requirements TOE Summary Specification FAU_STG.2 SF_PREPERSONALISATION FTP_ITC.1/PP SF_PREPERSONALISATION FCS_CKM.1/PP SF_PREPERSONALISATION FDP_UIT.1/PP SF_PREPERSONALISATION FCS_COP.1/CM SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL Table 27: SFRs and TSS – Coverage TOE Summary Specification Security Functional Requirements SF_ATOMIC_TRANSACTION FPT_FLS.1/Installer, FPT_RCV.3/Installer, FPT_FLS.1/ADEL, FDP_RIP.1/ABORT, FDP_ROL.1/FIREWALL, FPT_FLS.1 SF_CARD_CONTENT_MANAGEMENT FDP_ITC.2/Installer, FMT_SMR.1/Installer, FPT_FLS.1/Installer, FPT_RCV.3/Installer, FDP_ACC.2/ADEL, FDP_ACF.1/ADEL, FMT_MSA.3/ADEL, FCO_NRO.2/CM, FDP_IFC.2/CM, FMT_MSA.1/CM, FMT_MSA.3/CM, FMT_SMF.1/CM, FMT_SMR.1/CM, FTP_ITC.1/CM, FMT_SMF.1, FPT_FLS.1, FIA_ATD.1/AID, FMT_MTD.1/JCRE, FMT_MTD.3/JCRE SF_CARD_MANAGEMENT_ENVIRONMENT FMT_MSA.1/ADEL, FMT_SMF.1/ADEL, FMT_SMR.1/ADEL, FPT_TDC.1, FMT_MOF.1/PP SF_CARDHOLDER_VERIFICATION FMT_MTD.1/PIN_BIO, FIA_AFL.1/PIN, FMT_MTD.2/GP_PIN, FMT_MTD.1/PIN, FIA_AFL.1/GP_PIN, FIA_AFL.1/PIN_BIO ID-ONE COSMO V8.2 Public Security Target 196 | 202 TOE Summary Specification Security Functional Requirements SF_CLEARING_OF_SENSITIVE_INFORMATION FDP_RIP.1/ADEL, FPT_FLS.1/ADEL, FDP_RIP.1/ODEL, FPT_FLS.1/ODEL, FDP_RIP.1/OBJECTS, FDP_RIP.1/ABORT, FDP_RIP.1/APDU, FDP_RIP.1/bArray, FDP_RIP.1/KEYS, FDP_RIP.1/TRANSIENT SF_DAP_VERIFICATION FDP_IFC.2/CM, FDP_IFF.1/CM, FDP_UIT.1/CM, FTP_ITC.1/CM, FCO_NRO.2/CM_DAP SF_DATA_COHERENCY FPT_FLS.1/SCP, FPT_RCV.3/SCP, FPT_RCV.4/SCP SF_DATA_INTEGRITY FDP_SDI.2, FPR_UNO.1, FPT_FLS.1/SCP, FPT_TST.1 SF_ENCRYPTION_AND_DECRYPTION FDP_UIT.1/CM, FCS_COP.1 SF_ENTITY_AUTHENTICATION/SECURE_CHANNEL FIA_AFL.1/CM, FIA_UAU.1/CM, FIA_UAU.4/CardIssuer, FIA_UAU.7/CardIssuer, FMT_SMR.2/CM, FCS_COP.1/CM SF_EXCEPTION FPT_FLS.1/SCP SF_FIREWALL FDP_ACC.2/FIREWALL, FDP_ACF.1/FIREWALL, FDP_IFC.1/JCVM, FDP_IFF.1/JCVM, FMT_MSA.1/JCRE, FMT_MSA.1/JCVM, FMT_MSA.2/FIREWALL_JCVM, FMT_MSA.3/FIREWALL, FMT_MSA.3/JCVM, FMT_SMR.1, FAU_ARP.1, FPT_FLS.1, FIA_UID.2/AID, FIA_USB.1/AID SF_GP_DISPATCHER FIA_UID.1/CM, FTP_ITC.1/CM, FIA_UAU.1/CM SF_HARDWARE_OPERATING FPT_TST.1, FPT_PHP.3/SCP SF_KEY_ACCESS FCS_CKM.3 SF_KEY_AGREEMENT FCS_COP.1 SF_KEY_DESTRUCTION FCS_CKM.4, FCS_CKM.4/PP SF_KEY_DISTRIBUTION FCS_CKM.2 SF_KEY_GENERATION FCS_CKM.1 SF_KEY_MANAGEMENT FMT_MSA.1/CM, FPR_UNO.1/Key_CM, FPT_TDC.1/CM ID-ONE COSMO V8.2 Public Security Target 197 | 202 TOE Summary Specification Security Functional Requirements SF_MANUFACTURER_AUTHENTICATION FDP_ACC.2/PP, FDP_ACF.1/PP, FDP_UCT.1/PP, FDP_ITC.1/PP, FIA_AFL.1/PP, FIA_ATD.1/CardManu, FIA_UAU.4/CardManu, FIA_UAU.7/CardManu, FMT_SMR.2/PP, FMT_MSA.3/PP, FCS_COP.1/PP SF_MESSAGE_DIGEST FCS_COP.1 SF_MEMORY_FAILURE FPT_FLS.1/SCP, FPT_RCV.3/SCP, FRU_FLT.1/SCP SF_PREPERSONALISATION FDP_ACC.2/PP, FMT_MSA.1/PP, FMT_SMF.1/PP, FMT_MOF.1/PP, FMT_MSA.3/PP, FCS_COP.1/PP , FTP_ITC.1/CM, FDP_UIT.1/PP, FDP_ITC.1/PP, FCS_CKM.1/PP, tok267FTP_ITC.1/PP, FDP_UCT.1/PP, FAU_STG.2, FMT_SMR.2/PP SF_RANDOM_NUMBER FIA_UAU.4/CardIssuer, FIA_UAU.7/CardIssuer, FCS_RNG.1/SCP SF_RESIDENT_APPLICATION_DISPATCHER FDP_ACC.2/PP, FIA_UAU.1/PP, FIA_UID.1/PP SF_RUNTIME_VERIFIER FDP_ACC.2/RV_Stack, FDP_ACF.1/RV_Stack, FMT_MSA.1/RV_Stack, FMT_MSA.2/RV_Stack, FMT_MSA.3/RV_Stack, FMT_SMF.1/RV_Stack, FDP_ACC.2/RV_Heap, FDP_ACF.1/RV_Heap, FMT_MSA.1/RV_Heap, FMT_MSA.2/RV_Heap, FMT_MSA.3/RV_Heap, FMT_SMF.1/RV_Heap, FDP_ACC.2/RV_Transient, FDP_ACF.1/RV_Transient, FMT_MSA.1/RV_Transient, FMT_MSA.2/RV_Transient, FMT_MSA.3/RV_Transient, FMT_SMF.1/RV_Transient SF_SECURITY_FUNCTIONS_OF_THE_IC FCS_RNG.1/SCP SF_SIGNATURE FCS_COP.1 SF_UNOBSERVABILITY FPR_UNO.1/USE_KEY, FPR_UNO.1/Applet Table 1: TSS and SFRs - Coverage ID-ONE COSMO V8.2 Public Security Target 198 | 202 11 Rationale for the composition with the IC Some sensitive rationales are removed from the Public ST. ID-ONE COSMO V8.2 Public Security Target 199 | 202 12 RELATED DOCUMENTS ID-ONE COSMO V8.2 Public Security Target 200 | 202 Ref Document details [R1] "Common Criteria for information Technology Security Evaluation, Part”1: Introduction and general model", April 2017, Version 3.1 revision 5.“ [R2] "Common Criteria for information Technology Security Evaluation, Par” 2: Security Functional component", April 2017, Version 3.1 revision 5.“ [R3] "Common Criteria for information Technology Security Evaluation, Par” 3: Security Assurance components", April 2017, Version 3.1 revision 5. [R4] “Composite product evaluation for Smart Cards and similar devices” August 2015, Version 1.4, -. [R5] PP SUN Java Card™ System Protection Profile Open Configuration v3.0 May 2012, ANSSI-CC-PP-2010/03_M01 [R6] "Java Card - API" Application Programming Interfaces, Classic Edition Version 3.0.4, May, 2009, Sun Microsystems. [R7] "Java Card – JCRE” Runtime Environment Specification, Classic Edition Version 3.0.4, September, 2011, Sun Microsystems. [R8] "Java Card - Virtual Machine Specifications" Classic Edition, Version 3.0.4 May, 2009, Sun Microsystems. [R9] Global Platform, Card Specification Version 2.2.1 – January 2011. [R10] Global Platform Card, Mapping Guidelines of Existing GP v2.1.1 Implementation on v2.2.1 Version 1.0.1 – January 2011. [R11] Global Platform Card, ID Configuration Version 1.0 - December 2011. [R12] Global Platform Card Technology, Secure Channel Protocol 03, Card Specification v 2.2 - Amendment D Version 1.1 - September 2009. [R13] Global Platform Card Technology, Security Upgrade for Card Content Management, Card Specification v 2.2 – Amendment E Version 0.14 - October 2011. [R14] "Identification cards - Integrated Circuit(s) Cards with contacts, Part 6: Interindustry data elements for interchange" ISO/IEC 7816-6 (2004) [R15] "Digital Signatures using Reversible Public Key Cryptography for the Financial Services Industry (rDSA)" ANSI X9.31-1998, American Bankers Association ID-ONE COSMO V8.2 Public Security Target 201 | 202 [R16] "FIPS PUB 46-3, Data Encryption Standard" October 25, 1999 (ANSI X3.92), National Institute of Standards and Technology [R17] "FIPS PUB 81, DES Modes of Operation" April 17, 1995, National Institute of Standards and Technology [R18] "FIPS PUB 180-3, Secure Hash Standard" October 2008 , National Institute of Standards and Technology [R19] "FIPS PUB 186-3" June 2009, Digital Signature Standard (DSS) [R20] "Public Key Cryptography using RSA for the financial services industry" ISO/IEC 9796-1, annex A, section A.4 and A.5, and annex C (1995) [R21] “Information technology – Security techniques: Data integrity mechanism using a cryptographic check function employing a block cipher algorithm” ISO/IEC 9797-1 (1999) , International Organization for Standardization [R22] “FIPS PUB 140-2, Security requirements for cryptographic modules” Mars 2002 , National Institute of Standards and Technology [R23] PKCS#1 The public Key Cryptography standards RSA Data Security Inc. 1993 [R24] Security IC Platform Protection Profile with Augmentation Packages Version 1.0, 13 January 2014, BSI-CC-PP-0084-2014 [R26] NXP Secure Smart Card Controller P6022y VB 1- Security Target Lite Rev. 2.6 - BSI-DSZ-CC-1059-V3 2- Security Target Lite Rev. 2.1 - BSI-DSZ-CC-1059 [R27] IEEE Std 1363a-2004 Standard Specification of Public-Key Cryptography [R28] FIPS PUB 197, The Advanced Encryption Standard (AES) U.S. DoC/NIST, November 26, 2001. [R29] Certification of « open » smart card products, Version 1.1 (for trial use), 4 February 2013. [R30] The NIST SP 800-90 Recommendation for Random Number Generation Using Deterministic Random Bit Generators (Revise) March 2007 [R31] Référentiel général de sécurité Processus de qualification d’un produit de sécurité - niveau renforcé – version 1.0 ID-ONE COSMO V8.2 Public Security Target 202 | 202 [R33] ANSSI-CC-NOTE-06/2.0 du 23/01/2015 [R34] ANSI x9.62-2005 Public Key Cryptography for the Financial Services Industry – The Elliptic Curve Digital Signature Algorithm (ECDSA) [R35] ANSI x9.63-2001 Public Key Cryptography for the Financial Services Industry – Key Agreement and Key Transport Using Elliptic Curve Cryptography [R36] JIL-Guidance-for-smartcard-evaluation-v2-0 [R37] ID-One Cosmo v8.2 Security Recommendations FQR 110 8963 Ed4 [R38] ID-One Cosmo v8.2 Reference Guide FQR 110 8885 Ed8 [R39] ID-One Cosmo v8.2 Pre-Perso Guide FQR 110 8875 Ed9 [R40] ID-One Cosmo v8.1-N Application Loading Protection Guidance FQR 110 8001 Ed1 [R41] FQR 110 9106 Ed2 - OPTIONAL CODE R1.0 APPLI DESELECTION BEFORE DESFIRE [R42] The Java Virtual Machine Specification. Lindholm, Yellin ISBN 0-201-43294-3 [R43] Java Card 3 Platform Off-card Verification Tool Specification, Classic Edition, Version 1.0. Published by Oracle [R44] Java Card System Standard 2.2 Configuration Protection Profile – PP/0305 Version 1.0b – August 2003 [R45] FQR 110 9340 Ed2 [R46] FQR 110 9410 Ed1-ID-ONE Cosmo V8.2 – Impact Analysis Report