[JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite KOMSCO JK11 Security Target Lite October 6, 2010 IT Research Department [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite This page left blank on purpose for double-side printing. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite [REVISION STATUS] Revision Description of Change Date 1.0 ST v1.3 Summary [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite This page left blank on purpose for double-side printing. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite [List of Contents] 1. SECURITY TARGET INTRODUCTION .............................................................................1 1.1 Security Target Reference........................................................................................................................ 1 1.2 TOE Reference ........................................................................................................................................... 1 1.3 TOE Overview............................................................................................................................................. 2 1.3.1 TOE Product type...................................................................................................................................................................2 1.3.2 TOE Usage ...............................................................................................................................................................................2 1.3.3 Non-TOE hardware/software/firmware required by the TOE...............................................................................3 1.4 TOE Description......................................................................................................................................... 4 1.4.1 TOE Operational Environment..........................................................................................................................................4 1.4.2 Physical Scope of TOE........................................................................................................................................................5 1.4.3 Logical Scope of TOE...........................................................................................................................................................6 1.4.4 TOE Life Cycle ........................................................................................................................................................................8 1.5 Writing Rules .............................................................................................................................................. 9 1.6 Glossary ...................................................................................................................................................... 9 1.7 Security Target constitution ..................................................................................................................13 2. CONFORMANCE CLAIMS................................................................................................14 2.1 CC Conformance Claim ..........................................................................................................................14 2.2 PP Conformance Claim...........................................................................................................................14 2.3 Package Conformance............................................................................................................................14 2.4 Rationale of Conformance Claim ..........................................................................................................15 2.4.1 Rationale of Protection Profile Conformance ...........................................................................................................15 2.4.2 Rationale of Conformance Claim for Security problem definition....................................................................15 2.4.3 Rationale of Conformance Claim for Security objectives....................................................................................15 2.4.4 Rationale of Conformance Claim for Security functional requirements.........................................................15 2.4.5 Rationale of Conformance Claim for Assurance Requirements.......................................................................17 3. SECURITY PROBLEM DEFINITION................................................................................19 [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 3.1 Assets ........................................................................................................................................................19 3.1.1 User Data.................................................................................................................................................................................19 3.1.2 TSF Data..................................................................................................................................................................................20 3.2 Threats.......................................................................................................................................................20 3.3 Organizational security policies............................................................................................................21 3.4 Assumptions.............................................................................................................................................21 4. SECURITY OBJECTIVES .................................................................................................23 4.1 Security objectives for the TOE ............................................................................................................23 4.2 Security objectives for the operational environment........................................................................24 4.3 Security Objectives Rationale ...............................................................................................................24 4.3.1 TOE Security Objectives Rationale ..............................................................................................................................26 4.3.2 Security Objectives Rationale for the operational environment........................................................................28 5. EXTENDED COMPONENTS DEFINITION......................................................................29 5.1 Extended Components Definition.........................................................................................................29 6. SECURITY REQUIREMENTS...........................................................................................30 6.1 Security functional requirements .........................................................................................................31 6.1.1 Security Audit.........................................................................................................................................................................32 6.1.2 Cryptographic Support .......................................................................................................................................................33 6.1.3 User Data Protection...........................................................................................................................................................35 6.1.4 Identification and Authentication....................................................................................................................................42 6.1.5 Security Management.........................................................................................................................................................49 6.1.6 Privacy ......................................................................................................................................................................................53 6.1.7 Protection of the TSF..........................................................................................................................................................53 6.2 Assurance Requirements.......................................................................................................................56 6.2.1 Security Target ......................................................................................................................................................................57 6.2.2 Development ..........................................................................................................................................................................60 6.2.3 Guidance documents..........................................................................................................................................................63 6.2.4 Life-cycle support .................................................................................................................................................................64 6.2.5 Tests ..........................................................................................................................................................................................66 6.2.6 Vulnerability assessment ..................................................................................................................................................68 6.3 Security Requirements Rationale .........................................................................................................69 [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 6.3.1 Security Functional Requirements Rationale ...........................................................................................................69 6.3.2 Assurance Requirements Rationale.............................................................................................................................74 6.4 Dependencies Rationale.........................................................................................................................75 6.4.1 Dependencies of the Security Functional Requirements ....................................................................................75 6.4.2 Dependencies of the Assurance Requirements......................................................................................................76 7. TOE SUMMARY SPECIFICATION...................................................................................77 7.1 TOE Security Functionality ....................................................................................................................77 7.1.1 Security Audit.........................................................................................................................................................................77 7.1.2 Cryptographic Support .......................................................................................................................................................77 7.1.3 User Data Protection...........................................................................................................................................................77 7.1.4 Identification and Authentication....................................................................................................................................77 7.1.5 Security Management.........................................................................................................................................................77 7.1.6 Privacy ......................................................................................................................................................................................78 7.1.7 Protection of the TSF..........................................................................................................................................................78 8. ANNEX.................................................................................................................................79 8.1 References ................................................................................................................................................79 8.2 Abbreviated terms ...................................................................................................................................80 [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite [List of Figures] [FIGURE 1] OPERATIONAL ENVIRONMENT OF TOE..........................................................................................................4 [FIGURE 2] PHYSICAL SCOPE OF TOE......................................................................................................................................5 [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite [List of Tables] [TABLE 1] TOE USAGE AND APPLICATION ............................................................................................................................2 [TABLE 2] IDENTIFICATION OF NON-EVALUATION ELEMENTS.................................................................................3 [TABLE 3] SUPPORT ALGORITHM AND USAGE...................................................................................................................6 [TABLE 4] TOE LIFE CYCLE..............................................................................................................................................................8 [TABLE 5] RATIONALE OF CONFORMANCE CLAIM FOR SECURITY FUNCTIONAL REQUIREMENTS ...............................................................................................................................................................................................................16 [TABLE 6] RATIONALE OF CONFORMANCE CLAIM FOR ASSURANCE REQUIREMENTS ........................17 [TABLE 7] RELATION BETWEEN SECURITY OBJECTIVES AND THE SECURITY PROBLEM DEFINITION.....................................................................................................................................................................................24 [TABLE 8] SUBJECT AND OBJECT, RELATED SECURITY ATTRIBUTE, OPERATION DEFINITION ......30 [TABLE 9] SECURITY FUNCTIONAL REQUIREMENTS....................................................................................................31 [TABLE 10] SECURITY VIOLATION EVENTS .........................................................................................................................32 [TABLE 11] CRYPTOGRAPHIC ALGORITHM OF HARDWARE AND CRYPTO LIBRARY...............................35 [TABLE 12] LIST OF SUBJECTS AND OBJECTS.................................................................................................................36 [TABLE 13] LIST OF OPERATION.................................................................................................................................................36 [TABLE 14] LIST OF SUBJECTS AND OBJECTS.................................................................................................................36 [TABLE 15] LIST OF OPERATION.................................................................................................................................................36 [TABLE 16] SECURITY ATTRIBUTE OF SUBJECT AND OBJECT..............................................................................37 [TABLE 17] VALUES OF SECURITY ATTRIBUTE ................................................................................................................37 [TABLE 18] SECURITY ATTRIBUTE BASED ACCESS CONTROL RULES.............................................................38 [TABLE 19] SECURITY ATTRIBUTE OF SUBJECT AND OBJECT..............................................................................39 [TABLE 20] VALUES OF SECURITY ATTRIBUTE ................................................................................................................39 [TABLE 21] SECURITY ATTRIBUTE BASED ACCESS CONTROL RULES.............................................................40 [TABLE 22] LIST OF OBJECTS......................................................................................................................................................41 [TABLE 23] DATA INTEGRITY MONITORING AND ACTION ..........................................................................................42 [TABLE 24] LIST OF AUTHENTICATION EVENTS...............................................................................................................43 [TABLE 25] LIST OF ACTIONS .......................................................................................................................................................43 [TABLE 26] LIST OF USER SECURITY ATTRIBUTES........................................................................................................43 [TABLE 27] LIST OF USER SECURITY ATTRIBUTES........................................................................................................44 [TABLE 28] LIST OF VERIFICATION OF SECRETS.............................................................................................................44 [TABLE 29] LIST OF TSF MEDIATED ACTION.......................................................................................................................45 [TABLE 30] SCP02 AUTHENTICATION......................................................................................................................................45 [TABLE 31] LIST OF TSF MEDIATED ACTION.......................................................................................................................45 [TABLE 32] DAP AUTHENTICATION...........................................................................................................................................46 [TABLE 33] LIST OF TSF MEDIATED ACTION.......................................................................................................................46 [TABLE 34] DM AUTHENTICATION .............................................................................................................................................46 [TABLE 35] LIST OF TSF MEDIATED ACTION.......................................................................................................................47 [TABLE 36] LIST OF AUTHENTICATION MECHANISM.....................................................................................................47 [TABLE 37] CONDITION OF RE-AUTHENTICATING...........................................................................................................48 [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite [TABLE 38] LIST OF TSF MEDIATED ACTION.......................................................................................................................48 [TABLE 39] SECURITY ATTRIBUTES OF USER-SUBJECT............................................................................................49 [TABLE 40] LIST OF SECURITY FUNCTIONS ........................................................................................................................50 [TABLE 41] LIST OF TSF DATA.....................................................................................................................................................51 [TABLE 42] LIST OF LIMITS FOR TSF DATA..........................................................................................................................51 [TABLE 43] LIST OF SECURITY MANAGEMENT FUNCTION OF TSF.......................................................................52 [TABLE 44] LIST OF SECURITY ROLES ...................................................................................................................................52 [TABLE 45] LIST OF FAILURES/SERVICE DISCONTINUITIES......................................................................................54 [TABLE 46] LIST OF FAILURES/SERVICE DISCONTINUITIES......................................................................................54 [TABLE 47] LIST OF SELF TESTS................................................................................................................................................55 [TABLE 48] ASSURANCE REQUIREMENTS...........................................................................................................................56 [TABLE 49] MAPPING OF SECURITY FUNCTIONAL REQUIREMENTS AND SECURITY OBJECTIVES.69 [TABLE 50] DEPENDENCIES OF THE FUNCTIONAL COMPONENTS ......................................................................75 [TABLE 51] DEPENDENCIES OF THE ADDED ASSURANCE REQUIREMENTS .................................................76 [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 1/80 1. Security Target Introduction This document is the Security Target (shortly, ST) of KOMSCO JK11 product developed by the KOMSCO (Korea Minting, Security Printing & ID Card Operating Corporation). The assurance level of the Security Target is EAL4+. This section provides the label and description to control and identify the ST and the TOE that the ST refers to, brief description of the structure of document. And this section briefly describes the TOE usage and primary security features. 1.1 Security Target Reference The followings are the identification of this ST. Title JK11 Security Target Version V1.3 Evaluation criteria Korea IT Security Evaluation and Certification Scheme (Ministry of Public Administration and Security Public Notice No. 2009-52) CC version v3.1r3 Date 2010-08-06 Evaluation assurance level EAL4+(ATE_DPT.2, AVA_VAN.4) Author KOMSCO Technology Research Institute IT Research Department keyword SmartCard, JavaCard, IC Chip, SmartCard Terminal, Open Platform COS 1.2 TOE Reference The followings are the identification of TOE in this ST. Developer KOMSCO Technology Research Institute IT Research Department TOE Name KOMSCO JK11 TOE Version R02 TOE Identifier JK11-100C-R02 JK11-150C-R02 Note: The followings are the IC Chip that the TOE has been embedded on. • S3CC9GC/S3CC9LC, Samsung Electronics Co., Ltd. (non-TOE hardware) • 150C (S3CC9LC), 100C (S3CC9GC) [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 2/80 1.3 TOE Overview This section identifies TOE types. It also describes the uses and key security characteristics of TOE and identifies major hardware, software and firmware that are required by TOE but do not constitute TOE. TOE is a Java Card platform as an open card operating system. 1.3.1 TOE Product type TOE is a Java Card platform as an open card operating system developed by KOMSCO, which is used in S3CC9GC, a CC EAL4+-certified smart card IC chip from Samsung Electronics, and S3CC9LC, a CC EAL5+-certified smart card IC chip from Samsung Electronics. This security target defines security function and warranty requirements for open card operating system—excluding the IC chip as part of TOE’s sub-hardware—and the interface between the open card operating system and applications to be used there. The interface between the open card operating system and applications used consists of JCAPIs 2.2.2 of Java Card Platform V2.2.2 and VGI APIs 2.1.1 of Visa Global Platform V2.2.1. 1.3.2 TOE Usage TOE can run all Java applets developed in accordance with the JavaCard v2.2.2 standard. The applets run on the TOE include: public ID card applications such as electronic resident registration card application; financial applications (e.g. cash/credit, electronic wallet, e-commerce); and electronic signature applications (e.g. digital signature). Applications available on the TOE and their uses are outlined in [Table 1]. [Table 1] TOE Usage and Application Application Type Usage Transaction Type ID Electronic resident registration card IC chip-embedded smart card-type electronic resident registration card that is used to address the weaknesses of conventional resident registration card in the prevention of falsification and privacy protection (The chip contains private authentication certificate for online banking, PIN, health insurance and disability/elderly information) Identification Driver’s license IC chip-embedded smart card-type electronic driver’s license that is used to better prevent falsification and improve online utilization Identification Finance & Payment Cash card Designed for direct deposit/withdrawal of bank savings using private information and bank account information saved in the TOE at ATMs or other facilities Deposit & withdrawal of savings Credit card Credit card merchants access the main computer of the credit card company online via the credit authorization terminal (CAT) to check a credit card’s credit limit and validity and permit post-payment. Bank CDs are designed to read credit card information, check the status of the credit card owners’ bank accounts and pay cash. Payment Electronic wallet A certain level of value is saved in a semiconductor (IC) chip electronically to make payments in the same way as in cash. Unlike in the case of a pre-paid card, a certain amount of money can be redeposited to the bank and be used repeatedly. Payment [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 3/80 E-commerce Designed to trade products on a real-time basis via stores open on the Internet Payment Electronic Signature Digital signature Used as a sort of electronic signature in the open key cryptographic format (i.e. asymmetric cryptographic system); electronic data attached to or logically combined with data messages that are used to identify signers and represent their authorization on the content of data messages Identification, prevention of document falsification & denial Public Transport Card Public transport card Designed to read basic user information (i.e. the first six digits of the number displayed on the resident registration card) via the public transport terminal or other devices and exempt people with disabilities and senior citizens from public transport fares (gate opening/closing) Payment 1.3.3 Non-TOE hardware/software/firmware required by the TOE TOE is software installed in the IC chip. The IC chip as its sub-hardware and the crypto library that supports cryptographic computation are excluded from the TOE. Applets installed at the issuance phase are excluded from the TOE. • IC Chip • Cryptographic libary • Appplet Non-evaluation elements in TOE configuration are illustrated in [Table 2.] [Table 2] Identification of non-evaluation elements Non-evaluation elements Description IC chip Used here are the smart card IC (S3CC9GC) evaluated as equal to the currently evaluated TOE (CC EAL4+) and the smart card IC (S3CC9LC) evaluated as better than the currently evaluated (CC EAL5+) TOE. The chips used in the TOE are S3CC9GC and S3CC9LC from Samsung Electronics. The S3CC9GC chip has separately been authorized for the functions of ADV_IMP.2, ALC_DVS.2, AVA_MSU.2 and AVA_VLA.4. Crypto library The crypto libraries used in the TOE are: TORNADOTM developed by the chip’s manufacturer, Samsung Electronics; and RSA Cryptographic Library and ECC Cryptographic Library using Samsung TORNADO cryptographic co-processor. The libraries are applied to different chips as below: S3CC9GC: TORNADOTM RSA secure crypto library v3.5S S3CC9LC: TORNADOTM RSA secure crypto library v3.7S TORNADO2 ECC Cryptographic Library v2.4s AIS20 compliant random number generation library Applet Applets are applications installed in EEPROM of sub-hardware where the TOE is embedded to use TOE resources and run through the TOE. Applets that can be installed in the TOE are Java Applet execution files compatible with the JavaCard v2.2.2 standard. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 4/80 Note: The SCC9GC chip supports the SEED cryptographic coprocessor with 128 bits but is excluded from [R15], so it is not specified in this security target. The SCC9GC chip supports AES cryptographic coprocessor with the key sizes of 128 bits, 192 bits and 256 bits, but it excludes AES from the TOE and is thus not specified in this security target. 1.4 TOE Description 1.4.1 TOE Operational Environment [Figure 1] visualizes the relationship between the TOE and the service system (i.e. terminal and servers), briefly illustrating the hierarchy and TOE scope of a multi-functional smart card. A smart card exchanges information needed for the service system (i.e. terminal and servers) via R/W. As shown in [Figure 1], the IC hardware (i.e. micro-controller), crypto library and application layers of a TOE-embedded smart card are excluded from TOE evaluation elements; test software implemented on ROM for testing hardware functions is also excluded from TOE evaluation elements. Therefore, software embedded in the nonvolatile memory of the smart card alone is subject to CC authentication, while the TOE uses IC security countermeasures to carry out its own functions. In other words, TOE is a Java Card platform that includes smart card operating system, implementation environment and management program while excluding the IC chip and TOE applications installed. Smart card owners and issuers generally undertake tasks through communication with the smart card terminal. The issuers carry out administrative tasks such as application installation, issuance and repair using the issuance system and the smart card terminal; the owners use smart card functions using the terminal. Here the smart card terminal and operational servers constitute the TOE operational environment. [Figure 1] Operational Environment of TOE [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] 1.4.2 Physical Scope of TOE is software that constitutes the developed by KOMSCO, which is used in from Samsung Electronics, and Samsung Electronics. The physical scope of TOE is soft platform as an open card operating system TOE is converted into a binary image, masked in the ROM area of an IC chip and run with EEPROM and RAM data. The physical s and “preparative procedures” that are distributed to end users in the form of electronic document (i.e. CD format) to ensure safe TOE operation. [Figure Software that constitutes the physical scope of TOE, a Java Card platform as an open card operating system, is comprised conceptually of the following six parts: • Card Manager (CM) • Java Card Runtime Environment (JCRE) • Java Card Virtual Machine • Java Card Application Programming Interface • Visa Global Platform Application Programming Interface • Chip Operating System ( Management) For the safe management of TOE, the user manual is offered to the end user in the form of (booklet and) electronic document (i.e. CD format). The user manual distributed to the end user is also included in the physical scope of TOE and is identified as follows: • [JK11-MA-0005] Operational user guidance • [JK11-MA-0006] Preparative procedures Security Target Security Target Security Target Security Target 5/80 Physical Scope of TOE software that constitutes the Java Card platform, an open card operating system developed by KOMSCO, which is used in S3CC9GC, a CC EAL4+-certified smart card IC chip from Samsung Electronics, and S3CC9LC, a CC EAL5+-certified smart card IC chip from The physical scope of TOE is software that constitutes the an open card operating system; compiled with the non-TOE software of TOE is converted into a binary image, masked in the ROM area of an IC chip and run with EEPROM and RAM data. The physical scope of TOE also includes “operational user guidance that are distributed to end users in the form of electronic document (i.e. CD format) to ensure safe TOE operation. Figure 2] Physical Scope of TOE Software that constitutes the physical scope of TOE, a Java Card platform as an open card operating system, is comprised conceptually of the following six parts: Java Card Runtime Environment (JCRE) 2.2.2 Java Card Virtual Machine (JCVM) 2.2.2 Java Card Application Programming Interfaces (JCAPIs) 2.2.2 Global Platform Application Programming Interfaces (VGP APIs) 2.1.1 Operating System (Chip OS): Crypto Function, Kernel and HA management of TOE, the user manual is offered to the end user in the form of (booklet and) electronic document (i.e. CD format). The user manual distributed to the end user is also included in the physical scope of TOE and is identified as follows: Operational user guidance -v1.3 Preparative procedures -v1.2 Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite an open card operating system certified smart card IC chip certified smart card IC chip from ware that constitutes the Java Card TOE software of crypto library, TOE is converted into a binary image, masked in the ROM area of an IC chip and run with operational user guidance” that are distributed to end users in the form of electronic document Software that constitutes the physical scope of TOE, a Java Card platform as an open card VGP APIs) 2.1.1 HAL (I/O, Memory management of TOE, the user manual is offered to the end user in the form of (booklet and) electronic document (i.e. CD format). The user manual distributed to the end user is [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 6/80 Note: The IC Chip that the TOE has been embedded on is not included in the physical scope of TOE. And TOE does not include the application although it is possible that load the application on the EEPROM of IC Chip. That is out of scope in the ST. 1.4.3 Logical Scope of TOE TOE is the JavaCard Platform that supports the analysis of security violation, the cryptographic operation, the access Control, the identification and authentication, the security management and TSF protection function. TOE is composed of the following logical scope that described in “Smart Card Open Platform Protection Profile V2.1, 2010. 6. 10 Korea Internet & Security Agency.”  Analysis of security violation  Cryptographic operation  Access Control  Identification and Authentication  Security Management  TSF protection 1.4.3.1 Analysis of security violation TOE responds to security violation events such as the check sum values of internal data, errors in resource allocation and authentication failure events by detecting security violation events, suspending card functions and deleting memory data. TOE detects violations against the check sum values of the internal major system structure (CRC32) and the check sum values of the package CAP file (CRC32) to shut down card functions. Security exceptions that take place during JCVM operation due to resource allocation errors or other factors are allocated to dedicated counters, suspending the functions of applets if they exceed the maximum values. In the event of any failure on the TOE-supported authentication protocol, the TOE is reset by force and the memory areas of relevant TSF data are deleted to prevent any reuse of resources. 1.4.3.2 Cryptographic operation TOE performs cryptographic computation such as cryptographic key generation/destruction, encryption, decryption, and electronic signature generation and verification. It also supports hash value generation and random number generation. TOE provides these functions for applications through the interface of JCAPI 2.2.2. Below is a list of algorithms supported by the TOE: [Table 3] Support algorithm and usage Algorithm Usage TDES (112, 168 bits) in ECB/CBC mode Data Encryption/Decryption, Generation and Verification of signature (S3CC9GC/LC: provided in IC hardware) RSA (1024, 2048 bits) Data Encryption/Decryption, Generation and Verification of signature (S3CC9GC/LC: provided in IC hardware and Cryptographic library) ECC (192, 224, 256 bits) Generation and Verification of signature (S3CC9GC: not supported S3CC9LC: provided in IC hardware and Cryptographic library) [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 7/80 ECDH (192, 224, 256 bits) Key agreement protocol (S3CC9GC: not supported S3CC9LC: provided in IC hardware and Cryptographic library) SEED (128 bits) in ECB/CBC mode Data Encryption/Decryption (S3CC9GC/LC: provided in software) ARIA (128, 192, 256 bits) in ECB/CBC mode Data Encryption/Decryption (S3CC9GC/LC: provided in software) CRC32 Integrity of TSF execution code stored in ROM of IC SHA-1, SHA-224/256 Generation of signature-creation Hash Note: Hardware-oriented countermeasures that ensure one cannot obtain cryptographic information by abusing physical phenomena (e.g. change in current, voltage and electromagnetism) during cryptographic computation are excluded here as they do not fall into the TOE’s scope. 1.4.3.3 Access Control TOE provides firewall access control through JCRE. By isolating a single applet within the given space through the mechanism of firewall between applets, it prevents data from being leaked out by other applets and provides protection against hacking. 1.4.3.4 Identification and Authentication TOE provides initialization authentication in the administrator mode and SCP02 authentication, DAP authentication and DM authentication in the user mode. Through initialization authentication in the administrator mode, it confirms the administrator is authorized and initializes the TOE. When working together with an external system, the TOE performs SCP02 authentication to identify and authenticate the external system’s nodes for the mutual safety of paths and channels, checking if the card issuer is an authorized one and guaranteeing channel safety. Through secure channels, it ensures the integrity of messages and their confidentiality through message encryption. TSF data areas used upon the termination of authentication protocol are deleted and the security level initialized to ensure relevant information will not be reused. For applets requiring further improvement, the TOE verifies the integrity of applets and authorizes application providers through DAP authentication based on the open keys of authorized application providers. When the issuer seeks to transfer the issuance authority to a second issuer, TOE carries out DM authentication where the commissioned issuer delivers information on given applets to the issuer and receives tokens for these applets before submitting them to the TOE and obtaining the issuance authority. This commissioned issuer issues cards and delivers them to users through SCP02 authentication or DAP authentication. 1.4.3.5 Security Management TOE manages issues relating to security functions, security attributes, TSF data and security roles. Through Card Manager, it compels the security policies of card issuers and provides security service by managing card/application lifecycles, managing security channels for protecting data transmission and data access, and managing PINs for authenticating card owners. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 8/80 1.4.3.6 Other TSF Protection TOE performs internal tests to verify the integrity of TSF data and execution codes and provides the function of recovery to the safe state upon failure. Every time it is started, the TOE makes the internal tests of verifying the check sum values of patch codes and tables injected upon initialization and shutting down card functions if the values are inconsistent. When selecting applets, it verifies the integrity of applet execution codes and shuts down card functions to keep them secure against external attacks or failures. For recovery to the safe state upon failure, the TOE first verifies the check sum values of major TSF data and execution codes to suspend card functions in the event of any security violation and prevent resulting failures fundamentally. It also guarantees atomicity and transactions for Java objects within the TOE. If the installation of any applet or package is abnormally cancelled or suspended, all the resources allocated are recovered and relevant memories are recovered to the prior safe state. Through the anti-tearing mechanism, the TOE restores data to previous values and securely protects saved data when power is lost abnormally. TOE also encrypts major TSF data (e.g. key and PIN) and verifies their integrity through CRC32 to protect them securely from external exposure or modification. 1.4.4 TOE Life Cycle The lifecycle of the TOE is illustrated in [Table 4]. [Table 4] TOE Life Cycle Phase Administrator Description Remarks Development Developer TOE design & development Necessary standards may be designed in the “initialization & issuance” phase Manufacturing Manufacturer IC chip design/development Masking of the designed TOE on ROM IC chip manufacturing IC chip package IC card manufacturing (IC chip package embedded in the card) IC chip design/development, masking and IC chip manufacturing are done by a single manufacturer, while IC chip package and IC card manufacturing may be conducted by different manufacturers Initialization & issuance Developer or issuer Initialization Card issuance Application installation & issuance The developer is involved in Initialization but not in the subsequent phases; if the issuer wants, however, the authority for Initialization can also be transferred to the issuer through security document Usage Owner After card issuance, the owner uses the card normally in line with intended purpose Necessary standards may be designed in the “initialization & issuance” phase Issuer Application installation & issuance [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 9/80 Termination of usage Issuer After the owner’s termination of card use, the issuer discontinues the use of the card or collects it for disposal In the TOE, developers are directly involved from Development through Initialization & Issuance. Among the internal phases, , , which are the areas of manufacturers alone are not directly correlated with the TOE. After Development is completed, developers should distribute the TOE to manufacturers for ROM Masking. TOE becomes a product after being initialized by data generated by developers in Phase or , and becomes available for issuers or for users via issuers. 1.5 Writing Rules The notation, formatting and conventions used in this ST are consistent with the Common Criteria for Information Technology Security Evaluation (hereafter referred to as “CC”). In addition to this, additional writing rules are defined and used to prevent any confusion with operations that are already performed in the Protection Profile conformed to by this security target. The Common Criteria allows selection, assignment, refinement, and iteration operations which can be executed in the Security Functional requirement. Each operation is used in the ST by the following type. Iteration This is used when a component is repeated with varying operations. The result of iteration operation is represented by iteration number with round bracketed, that is, (Iteration number). Assignment This is used to assign specific values to unspecified parameters (e.g., password length). The result of an assignment is represented by square brackets, that is, [Assignment Value]. Selection This is used to select one or more options provided by the CC in stating a requirement. The result of selection operation is represented by underlined italics. Refinement This is used that a requirement to be “stricter” than the original by adding detail to a requirement. It therefore restricts a requirement further. The result of a refinement is represented by bold text. 1.6 Glossary The terms used in the Security Target follow those of the Common Criteria in case they are same. Development environment Environment in which the TOE is developed Object A passive entity in the TOE, that contains or receives information, and upon which subjects perform operations Attack potential [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 10/80 Measure of the effort to be expended in attacking a TOE, expressed in terms of an attacker's expertise, resources and motivation Iteration Use of the same component to express two or more distinct requirements Security objective Statement of intent to counter identified threats and/or satisfy identified organisation security policies and/or assumptions ST, Security Target Implementation-dependent statement of security needs for a specific identified TOE ST Evaluation Assessment of an ST against defined criteria Security attribute Property of subjects, users (including external IT products), objects, information, sessions and/or resources that is used in defining the SFRs and whose values are used in enforcing the SFRs Assurance Grounds for confidence that a TOE meets the SFRs PP, Protection Profile Implementation-independent statement of security needs for a TOE type User See "External Entity” Selection Specification of one or more items from a list in a component Guidance documentation Documentation that describes the delivery, preparation, operation, management and/or use of the TOE Smartcard Terminal A device which has a keypad, display, security module and Smartcard read/write functions. Identity A representation (e.g. a string) uniquely identifying an authorized user, which can either be the full or abbreviated name of that user or a pseudonym. Trusted path A means by which a user and a TSF can communicate with the necessary confidence Secure state State in which the TSF data are consistent and the TSF continues correct enforcement of the SFRs Trusted channel A means by which a TSF (TOE Security Functionality) and another trusted IT product can communicate with necessary confidence Element Indivisible statement of a security need [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 11/80 Role A predefined set of rules establishing the allowed interactions between a user and the TOE Operation (on a component of the CC) Modification or repetition of a component. Allowed operations on components are assignment, iteration, refinement and selection. Operation (on a subject) A specific type of action performed by a subject on an object Operational environment Environment in which the TOE is operated External Entity Entity (human or IT entity) possibly interacting with the TOE from outside of the TOE boundary Threat Agent Unauthorized user or external IT entity who makes threat like illegal access, modification and deletion to the asset. Authorized Issuer Authorized User who safely operate and manage functions according to TOE Security Policy Authorized User TOE user who may, in accordance with the SFRs, perform an operation Authentication Data Information used to verify the claimed identity of a user Assets Entities that the owner of the TOE presumably places value upon Refinement The addition of details to a component Organizational Security Policies A set of security rules, procedures, practices, or guidelines imposed by an organization upon its operations. Dependency Relationship between components such that if a requirement based on the depending component is included in a PP, ST or package, a requirement based on the component that is depended upon must normally also be included in the PP, ST or package Subject An active entity in the TOE that performs operations on objects Augmentation Addition of one or more requirement (s) to a package Component The smallest selectable set of elements on which requirements may be based Class A set of CC families that share a common focus [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 12/80 Evaluation Assessment of a PP, an ST or a TOE, against defined criteria TOE (Target of Evaluation) A set of software, firmware and/or hardware possibly accompanied by guidance EAL (Evaluation Assurance Level) A set of assurance requirements drawn from CC Part 3, representing a point on the CC predefined assurance scale, that form an assurance package Family A set of components that share a similar goal but differ in emphasis or rigour Package A named set of either security functional or security assurance requirements (ex: ‘EAL 4’) Assignment The specification of an identified parameter in a component (of the CC) or requirement Applet The name is given to a Java Card technology-based user application. An applet is the basic piece of code that can be selected for execution from outside the card. Each applet on the card is uniquely identified by its AID . EEPROM (Electrically Erasable Programmable Read-Only Memory) EEPROM is a non-volatile storage chip used in computers and other devices to store small amounts of volatile (configuration) data. When larger amounts of more static data are to be stored (such as in USB flash drives) other memory types like flash memory are more economic. SEEPROM, meaning Serial EEPROM, is an EEPROM chip that uses a serial interface to the circuit board IC Chip (Integrated Circuit Chip) A semiconductor for Smartcard functions, and it has mask ROM, EEPROM, RAM and I/O port. JCAPI (JavaCard Application Programming Interface) JCAPI is used to compose the application of JavaCard, is the interface for functions defined java framework and extended java package. JCAPI is a subset of the JavaTM programming language. Package A Package is a name space within the Java programming language that may contain class es and interfaces. A Package defines either a library, or applet definitions and is divided in two sets of files: export files and CAP files. RAM (Random Access Memory) A type of computer memory that can be accessed randomly; that is, any byte of memory can be accessed without touching the preceding bytes. There are two basic types of RAM: dynamic RAM (DRAM), static RAM (SRAM). The two types differ in the technology they use to hold data, dynamic RAM being the more common type. Dynamic RAM needs to be refreshed thousands of times per second. Static RAM does not need to be refreshed, which makes it faster; but it is also more expensive than dynamic RAM. Both types of RAM are volatile, meaning that they lose their contents when the power is turned off. ROM (Read-Only Memory) A computer memory on which data has been prerecorded. Once data has been written onto a ROM chip, it cannot be removed and can only be read. Unlike main memory (RAM), ROM retains its contents even when the computer is turned off. ROM is referred to as being nonvolatile, whereas RAM is volatile. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 13/80 TSF, TOE Security Functionality Combined functionality of all hardware, software, and firmware of a TOE that must be relied upon for the correct enforcement of the SFRs TOE resource Anything useable or consumable in the TOE TOE evaluation Assessment of a TOE against defined criteria TSF Data Data for the operation of the TOE upon which the enforcement of the SFR relies 1.7 Security Target constitution Section 1 is the introduction to this security target, providing security target references, TOE references, TOE overview and descriptions. Section 2 discusses conformance claims, where conformance to the Common Criteria, Protection Profile and Package is declared and the theoretical rationale of the conformance claims and methodology for conformance to the Protection Profile are described. Section 3 defines security problems, specifying security problems in TOE and the TOE operational environment from the perspectives of threat, organizational security policy and assumption. Section 4 specifies TOE security objectives and security objectives for the operational environment for tackling threats identified in the security problem definition, undertake organizational security policies and supporting assumptions. Section 5 defines extended components, explaining components extended in Part 2 or Part 3 of the Common Criteria. Section 6 illustrates security functional requirements and assurance requirements for satisfying security objectives. Section 7 summarizes TOE specification and explains security functions implemented in the TOE. References provide information on data that this document has referred to for users interested in this security target wishing to obtain further background or relevant information above what is specified here. The list of abbreviations is offered for better understanding of frequently used terms or abbreviations. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 14/80 2. Conformance claims This section provides a description of the Common Criteria, Protection Profile and Package that conform to Security Target. 2.1 CC Conformance Claim This ST is conformant to the following Common Criteria. - Common Criteria Identification • Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 3, July 2009, CCMB-2009-07-001 • Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, Version 3.1, Revision 3, July 2009, CCMB-2009-07-002 • Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, Version 3.1, Revision 3, July 2009, CCMB-2009-07-003 - Conformance to Common Criteria • Conformance to Common Criteria for Information Technology Security Evaluation, Part 2: Security functional components, Version 3.1, Revision 3 • Conformance to Common Criteria for Information Technology Security Evaluation, Part 3: Security assurance components, Version 3.1, Revision 3 Note: To be specified in parallel as “Common Criteria” from below 2.2 PP Conformance Claim This ST is conformant to the following Protection Profile. • Protection Profile Identification • Smart Card Open Platform Protection Profile v2.1(KECS-PP-0097a-2008), June 10, 2010 • Conformance to Protection Profile • Smart Card Open Platform Protection Profile v2.1 “Verifiable Conformance to Protection Profile” 2.3 Package Conformance This security target adds the following package of assurance requirements. This is added by the conformed Protection Profile. • EAL4+ (ATE_DPT.2 Testing: security enforcing modules, AVA_VAN.4 Methodical vulnerability analysis) [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 15/80 2.4 Rationale of Conformance Claim This security target conforms to the Protection Profile, as required in Smart Card Open Platform Protection Profile v2.1 (to be specified as “SCOP-PP” from below; the specification of version omitted), as follows: • Smart Card Open Platform Protection Profile v2.1 “Verifiable Conformance to Protection Profile” The rationale of Conformance Claim for Protection Profile of this ST is based on the following. 2.4.1 Rationale of Protection Profile Conformance The conformed Protection Profile is specified in line with “Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 2,” and this security target is prepared in line with “Common Criteria for Information Technology Security Evaluation, Part 1: Introduction and general model, Version 3.1, Revision 3.” However, the types in the conformed Protection Profile and this security target remain consistent as no change has been made regarding the consistency of types and structures in the conformed Protection Profile and this security target. 2.4.2 Rationale of Conformance Claim for Security problem definition This security target defines security problems relating to threats, organizational security policies and assumptions in the same way as SCOP-PP does. Therefore, this security target is equal to SCOP-PP. 2.4.3 Rationale of Conformance Claim for Security objectives This security target defines security objectives for TOE and the operational environment in the same way as SCOP-PP does. Among the security objectives of SCOP-PP, however, “Response to Information Leakage” is specified separately as TOE security objectives and security objectives for the operational environment, with the cautions specified in SCOP-PP as a reference. In this regard, this security target is equal to or more confined than SCOP-PP. Application Notes: Sub-hardware of TOE, an IC chip activates protection functions that it offers and counters external attacks to stop an external entity from abusing physical phenomena that take place during normal TOE operation (e.g. change in current, voltage and electromagnetism) and thereby obtaining TOE information. 2.4.4 Rationale of Conformance Claim for Security functional requirements The theoretical rationale of conformance claims for security functional requirements is provided in [Table 5], which demonstrates that the security functional requirements of this security target are equal to (or more confined than) those of SCOP-PP. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 16/80 [Table 5] Rationale of Conformance Claim for Security functional requirements Division Component Theoretical Rationale SCOP-PP ACCEPTANCE FAU_ARP.1 This security target undertakes operations allowed in SCOP- PP for functional components suggested on the left. FAU_SAA.1 SCOP-PP ACCEPTANCE FCS_CKM.1 This security target performs operations allowed in SCOP- PP for FCS_CKM.1 and FCS_CKM.4 among the functional components on the left and is thus equal to SCOP-PP. It is more limited than SCOP-PP as it carries out “repetition” and “elaboration” operations allowed in the Common Criteria for FCS_COP.1(1) ~(3) and specifies additional cryptographic computation. FCS_CKM.4 FCS_COP.1(1) FCS_COP.1(2) FCS_COP.1(3) SCOP-PP ACCEPTANCE FDP_ACC.2(1) This security target undertakes operations allowed in SCOP- PP for FDP_ RIP.1 among the functional components suggested on the left and is thus equal to SCOP-PP. It is more limited than SCOP-PP as it carries out “repetition” and “elaboration” operations allowed in the Common Criteria for FDP_ACC.2(1) ~ (2) and FDP_ACF.1(1) ~ (2) and specifies additional requirements for user data protection. FDP_ACC.2(2) FDP_ACF.1(1) FDP_ACF.1(2) FDP_RIP.1 ADDITION FDP_SDI.2 This security target additionally defines SFRs for the integrity test of saved data, response behaviors and the integrity of transmitted data. It is more limited than SCOP- PP as it defines additional security functional requirements for TSF protection. FDP_UCT.1 FDP_UIT.1 SCOP-PP ACCEPTANCE FIA_AFL.1 This security target carries out operations allowed in SCOP- PP for FIA_AFL.1, FIA_SOS.1, FIA_UAU.4, FIA_UAU.6 and FIA_UID.1 among the functional components suggested on the left and is thus equal to SCOP-PP. It is more limited than SCOP-PP as it carries out “repetition” and “elaboration” operations allowed in the Common Criteria for FIA_ATD.1(1) ~ (2) and FIA_UAU.1(1) ~ (4) among the functional components on the left to specify additional authentication. FIA_ATD.1(1) FIA_ATD.1(2) FIA_SOS.1 FIA_UAU.1(1) FIA_UAU.1(2) FIA_UAU.1(3) FIA_UAU.1(4) FIA_UAU.4 FIA_UAU.6 FIA_UID.1 ADDITION FIA_USB.1 This security target additionally defines SFRs for user- subject binding. It is more limited than SCOP-PP as it defines additional security functional requirements for identification and authentication. SCOP-PP ACCEPTANCE FMT_MOF.1 This security target performs operations allowed in SCOP- PP for FMT_MOF.1, FMT_MSA.3, FMT_MTD.1, FMT_MTD.2, FMT_SMF.1 and FMT_SMR.1 among the functional components suggested on the left. It is more limited than SCOP-PP as it carries out “repetition” and “elaboration” operations allowed in the Common Criteria for FMT_MSA.1(1) ~ (2) among the functional components on the left to specify additional security management requirements. FMT_MSA.1(1) FMT_MSA.1(2) FMT_MSA.3 FMT_MTD.1 FMT_MTD.2 FMT_SMF.1 FMT_SMR.1 SCOP-PP FPR_UNO.1 This security target undertakes operations allowed in SCOP- [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 17/80 ACCEPTANCE PP for functional components suggested on the left. SCOP-PP ACCEPTANCE FPT_FLS.1 This security target undertakes operations allowed in SCOP- PP for functional components suggested on the left. FPT_RCV.3 FPT_RCV.4 FPT_TST.1 2.4.5 Rationale of Conformance Claim for Assurance Requirements The theoretical rationale of conformance claims for assurance requirements is specified in [Table 6], which shows that the assurance requirements of this security target are equal to (or more confined than) those of SCOP-PP. [Table 6] Rationale of Conformance Claim for Assurance requirements Assurance Class Assurance Components Rationale ASE: Security Target ASE_INT.1 ST introduction This security target provides assurance requirements equivalent to EAL 4+. This security target includes perfectly equal assurance requirements as SCOP-PP and does not add to SCOP-PP or specify hierarchically stronger assurance requirements. ASE_CCL.1 Conformance claims ASE_SPD.1 Security problem definition ASE_OBJ.2 Security objectives ASE_ECD.1 Extended components definition ASE_REQ.2 Derived security requirements ASE_TSS.1 TOE summary specification ADV: Development ADV_ARC.1 Security architecture description ADV_FSP.4 Complete functional specification ADV_IMP.1 Implementation representation of the TSF ADV_TDS.3 Basic modular design AGD: Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC: Life-cycle support ALC_CMC.4 Production support, acceptance procedures and automation ALC_CMS.4 Problem tracking CM coverage ALC_DEL.1 Delivery procedures ALC_DVS.1 Identification of security measures ALC_LCD.1 Developer defined life-cycle model [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 18/80 ALC_TAT.1 Well-defined development tools ATE: Tests ATE_COV.2 Analysis of coverage ATE_DPT.2 Testing: security enforcing modules ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample AVA: Vulnerability assessment AVA_VAN.4 Methodical vulnerability analysis [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 19/80 3. Security problem definition The security problem definition defines the threats, the organizational security policies and the assumptions to be addressed by the TOE and the operational environment of the TOE. 3.1 Assets TOE is a Java Card platform that is run on the IC chip to manage information and resources. Its assets are divided into “primary assets” and “secondary assets.” The security objective of the TOE is to protect primary assets during the usage phase. The information and tools used in the manufacturing and development of smart cards need to be protected to defend these primary assets, and these information and tools are called secondary assets. In other words, the information generated or utilized in the process of TOE production does not constitute assets that are directly protected by the TOE, but it significantly affects the integrity or confidentiality of the TOE itself. This information is called secondary assets, and the safety of secondary assets is satisfied by EAL4+ assurance requirements. The primary assets that the TOE needs to protect are data managed in the smart card; they are divided into user data and TSF data. The former refers to data generated for or by the users, while the latter is data generated for or by the TOE. Smart cards are carried and used by users, so they are the subjects that the attackers seek to steal. Therefore, the IC chips themselves are assets that need to be protected from physical threats. These assets have to do with TOE threats and can be classified as follows: • TOE including Native Code • User data • TSF data The next section describes in detail the user data and TSF data among primary assets that the TOE needs to protect. 3.1.1 User Data User data include certain PINs, authentication data, application codes and sensitive application values of applications that need to be protected from unauthorized exposure and modification. D.APP_CODE This is the code of the applets and libraries loaded on the TOE and shall be protected from unauthorized modification. D.APP_DATA This is 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 and shall be protected from unauthorized modification. D.PIN This is user PIN and shall be protected from unauthorized disclosure and modification. D.APP_KEYs This is cryptographic keys owned by the applets and shall be protected from unauthorized disclosure and modification. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 20/80 3.1.2 TSF Data TSF data include the initialization data, the configuration data, the cryptographic keys, random for key generation that shall be protected from unauthorized disclosure and modification and all data using by TOE for the security feature of TOE. D.TS_CODE This is TOE system code and shall be protected from unauthorized disclosure and modification. D.TS_KEYs This is TOE system key, that is, the cryptographic key used when loading a file into the card and IK, MK for the card initialization D.TS_DATA This is TOE system data, the internal runtime data areas necessary for the execution of the JCVM and shall be protected from monopolization and unauthorized disclosure or modification D.SEC_DATA This is the runtime security data of the JCRE of TOE and shall be protected from unauthorized disclosure and Modification D.CRYPTO This is cryptographic data used in runtime cryptographic computations, like a seed used to generate a key and shall be protected from unauthorized disclosure and modification. 3.2 Threats The threat agent is user and external IT entity that attempts illegal access to assets protected by the TOE using physical or logical methods outside the TOE and harm using abnormal method. The threat agent to the TOE requires the middle level of expertise, resources and motivation. T. Logical Attack The threat agent may abuse logical interfaces to modify and disclose user data or TSF data. Application Notes: Logical interfaces are data exchange interfaces between TOE and the smart card terminal, usually referring to commands and responses exchanged between the smart card and the terminal. These commands and responses include international, local, industrial and independent standards. Attackers may abuse sentences or interpretational differences exploiting logical interfaces or abuse commands for certain usage. T. Abuse Issue The threat agent may abuse the TOE while the smartcard including the TOE is issued. T. UnAuthorized IFD The threat agent may modify and disclose user data or TSF data by abusing an unauthorized terminal. T. UnAuthorized App The threat agent may modify and disclose user data or TSF data by unauthorized installation of application program containing malicious code. T. Unexpected Malfunction User data or TSF data can be disclosed or damaged by incomplete termination of TSF service due to cut of power supply or an impact during card usage. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 21/80 T. Repeat authentication The threat agent may access to the TOE by attempting authentication repeatedly. T. Abnormal Malfunction The threat agent may modify and disclose user data or TSF data in case of incomplete termination of a TSF service caused by attacks based on giving physical stress to smartcard. Application Notes: This threat refers to an attack where the attacker places physical stress such as voltage, frequency and temperature in order to modify or expose TSF data. T. Residue Information When the TOE reuses resources, the threat agent may access to unauthorized information in case the object information is not removed adequately. T. Information Leakage The threat agent may abuse the information leaked from the TOE during the normal TOE operation. Application Notes: Information leaked during normal TOE usage refers to electric signals such as power, voltage and current released from the IC circuit of a smart card. This threat is an attack where the attacker can obtain cryptographic keys or major TSF data by analyzing electric signals from the smart card with relevant equipment. Prime examples of this attack include power attack, differential power attack and timing attack. 3.3 Organizational security policies Organizational security policies described this section must be observed in the TOE following this Security Target. P. Open platform The TOE must be developed as an open platform which can load and use multiple applications in an interoperable manner. P. Duty separation Role must be assigned to the responsible personnel of each step from manufacturing to using the smartcard and the TOE must be created and managed according to each role in a secure manner. 3.4 Assumptions It is assumed that the following terms exist in the TOE operation environment accepting this Security Target. A. Secure Channel There shall be a secure channel between the TOE and the IFD. A. Application The application program must follow approved procedure when installed into the TOE. If the application program is installed adequately, it shall not contain malicious code. A. Underlying hardware Underlying hardware upon which the TOE is operated must be physically secure and provide [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 22/80 cryptographic operation for the security functions of TOE. Application Notes: The hardware (i.e. the IC chip of a smart card) based on which the TOE operates to come up with tools to tackle physical attacks and ensure the safety of TOE includes S3CC9GC, a CC EAL4+-certified smart card IC chip from Samsung Electronics, and S3CC9LC, a CC EAL5+-certified smart card IC chip from Samsung Electronics. Cryptographic computation supported by the IC chip is provided from the IC chip’s cryptography-dedicated processor and the crypto library built in the chip, excluding the cryptographic algorithm implemented as software. A. TOE management In the steps from manufacturing to using the TOE, there are roles of manufacturers, issuers and holders and training to each role shall be conducted in accordance with defined provisions. And the TOE is handled in a secure manner when repaired or replaced due to breakdown of the TOE or the smartcard. A. TSF data TSF data that are exposed to be processed in the course of TOE operation are managed securely. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 23/80 4. Security objectives This security target defines security objectives by categorizing them into the TOE and the environment. The security objectives for the TOE are directly handled by the TOE. The security objectives for the environment are handled by technical/process-related means so that TOE exactly provides its security functionality. 4.1 Security objectives for the TOE The followings are security objectives directly handling by the TOE: O. Data Protection The TOE shall be protected stored user data and TSF data from unauthorized disclosure, modification and deletion. O. Issue The TOE must ensure that authorized issuer can issue smartcards according to defined procedure. O. Identification The TOE must clarify users who can use logical interfaces and their access rights to assets according to roles. Application Notes: TOE should be able to clearly identify users and assets so that each user can be linked to assets accessible through logical interfaces. O. Authorized Repair The TOE must ensure that only an authorized user can conduct fix the failure. Application Notes: Repairs can be made only by those who can normally use logical interfaces with authorized terminals. Logical interfaces can be implemented with international, local, industrial and independent standards. O. Authentication A user must conduct authentication procedure before accessing TOE user data and TSF data. O. Rollback The TOE shall be rolled back to a well-defined valid state in case of TSF failure. And the TOE must detect the failure of the TSF and resume TSF service from the state before failure. O. Rem_Residue The TOE shall ensure that user data or TSF data stored in memories is protected against an unintended remaining in case of session closed in the work area used by TSF. O. Leak Countermeasure The TOE must be designed to prevent normally disclosed information from being abused. Application Notes: Major TSF data of the TOE, Keys and PIN are encrypted to counter external attacks so that an external entity cannot obtain TOE information. O.Open Platform The TOE must be supported as an open platform which can load and use multiple applications in an interoperable manner. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 24/80 4.2 Security objectives for the operational environment Below are security objectives that need to be handled with technical/procedural means supported in the operational environment in order for the TOE to accurately provide its security functionality: OE.Training Administration training must be conducted for each role of step of manufacturing, issuing, and using. OE. Secure Communication A secure communication cannel shall be provided between the TOE and corresponding smartcard accepting device. OE.Application The application installation must follow approved procedure, and adequately loaded applications shall not contain malicious code. OE.Leak Countermeasure TOE must implement the countermeasure to prevent misuse of disclosed information from the TOE during the normal TOE operation. Application Notes: Sub-hardware of TOE, an IC chip activates protection functions that it offers and counters external attacks to stop an external entity from abusing physical phenomena that take place during normal TOE operation (e.g. change in current, voltage and electromagnetism) and thereby obtaining TOE information. OE.Underlying hardware The TOE must ensure secure operation on a tamper-resistant IC chip, and the Underlying hardware of the TOE shall provide means to counter various tampering attacks. Application Notes: An IC chip supports cryptographic computation and provides the TOE with SPA/DPA handling techniques in this regard. It also provides the TOE with the functions of ActiveShield and Security Detector for preventing external infiltration in order to examine if the TOE goes beyond its normal scope of operation. OE.TSF data The TOE must operate the TSF data processed out of the TOE in a secure manner. 4.3 Security Objectives Rationale The theoretical rationale of security objectives proves that the specified security objectives are adequate, sufficient to deal with security problems, and not excessive but essential. The theoretical rationale of security objectives demonstrates the followings: • Each assumption, threat or organizational security policy is handled by at least one security objective. • Each security objective handles at least one assumption, threat or organizational security policy. [Table 7] Relation between security objectives and the security problem definition TOE security objectives Security objectives for the operational environment Security objectives for the operational environment [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 25/80 Security objectives Definition of security problems O.Data Protection O.Issuance O.IDENTIFICATI ON O.Authorized Repair O.Authentication O.Rollback O.Rem_Residue O.Leak Countermeasure O.Open Platform OE.Training OE.Safe Communication OE.Application OE.Leak Countermeasure OE.Underlying hardware OE.TSF Data T.Logical Attack X X X X X T.Abuse Issue X X T.UnAuthorized IFD X X X X X T.UnAuthorized App X X T.Unexpected Malfunction X X T.Repeat Authentication X T.Abnormal Malfunction X T.Residue Information X X T.Information Leakage X X P.Open Platform X P.Duty Separation X X X X X A.Secure Channel X A.Application X A.Underlying Hardware X A.TOE Management X A.TSF Data X [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 26/80 4.3.1 TOE Security Objectives Rationale O.Data Protection This security objective ensures that only authorized users can access and modify user data and TSF data as assets. This security objective is necessary to deal with T.Logical Attack and T.Unauthorized IFD Threat where unauthorized users provoke attacks using smart card commands. O.Issue This security objective ensures only authorized personnel can undertake issuance operations upon the issuance of smart cards. This security objective is necessary to: deal with T.Logical Attack, where logical attacks are made; tackle T.UnAuthorized IFD and T.Abuse Issue, where unauthorized users access the terminal and perform issuance operations illicitly; and carry out the organizational security policy, P.Duty Separation. O.Identification This security objective ensures that the roles of TOE users and issuers are identified. TSF should clarify users that can use logical interfaces and assets they can utilize. Therefore, this security objective is necessary to deal with threats such as T.Logical Attack, T.UnAuthorized IFD and T.UnAuthorized App and to undertake the organizational security policy, P.Duty Separation. O.Authorized Repair This security objective ensures that only authorized issuers can access smart card management functions upon TOE failure. This security objective is necessary to deal with T.UnAuthorized IFD, where the terminal is used illicitly, and T.Logical Attack, where logical attacks such as illicit command use are made, and to carry out the organizational security policy, P.Duty Separation. O.Authorization This security objective ensures that the TOE provides means of authorization for identified users. Therefore, this security objective is necessary to deal with threats such as T.Logical Attack, T.UnAuthorized IFD and T.Repeat Authentication and to undertake the organizational security policy, P.Duty Separation. O.Rollback This security objective ensures that TOE detects any malfunction during TSF service and resumes the service from the state prior to the detection of malfunction. Therefore, this security objective is necessary to deal with T.Unexpected Malfunction, a threat where TSF service is suspended by unexpected failure during usage. O.Rem_Residue This security objective ensures that information in resources is removed upon the insecure termination of service and is thus necessary to deal with the threat T.Unexpected Malfunction. It also ensures that user data or TSF data are not left in the work areas where TSF service is used. This is necessary to tackle T.Residue Information, a threat where TSF records information in resources and terminates the use but fails to remove the information properly. O.Leak Countermeasure This security objective ensures that even during normal TOE usage, data leaked by using relevant equipment are detected and countermeasures implemented to prevent any abuse of sensitive TSF data. TOE may be attacked in an environment where its physical vulnerabilities are fully exposed and may be potentially abused. Therefore, this security objective is needed to tackle the threat, T.Information Leakage. O.Open Platform [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 27/80 This security objective ensures that TOE is an open platform where a wide variety of applications can be installed and used. Therefore, this security objective is needed to undertake the organizational security policy, P.Open Platform. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 28/80 4.3.2 Security Objectives Rationale for the operational environment OE.Training This security objective for the operational environment ensures that proper training is made by separated role in the process of issuing and using the TOE at the manufacturing phase. Developers should specify in the user manual and the administrator manual that proper training should be given, and evaluators should verify this. Therefore, this security objective is necessary to carry out the organizational security policy, P.Duty Separation, and support the assumption A.TOE Management. OE.Secure Communication This security objective for the operational environment should provide a safe path between the TOE and the terminal that it communicates with. Therefore, this security objective is necessary to support the assumption A.Secure Channel. OE.Application This security objective for the operational environment ensures that the procedure of installing applications in the TOE is carried out legitimately and that no misconduct is made. The administrator should undergo proper identification and authorization processes and install the applications in line with the approved procedure, and these legitimately installed applications should not include any malicious code. Therefore, this security objective is necessary to tackle the threat T.Abuse Issue and support the assumption A.Secure Channel. OE.Leak Countermeasure This security objective ensures that even during normal TOE usage, data leaked by using relevant equipment are detected and countermeasures implemented to prevent any abuse of sensitive TSF data. TOE may be attacked in an environment where its physical vulnerabilities are fully exposed and may be potentially abused. Therefore, this security objective is needed to tackle the threat, T.Information Leakage. OE.Underlying hardware This security objective for the operational environment ensures that the TOE operates on a physically secure chip and that TOE’s sub-hardware provides countermeasures and cryptographic computation against a wide array of physical attacks to support TOE security functions. Therefore, this security objective is necessary to deal with threats such as T.Abnormal Malfunction and T.Residue Information and support the assumption A.Underlying Hardware. OE.TSF Data This security objective for the operational environment ensures that in the environment where the TOE is operated, TSF data getting out of the TOE are managed securely even beyond the TOE’s control. To achieve this security objective, developers should securely manage data stored in the terminal as the environment where the TOE is used. Therefore, this security objective is necessary to support the assumption A.TSF Data. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 29/80 5. Extended Components Definition This section describes the components extended from CC Part 2 or Part 3. 5.1 Extended Components Definition In this Security Target, the components extended from CC Part 2 or Part 3 do not exist. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 30/80 6. Security Requirements Security requirements specify function and warranty requirements that are accepted by this security target and should be met on the TOE. This security target defines all the subjects, objects, operations, security attributes and external entities used in security requirements as follows: a) Subjects, objects and related security attributes and operations1 [Table 8] Subject and Object, related security attribute, operation definition Subject (user) Subject (user) security attribute Object (information) Object (information) security attribute Operation S.APP Context, Active, Selected OB.JAVAOB JECT Sharing, Context, LifeTime -OP.ARRAY_ACCESS -OP.INSTANCE_FIELD -OP.INVK_VIRTUAL -OP.INVK_INTERFACE -OP.THROW -OP.TYPE_ACCESS -OP.JAVA -OP.CREATE (Sharing, LifeTime) S.JCRE None S.CM Lifecycle, Security Level, Privilege OB.APP Signature, Context -OP.LOAD -OP.INSTALL -OP.DELETE Issuer (Administrat or) User identifier, authentication data, role TSF data - -Modification, deletion -Specification of limits -Verification of integrity security attribute - -Modification, deletion -Specification of initial values to replace defaults Note: In [Table 14], the subjects of an active entity within the TOE during TOE operation are S.APP, S.JCRE and S.CM, and the entity here as TOE administrator is the issuer. b) External entities - SmartCard Terminal - SmartCard IC Chip 1 Subjects (prefixed with an S ), objects (prefixed with an OB ) and operations (prefixed with an OP ) are used in this document [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 31/80 6.1 Security functional requirements Security functional requirements defined in this security target are expressed by selecting relevant security functional components from Part 2 of the Common Criteria to meet the security objectives identified in the previous section. [Table 9] summarizes security functional components used in this security target. [Table 9] Security functional requirements Security Functional Class Security Functional Component Remarks Security Audit FAU_ARP.1 Security alarms SCOP-PP FAU_SAA.1 Potential violation analysis Cryptographi c Support FCS_CKM.1 Cryptographic key generation FCS_CKM.4 Cryptographic key destruction SCOP-PP FCS_COP.1(1) Cryptographic operation FCS_COP.1(2) Cryptographic operation Added (Iteration) FCS_COP.1(3) Cryptographic operation User Data Protection FDP_ACC.2(1) Complete access control SCOP-PP FDP_ACC.2(2) Complete access control Added (Iteration) FDP_ACF.1(1) Security attribute based access control SCOP-PP FDP_ACF.1(2) Security attribute based access control Added (Iteration) FDP_RIP.1 Subset residual information protection SCOP-PP FDP_SDI.2 Stored data integrity monitoring and action Added FDP_UCT.1 Basic data exchange confidentiality Added FDP_UIT.1 Data exchange integrity Added Identification and Authenticatio n FIA_AFL.1 Authentication failure handling SCOP-PP FIA_ATD.1(1) User attribute definition FIA_ATD.1(2) User attribute definition Added (Iteration) FIA_SOS.1 Verification of secrets SCOP-PP FIA_UAU.1(1) Authentication FIA_UAU.1(2) Authentication Added (Iteration) FIA_UAU.1(3) Authentication Added (Iteration) FIA_UAU.1(4) Authentication Added (Iteration) FIA_UAU.4 Single-use authentication mechanisms SCOP-PP FIA_UAU.6 Re-authenticating FIA_UID.1 Identification FIA_USB.1 User-subject binding Added Security Management FMT_MOF.1 Management of security functions behavior SCOP-PP FMT_MSA.1(1) Management of security attributes FMT_MSA.1(2) Management of security attributes Added (Iteration) FMT_MSA.3 Static attribute initialization SCOP-PP FMT_MTD.1 MANAGEMENT OF TSF Data FMT_MTD.2 MANAGEMENT OF LIMITS ON TSF Data FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles Privacy FPR_UNO.1 Unobservability [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 32/80 Protection of the TSF FPT_FLS.1 Failure with preservation of secure state FPT_RCV.3 Automated recovery without undue loss FPT_RCV.4 Function recovery FPT_TST.1 TSF testing 6.1.1 Security Audit FAU_ARP.1 Security alarms Hierarchical to: No other components Dependencies: FAU_SAA.1 Potential violation analysis FAU_ARP.1.1 The TSF shall take [one of the below list of actions] upon detection of a potential security violation. [ List of actions: a) blocks the action that produce the security violation and throws an exception; b) locks the card session (to become mute); c) reinitializes the Java Card System and its data (reset); d) temporarily disables the services of the card until a privileged roles performs a special action; e) definitely disables all the services of the card; ] Application Notes: This functional requirement may define a variety of response functions to protect data in the smart card if TOE detects any potential external security violation event. When an external attack is detected, the response could be the suspension of card functions or the deletion of memory data. FAU_SAA.1 Potential violation analysis Hierarchical to: No other components Dependencies: FAU_GEN.1 Audit data generation FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the audited events and based upon these rules indicate a potential violation of the enforcement of the SFRs. FAU_SAA.1.2 The TSF shall enforce the following rules for monitoring audited events. a) Accumulation or combination of the following known [security violation events] representing potential security violations [ [Table 10] Security violation events Security violation events Abnormal environmental conditions (frequency, voltage, temperature) Physical tampering EEPROM failure audited through exceptions in the read/write operations and inconsistency check Card Manger life cycle inconsistency audited through the life cycle checks in all administrative operations Corruption of check-summed objects [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 33/80 Applet life cycle inconsistency Card tearing (unexpected removal of the Card out of the CAD) and power failure Abortion of a transaction in an unexpected context Violation of the Firewall or JCVM security policies Unavailability of resources Array overflow Access uninitialized key Security exception limit excess Abort Transaction limit excess Other runtime errors related to applet’s failure, like uncaught exceptions Randomness test for the random number generator is failed The Integrity of the patch code and table is corrupted. ] b) [none] Application Notes: Elaboration operations are undertaken as TOE does not conduct potential violation analysis and auditing record using audited events but utilizes the handling progress of internal events to carry out potential security violation analysis. TSF may perform security alert functions in FAU_ARP.1 through security violation analysis on the check sum values of internal data, errors in resource allocation and authentication failure events. 6.1.2 Cryptographic Support FCS_CKM.1 Cryptographic key generation Hierarchical to: No other components Dependencies: [FCS_CKM.2 Cryptographic key distribution, or FCS_COP.1 Cryptographic operation] FCS_CKM.4 Cryptographic key destruction FCS_CKM.1.1 The TSF shall generate cryptographic keys in accordance with a specified cryptographic key generation algorithm [[R10], E.4.1] and specified cryptographic key sizes [112bits] that meet the following: [[R10], 8. Secure Communication]. Application Notes: This security functional requirement may support cryptographic key generation in the TOE operational environment (i.e. the cryptography-dedicated processor of the smart card IC chip, or the crypto library loaded onto the IC chip) if it cannot be fully implemented as TOE security functional requirement. Note: TOE can generate cryptographic keys in line with the specified cryptographic key generation algorithms [[R24], [R25]] and the specified cryptographic key length [RSA 1024, 2048bits] that are suitable for [[R29], Annex A, sections A.4 and A.5, and Annex C ] provided by the TOE operational environment (i.e. the cryptography-dedicated processor of the smart card IC chip, or the crypto library loaded onto the IC chip). See [R16] for more detail. Cryptographic keys can also be generated in line with the specified cryptographic key generation algorithm [[R27], section A.4.3 Elliptic Curve Key Generation] and the specified cryptographic key length [ECC 192, 224, 256bits] that are suitable for [[R27]] provided by the TOE operational environment (i.e. the cryptography-dedicated processor of the smart card IC chip, or the crypto library loaded onto the IC chip). See [R26] for more detail. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 34/80 FCS_CKM.4 Cryptographic key destruction Hierarchical to: No other components Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4.1 The TSF shall destroy cryptographic keys in accordance with a specified cryptographic key destruction method [physical deletion by overwriting the memory data with zero value] that meets the following: [none]. FCS_COP.1 (1) Cryptographic operation Hierarchical to: No other components Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1 The TSF shall perform [data encryption and decryption] in accordance with a specified cryptographic algorithm [SEED in ECB/CBC mode] and cryptographic key sizes [128 bits] that meet the following: [the below list of SEED standards]. [  TTAS.KO-12.0004: 128-bit Symmetric Block Cipher (SEED) ] FCS_COP.1 (2) Cryptographic operation Hierarchical to: No other components Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction FCS_COP.1.1 The TSF shall perform [data encryption and decryption] in accordance with a specified cryptographic algorithm [ARIA in ECB/CBC mode] and cryptographic key sizes [128, 192 or 256 bits] that meet the following: [the below list of ARIA standards]. [  KSX1213 128-bit Symmetric Block Cipher ARIA, May, 2004 ] FCS_COP.1 (3) Cryptographic operation Hierarchical to: No other components Dependencies: [FDP_ITC.1 Import of user data without security attributes, or FDP_ITC.2 Import of user data with security attributes, or FCS_CKM.1 Cryptographic key generation] FCS_CKM.4 Cryptographic key destruction [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 35/80 FCS_COP.1.1 The TSF shall perform [secure hashing] in accordance with a specified cryptographic algorithm [SHA-224/256] and cryptographic key sizes [none] that meet the following: [the below list of SHA-224/256 standards]. [  ANSI X9.30, NIST FIPS180-2: Secure Hash Standard, August 1, 2002 ] Note: The FCS_COP.1 security functional requirement defines software cryptographic computation functions provided by TOE. The below table illustrates cryptographic computation functions supported by the cryptography-dedicated processor for the smart card IC chip and the crypto library as the TOE operational environment. [Table 11] Cryptographic algorithm of hardware and crypto library cryptographic algorithm Standard Function key sizes TDES in ECB/CBC mode -FIPS PUB 46-3 -ISO/IEC 9797-1:1999: Part1 data encryption and decryption 112 bits (TDES double key, 168 bits (TDES triple key) TDES Signature -FIPS PUB 46-3 -ISO/IEC 9797-1:1999: Part1 data signature generation and verification 112 bits (TDES double key, 168 bits (TDES triple key)] RSA Cipher -PKCS#1 v2.1 -ANSI X9.31, PKCS#2 and IEEE- P13-63 data encryption and decryption 1024, 2048 bits for modulus RSA Signature -PKCS#1 v2.1 -ISO/IEC 9796-2:2002: data signature generation and verification 1024, 2048 bits for modulus ECC Signature -ANSI X9.62-2005 data signature generation and verification 192, 224, 256 bits ECDH -ANSI X9.63-2001 Diffie-Hellman key agreement 192, 224, 256 bits 6.1.3 User Data Protection FDP_ACC.2 (1) Complete access control Hierarchical to: FDP_ACC.1 Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.2.1 The TSF shall enforce the [CARD CONTENT MANAGEMENT access control SFP] on [list of subjects and objects specified in [Table 12] in relation to CARDMANAGER] and all operations among subjects and objects covered by the SFP. [ [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 36/80 [Table 12] List of subjects and objects Subject and Object Description S.CM CardManager, which is the security policy of [R10] OB.APP This represents the JavaCard Package and is the object of S.CM. [Table 13] List of Operation Operation Description OP.LOAD Load Package under the Package AID , card lifecycle, SCP02, DM and DAP authentication of [R10] OP.INSTALL Install Package under the Package AID , card lifecycle, SCP02, DM and DAP authentication of [R10] OP.DELETE Delete Package under the Package AID , card lifecycle, SCP02, DM and DAP authentication of [R10] ] FDP_ACC.2.2 The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. FDP_ACC.2(2) Complete access control Hierarchical to: FDP_ACC.1 Dependencies: FDP_ACF.1 Security attribute based access control FDP_ACC.2.1 The TSF shall enforce the [FIREWALL access control SFP] on [list of subjects and objects specified in [Table 14] in relation to FIREWALL] and all operations among subjects and objects covered by the SFP. [ [Table 14] List of subjects and objects Subject and Object Description S.APP Any package, which is the security unit of the firewall policy S.JCRE The JCRE. This is the process that manages applet selection and deselection, along with the delivery of APDUs from and to the smart card device. This subject is unique. OB.JAVAOBJECT Any Object. Note that KEYS, PIN, arrays and applet instances are specific objects in the Java programming language. [Table 15] List of Operation Operation Description OP.ARRAY_ACCESS Read/Write an array component [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 37/80 OP.INSTANCE_FIELD Read/Write a field of an instance of a class in the Java programming language OP.INVK_VIRTUAL Invoke a virtual method (either on a class instance or an array object) OP.INVK_INTERFACE Invoke an interface method OP.THROW Throwing of an object OP.TYPE_ACCESS Invoke checkcast or instanceof on an object OP.JAVA Any access in the sense of [R13], §6.2.8. In our Information, this is one of the preceding operations. OP.CREATE (Sharing, LifeTime) Creation of an object (new or makeTransient call) ] FDP_ACC.2.2 The TSF shall ensure that all operations between any subject controlled by the TSF and any object controlled by the TSF are covered by an access control SFP. FDP_ACF.1(1) Security attribute based access control Hierarchical to: No other components Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1 The TSF shall enforce the [Security attribute of Subject and Object specified in the [Table 17] based CARD CONTENT MANAGEMENT access control SFP] to objects based on the [Security attribute of Subject and Object specified in the [Table 16] in relation to CARDMANAGER]: [ [Table 16] Security attribute of Subject and Object Subject and Object Security Attribute S.CM Lifecycle, Security Level, Privilege OB.APP Signature, Context [Table 17] Values of Security attribute Name Description Lifecycle Card lifecycle - OP_READY, INITIALIZED, SECURED, CARD_LOCKED, TERMINATED Security Level Secure Channel Protocol- SCP02 authentication of [R10] operates according to the Security Level that is established. Its coding is AUTHENTICATED, NO_SECURITY, C_MAC etc. Privilege Privilege - SECURITY_DOMAIN, DAP_VERIFICATION, DELEGATED_MANAGEMENT, CARD_LOCK, CARD_TERMINATE, DEFAULT_SELECTED, [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 38/80 CVM_MANAGEMENT, MANDATED_DAP_VERIFICATION Signature SCP02_C_MAC - Signature for each command which includes Package AID, Code and Data by SCP02 authentication of [R10] DM_TOKEN - Signature on Package AID and Information for DM authentication of [R10] DAP block - Signature on Package AID, Code and Data for DAP authentication of [R10] Context Package AID ] FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [Authorizing access rules specified in the [Table 18] and a. Added rules] [ a. Added rules If the Security Level sets C_MAC and SCP02_C_MAC is successfully verified by the key issued by S.CM, then OP.LOAD, OP.INSTALL and OP.DELETE continues. If the SECURITY_DOMAIN and DELEGATED_MANAGEMENT Privilege is granted, the DM_TOKEN is presented and it is successfully verified by the key issued by S.CM, then OP.LOAD, OP.INSTALL and OP.DELETE continues. If the SECURITY_DOMAIN and DAP_VERIFICATION or MANDATED_DAP_VERIFICATION Privilege is granted, the DAP block is presented and it is successfully verified by the key issued by S.CM, then OP.LOAD, OP.INSTALL and OP.DELETE continues. ] FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [none] FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the [Denying access rules specified in the[Table 18]]: [ [Table 18] Security attribute based access control rules Security attributes Governing access rules Authorizing access rules Denying access rules Lifecycle Verify the card lifecycle is OP_READY, INITIALIZED, SECURED, CARD_LOCKED or TERMINATED If the card lifecycle is OP_READY, INITIALIZED or SECURED. OP.LOAD, OP.INSTALL and OP.DELETE continues. If the card lifecycle is CARD_LOCKED or TERMINATED. OP.LOAD, OP.INSTALL and OP.DELETE is aborted. Security Level Verify the SCP02 authentication of [R10] is successful and the Security Level is AUTHENTICATED or NO_SECURITY If the SCP02 authentication of [R10] is successful and the Security Level is AUTHENTICATED. OP.LOAD, If the SCP02 authentication of [R10] is fail and the Security Level is NO_SECURITY. OP.LOAD, [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 39/80 OP.INSTALL and OP.DELETE continues. OP.INSTALL and OP.DELETE is aborted. Context Verify there is other application currently loaded on this TOE with the same AID If there is no other application currently loaded on this TOE with the same AID. OP.LOAD and OP.INSTALL continues. OP.DELETE is aborted. If there is another application currently loaded on this TOE with the same AID. OP.LOAD and OP.INSTALL is aborted. OP.DELETE continues. ] FDP_ACF.1(2) Security attribute based access control Hierarchical to: No other components Dependencies: FDP_ACC.1 Subset access control FMT_MSA.3 Static attribute initialization FDP_ACF.1.1 The TSF shall enforce the [Security attribute of Subject and Object specified in the [Table 20] based FIREWALL access control SFP] to objects based on the [Security attribute of Subject and Object specified in the [Table 19] in relation to FIREWALL] [ [Table 19] Security attribute of Subject and Object Subject and Object Security Attribute S.APP Context, Active, Selected S.JCRE None OB.JAVAOBJECT Sharing, Context, LifeTime [Table 20] Values of Security attribute Name Description Context Package AID or “JCRE” Active Context of any package is currently active context Selected Context of any package is currently selected applet context Sharing Standard, SIO, Java Card RE entry point, or global array LifeTime CLEAR_ON_DESELECT ( , COD) or PERSISTENT ] [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 40/80 FDP_ACF.1.2 The TSF shall enforce the following rules to determine if an operation among controlled subjects and controlled objects is allowed: [Authorizing access rules specified in the [Table 21]] FDP_ACF.1.3 The TSF shall explicitly authorize access of subjects to objects based on the following additional rules: [a. Added rules] [ a. Added rules The S.JCRE can freely perform all operations which includes OP.JAVA and OP.CREATE with the exception given in the Denying access rules of the LifeTime (COD) at the below table, provided it is the currently active context. ] FDP_ACF.1.4 The TSF shall explicitly deny access of subjects to objects based on the [Denying access rules specified in the[Table 21]]: [ [Table 21] Security attribute based access control rules Security attributes Governing access rules Authorizing access rules Denying access rules Context with Sharing (Standard) and LifeTime (PERSISTENT) Verify the Context of OB.JAVAOBJECT to be accessed by S.APP is the same as the Active Context. If the Context of OB.JAVAOBJECT to be accessed by S.APP is the same as the Active Context. OP.ARRAY_ACCESS, OP.INSTANCE_FIELD, OP.INVK_VIRTUAL, OP.INVK_INTERFACE, OP.THROW or OP.TYPE_ACCESS continues. If the Context of OB.JAVAOBJECT which is to be accessed by S.APP is not the same as the Active Context. OP.ARRAY_ACCESS, OP.INSTANCE_FIELD, OP.INVK_VIRTUAL, OP.INVK_INTERFACE, OP.THROW or OP.TYPE_ACCESS is aborted. Sharing (Java Card RE entry point or global array) Verify the Sharing attribute of OB.JAVAOBJECT to be accessed by S.APP is Card RE entry point or Global Array If the Sharing attribute of OB.JAVAOBJECT to be accessed by S.APP is Card RE entry point or Global Array. OP.ARRAY_ACCESS, OP.INSTANCE_FIELD, OP.INVK_VIRTUAL, OP.INVK_INTERFACE, OP.THROW or OP.TYPE_ACCESS continues. - [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 41/80 Sharing (SIO) Verify the Sharing attribute of OB.JAVAOBJECT to be accessed by S.APP is SIO If the Sharing attribute of OB.JAVAOBJECT to be accessed by S.APP is SIO and the O.JAVAOBJECT's interface is verified as and extends the Shareable interface. OP.TYPE_ACCESS or OP.INVK_INTERFACE continue. If the Sharing attribute of OB.JAVAOBJECT to be accessed by S.APP is SIO and and the O.JAVAOBJECT's interface is not verified as or does not extends the Shareable interface. OP.TYPE_ACCESS or OP.INVK_INTERFACE is aborted. LifeTime (COD) Verify the LifeTime attribute of OB.JAVAOBJECT to be accessed by S.APP is COD If the LifeTime attribute of OB.JAVAOBJECT to be accessed by S.APP is COD and its Context is the same as the Selected applet Context. OP.ARRAY_ACCESS, OP.INSTANCE_FIELD, OP.INVK_VIRTUAL, OP.INVK_INTERFACE, OP.THROW or OP.TYPE_ACCESS continues. If the LifeTime attribute of OB.JAVAOBJECT to be accessed by Any subject is COD and its Context is not the same as the Selected applet Context. OP.JAVA, OP.CREATE is aborted. ] FDP_RIP.1 Subset residual information protection Hierarchical to: No other components Dependencies: No dependencies FDP_RIP.1.1 The TSF shall ensure that any previous information content of a resource is made unavailable upon the allocation of the resource to, deallocation of the resource from the [list of objects specified in the [Table 22]]: [ [Table 22] List of Objects Objects Applet instances and package Any Java Card transient object Cryptographic buffer ] FDP_SDI.2 Stored data integrity monitoring and action Hierarchical to: FDP_SDI.1 Stored data integrity monitoring [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 42/80 Dependencies: No dependencies 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 [user data attributes specified in the [Table 23]]: FDP_SDI.2.2 Upon detection of a data integrity error, the TSF shall [action specified in the [Table 23]]. [ [Table 23] Data integrity monitoring and action Data Attribute Action Package CRC32 definitely disables all the services of the card PIN CRC32 definitely disables all the services of the card Key CRC32 definitely disables all the services of the card Patch Table Check-Sum definitely disables all the services of the card ] FDP_UCT.1 Basic data exchange confidentiality Hierarchical to: No other components Dependencies: [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FDP_UCT.1.1 The TSF shall enforce the [CARD CONTENT MANAGEMENT access control SFP for the SCP02 and DM authentication] to be able to transmit and receive user data in a manner protected from unauthorized disclosure. FDP_UIT.1 Data exchange integrity Hierarchical to: No other components Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] [FTP_ITC.1 Inter-TSF trusted channel, or FTP_TRP.1 Trusted path] FDP_UIT.1.1 The TSF shall enforce the [CARD CONTENT MANAGEMENT access control SFP for the SCP02 and DM authentication] to be able to receive user data in a manner protected from modification, deletion, insertion, replay errors. FDP_UIT.1.1 The TSF shall be able to determine on receipt of user data, whether modification, deletion, insertion, replay has occurred. 6.1.4 Identification and Authentication FIA_AFL.1 Authentication failure handling Hierarchical to: No other components [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 43/80 Dependencies: FIA_UAU.1 Authentication FIA_AFL.1.1 The TSF shall detect when an administrator configurable positive integer within range of values specified in the [Table 24] unsuccessful authentication attempts occur related to [list of authentication events specified in the [Table 24]]. [ [Table 24] List of authentication events List of authentication events List of thresholds Authentication of any user of S.APP An administrator configurable positive integer within 1 and 255 Authentication of S.CM on behalf of card issuer 255 ] FIA_AFL.1.2 When the defined number of unsuccessful authentication attempts has been surpassed, the TSF shall [list of actions specified in the [Table 25]]. [ [Table 25] List of actions List of authentication events List of actions Authentication of any user of S.APP Temporarily lock the cardholder authentication service, until an unlocking action has been successfully undertaken by a privileged user Authentication of S.CM on behalf of card issuer definitely disables all the services of the card ] FIA_ATD.1(1) User attribute definition Hierarchical to: No other components Dependencies: No dependencies FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users. [ [Table 26] List of user security attributes User Security Attribute Any user of S.APP The AID and version number of each package The AID of each registered applet Whether a registered applet is currently selected for execution Card issuer of S.CM The Card Lifecycle for card content management The Security Level for card content management [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 44/80 The Privilege for card content management ] FIA_ATD.1(2) User attribute definition Hierarchical to: No other components Dependencies: No dependencies FIA_ATD.1.1 The TSF shall maintain the following list of security attributes belonging to individual users. [ [Table 27] List of user security attributes User Security Attribute Administrator User Identifier Authentication Data Role ] FIA_SOS.1 Verification of secrets Hierarchical to: No other components Dependencies: No dependencies FIA_SOS.1.1 The TSF shall provide a mechanism to verify that secrets meet [a defined quality metric specified in the [Table 28]]. [ [Table 28] List of verification of secrets secret List of metric PIN of any user of S.APP maximum length ( <= 8bytes) of PIN PIN value and retry counter is encrypted by an applet specific key KEY of S.CM on behalf of card issuer A maximum length (112bits) of TDES and maximum length (1024bits) of RSA KEY value is encrypted by an applet specific key ] Application Notes: The defined allowable standards will be minimum length, combination rule and modification cycle in the case of password authentication mechanism. FIA_UAU.1(1) Authentication Hierarchical to: No other components Dependencies: FIA_UID.1 Identification [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 45/80 FIA_UAU.1.1/SCP02 The TSF shall allow [list of TSF mediated actions specified in the [Table 29] in relation to SCP02] on behalf of the user to be performed before the user is authenticated. [ [Table 29] List of TSF mediated action Command Action Get Data reads data that identifies the card or the Card Issuer Manage Channel opens a logical channel with the card Select Applet selects an application on the card Initialize Update opens a secure communication channel with the card External Authenticate opens a secure communication channel with the card [Table 30] SCP02 Authentication Mechanism Description SCP02 Secure Channel Protocol 02 according to [R10] ] FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user in addition to FIA_UAU.1.1. Application Notes: This security functional requirement is authentication performed by S.CM with an aim of compelling CARD CONTENT MANAGEMENT access control SFP. S.CM authenticates external entities through the authentication of this security functional requirement. FIA_UAU.1(2) Authentication Hierarchical to: No other components Dependencies: FIA_UID.1 Identification FIA_UAU.1.1 The TSF shall allow [list of TSF mediated actions specified in the [Table 31] in relation to DAP] on behalf of the user to be performed before the user is authenticated. [ [Table 31] List of TSF mediated action Command Action Get Data reads data that identifies the card or the Card Issuer Manage Channel opens a logical channel with the card Select Applet selects an application on the card Initialize Update opens a secure communication channel with the card External Authenticate opens a secure communication channel with the card [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 46/80 Load Loads DAP Blocks for DAP Verification [Table 32] DAP Authentication Mechanism Description DAP Data Authentication Pattern according to [R10] ] FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user in addition to FIA_UAU.1.1. Application Notes: This security functional requirement is authentication performed by S.CM with an aim of compelling CARD CONTENT MANAGEMENT access control SFP. S.CM examines and authenticates the integrity of S.APP. FIA_UAU.1(3) Authentication Hierarchical to: No other components Dependencies: FIA_UID.1 Identification FIA_UAU.1.1 The TSF shall allow [list of TSF mediated actions specified in the [Table 33] in relation to DM] on behalf of the user to be performed before the user is authenticated. [ [Table 33] List of TSF mediated action Command Action Get Data reads data that identifies the card or the Card Issuer Manage Channel opens a logical channel with the card Select Applet selects an application on the card Initialize Update opens a secure communication channel with the card External Authenticate opens a secure communication channel with the card Load Loads Package Install Installs Package & Token Verification [Table 34] DM Authentication Mechanism Description DM Delegated management according to [R10] ] FIA_UAU.1.2 The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user in addition to FIA_UAU.1.1. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 47/80 Application Notes: This security functional requirement is authentication performed by S.CM with an aim of compelling CARD CONTENT MANAGEMENT access control SFP. S.CM authenticates special S.APP serving the role of S.CM. FIA_UAU.1(4) Authentication Hierarchical to: No other components Dependencies: FIA_UID.1 Identification FIA_UAU.1.1. The TSF shall allow [list of TSF mediated actions specified in the [Table 35] in relation to CVM] on behalf of the user to be performed before the user is authenticated. [ [Table 35] List of TSF mediated action Command Action Get Data reads data that identifies the card or the Card Issuer Manage Channel opens a logical channel with the card Select Applet selects an application on the card Verify invokes GPAPI_CVM_Verify according to [R10] ] FIA_UAU.1.2/CVM The TSF shall require each user to be successfully authenticated before allowing any other TSF-mediated actions on behalf of that user in addition to FIA_UAU.1.1. Application Notes: This security functional requirement is authentication performed by S.CM. FIA_UAU.4 Single-use authentication mechanisms Hierarchical to: No other components Dependencies: No dependencies FIA_UAU.4.1 The TSF shall prevent reuse of authentication data related to [authentication mechanisms specified in the [Table 36]]. [ [Table 36] List of authentication mechanism List of authentication mechanism Action SCP02 authentication mechanism uses random number and clear crypto buffer DAP authentication mechanism uses applet AID and clear crypto buffer DM authentication mechanism uses applet AID and clear crypto buffer CVM authentication mechanism verifies the PIN encrypted by the key specific to an applet and clear crypto buffer ] [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 48/80 Application Notes: Single-use authentication mechanisms can be applied to all users including authorized administrator and may not be used in services available within the range that does not violate the security policy. Prime examples of single-use authentication mechanism are one-time password and encrypted timestamp. FIA_UAU.6 Re-authenticating Hierarchical to: No other components Dependencies: No dependencies FIA_UAU.6.1 The TSF shall re-authenticate the user under the conditions [under which re- authentication is required specified in the [Table 37]]. [ [Table 37] Condition of Re-authenticating List Condition SCP02 after Card Manager is deselected after card session is closed (after card reset) DAP when any Package is loaded DM when any Package is loaded, installed CVM after applet is deselected after card session is closed (after card reset) ] Application Notes: The developer of the security target should describe conditions for re- authentication upon the normal or abnormal termination of services during the use of a smart card. FIA_UID.1 Identification Hierarchical to: No other components Dependencies: No dependencies FIA_UID.1.1 The TSF shall allow [list of TSF-mediated actions specified in the [Table 38]] on behalf of the user to be performed before the user is identified. [ [Table 38] List of TSF mediated action Command Action CheckChipData check card and get chip and OS data Get Data reads data that identifies the card or the Card Issuer Manage Channel opens a logical channel with the card Select Applet selects an application on the card ] [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 49/80 FIA_UID.1.2 The TSF shall require each user to be successfully identified before allowing any other TSF-mediated actions on behalf of that user in addition to FIA_UID.1.1. Application Notes: Within the range of TOE, the user is confined to the issuer, who should undergo identification and authentication before accessing TOE and using its functions in a way befitting his/her role. FIA_USB.1 User-subject binding Hierarchical to: No other components Dependencies: FIA_ATD.1 User attribute definition FIA_USB.1.1 The TSF shall associate the following user security attributes with subjects acting on the behalf of that user: [list of user security attributes specified in the [Table 39]]. [ [Table 39] Security attributes of User-subject User - Security Attribute Subject - Security Attribute Any user of S.APP - The AID and version number of each package - The AID of each registered applet - Whether a registered applet is currently selected for execution S.APP - The Context security attribute Card issuer of S.CM - The Card Lifecycle for card content management - The Security Level for card content management - The Privilege for card content management S.CM - The Lifecycle and Security Level and Privilege security attribute ] FIA_USB.1.2 The TSF shall enforce the following rules on the initial association of user security attributes with subjects acting on the behalf of users: [rules defined in FDP_ACF.1(1).1, FDP_ACF.1(2).1/ and FMT_MSA.3.1]. FIA_USB.1.3 The TSF shall enforce the following rules governing changes to the user security attributes associated with subjects acting on the behalf of users: [rules defined in FMT_MSA.1.1]. Application Notes: The user-subject binding is limited to descriptions on FIA_ATD.1(1) concerning the active entity within the TOE during TOE operation. 6.1.5 Security Management FMT_MOF.1 Management of security functions behavior Hierarchical to: No other components Dependencies: FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 50/80 FMT_MOF.1.1 The TSF shall restrict the ability to disable, enable, [management] the behavior of the functions [list of functions of S.CM’ operation specified in the [Table 40]] to [S.CM]. [ [Table 40] List of Security Functions Role Behavior Functions S.CM Load/Delete Package Load/Delete S.CM Enable/Disable Card Lock S.CM Enable Card Terminate ] Application Notes: This security functional requirement should be implemented to activate the functions of a smart card always via the issuer when the use of the smart card begins. At the same time, it should make sure that the issuer suspends the functions of the smart card when discontinuing the use of its functions. While using the smart card, the issuer may add, delete or modify applications. In this document, the term “package” includes application (or applet), and the modification of applications is confined to certain cases. In other words, it refers to the operation of installing, issuing and recording information on applications, which does not constitute the role of S.CM as it is performed by the issuer and is done using the functions of the given applications. FMT_MSA.1 (1) Management of security attributes Hierarchical to: No other components Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles FMT_MSA.1.1 The TSF shall enforce the [CARD CONTENT MANAGEMENT access control SFP] to restrict the ability to modify the security attributes [list of security attributes of subjects defined in FDP_ACF.1(1)] to [S.CM roles defined in FMT_SMR.1.1 ]. FMT_MSA.1 (2) Management of security attributes Hierarchical to: No other components Dependencies: [FDP_ACC.1 Subset access control, or FDP_IFC.1 Subset information flow control] FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles FMT_MSA.1.1 The TSF shall enforce the [FIREWALL access control SFP] to restrict the ability to modify the security attributes [list of security attributes of subjects defined in FDP_ACF.1(2)] to [S.JCRE roles defined in FMT_SMR.1.1 ]. FMT_MSA.3 Static attribute initialization Hierarchical to: No other components [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 51/80 Dependencies: FMT_MSA.1 Management of security attributes FMT_SMR.1 Security roles FMT_MSA.3.1 The TSF shall enforce the [CARD CONTENT MANAGEMENT access control SFP and FIREWALL access control SFP] to provide restrictive default values for security attributes that are used to enforce the SFP. FMT_MSA.3.2 The TSF shall allow the [S.CM role and S.JCRE role defined in FMT_SMR.1.1] to specify alternative initial values to override the default values when an object or information is created. FMT_MTD.1 MANAGEMENT OF TSF Data Hierarchical to: No other components Dependencies: FMT_SMF.1 Specification of Management Functions FMT_SMR.1 Security roles FMT_MTD.1.1 The TSF shall restrict the ability to modify the [list of TSF data specified in the [Table 41]] to [list of the authorized roles specified in the [Table 48]]. [ [Table 41] List of TSF data TSF data role Card Life Cycle S.CM Privilege S.CM KEY (DES-SCP02, DAP) S.CM KEY (RSA-DAP, DM) S.CM GLOBAL_PIN S.CM ] FMT_MTD.2 Management of limits on TSF data Hierarchical to: No other components Dependencies: FMT_MTD.1 MANAGEMENT OF TSF Data FMT_SMR.1 Security roles FMT_MTD.2.1 The TSF shall restrict the specification of the limits for [list of TSF data specified in the [Table 42]] to [list of the authorized roles specified in the [Table 49]]. FMT_MTD.2.2 The TSF shall take the [action specified in the [Table 42]], if the TSF data are at, or exceed, the indicated limits: [ [Table 42] List of limits for TSF data TSF data role Action Card Life Cycle S.CM Throw an error status word and terminate card Privilege S.CM Throw an error status word [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 52/80 KEY (DES- SCP02, DAP) Authentication Retry Counter S.CM Throw an error status word and close secure communication channel Key Size KEY (RSA- DAP, DM) Authentication Retry Counter S.CM Throw an error status word and close secure communication channel Key Size GLOBAL_PIN PIN retry counter S.CM Throw an error status word and block PIN PIN Size ] FMT_SMF.1 Specification of Management Functions Hierarchical to: No other components Dependencies: No dependencies FMT_SMF.1.1 The TSF shall be capable of performing the following security management functions: [list of security management functions to be provided by the TSF specified in the [Table 43]]. [ [Table 43] List of security management function of TSF List of Security Functions Card Life Cycle Management Package Load & Delete Card Security Level Management Privilege Management modify the active context and the selected context modify the list of registered applet’s AID Key Management PIN Management ] FMT_SMR.1 Security roles Hierarchical to: No other components Dependencies: FIA_UID.1 Identification FMT_SMR.1.1 The TSF shall maintain the roles [S.CM, S.APP, S.JCRE specified in the [Table 44]]. [ [Table 44] List of Security roles Role Description S.CM (Card Card Life Cycle Management [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 53/80 Manager) represents the card issuer Package Load & Delete Card Security Level Management Privilege Management Key Management PIN Management S.APP represents the card user Applet Life Cycle Management Applet PIN Management S.JCRE modify the active context and the selected context modify the list of registered applet’s AID ] FMT_SMR.1.2 The TSF shall be able to associate users with roles defined in FMT_SMR.1.1. Application Notes: Described here are the security roles of TOE during operation; TOE’s security role as administrator is the issuer, but such is not described in this security role. The smart card issuer plays the overall roles of an administrator for his/her smart card—by installing applications before using the smart card, receiving reports on failures during use and fixing the failures, and discarding the smart card upon the discontinuation of use. In this security target, the roles of the issuer may be transferred to another issuer through privilege management. 6.1.6 Privacy FPR_UNO.1 Unobservability Hierarchical to: No other components Dependencies: No dependencies FPR_UNO.1.1 The TSF shall ensure that [external entities] are unable to observe the operation [FCS_COP.1 Cryptographic operation, comparison of Keys and PIN] on [Keys and PIN] by [TSF]. Application Notes: An external entity may obtain and abuse cryptographic information from physical phenomena that take place during the cryptographic computation of TOE (e.g. change in current, voltage and electromagnetism). TOE encrypts keys and PINs and uses CRC32 and MAC to verify integrity and provide means to counter attacks like DFA. If this cannot be fully realized as TOE security functional requirement, the TOE operational environment (i.e. the cryptography- dedicated processor of the smart card IC chip, or the crypto library loaded onto the IC chip) may provide means to counter attacks like DPA and SPA. 6.1.7 Protection of the TSF FPT_FLS.1 Failure with preservation of secure state Hierarchical to: No other components Dependencies: No dependencies FPT_FLS.1.1 The TSF shall preserve a secure state when the following types of failures occur: [list of types of failures in the TSF]. Note: See the list of potential security violations in FAU_SAA.1 for [List of TSF failure types]. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 54/80 FPT_RCV.3 Automated recovery without undue loss Hierarchical to: FPT_RCV.2 Automated recovery Dependencies: AGD_OPE.1 Operational user guidance FPT_RCV.3.1 When automated recovery from [list of failures/service discontinuities specified in the [Table 45]] is not possible, the TSF shall enter a maintenance mode where the ability to return to a secure state is provided. [Table 45] List of failures/service discontinuities Security violation events Security exception limit excess Abort Transaction limit excess FPT_RCV.3.2 For [list of failures/service discontinuities specified in the [Table 46]], the TSF shall ensure the return of the TOE to a secure state using automated procedures. [Table 46] List of failures/service discontinuities Security violation events Abnormal environmental conditions (frequency, voltage, temperature) Physical tampering Card Manger life cycle inconsistency audited through the life cycle checks in all administrative operations Applet life cycle inconsistency Card tearing (unexpected removal of the Card out of the CAD) and power failure Abortion of a transaction in an unexpected context Violation of the Firewall or JCVM security policies Unavailability of resources Array overflow Access uninitialized key Security exception limit excess Abort Transaction limit excess Other runtime errors related to applet’s failure, like uncaught exceptions Randomness test for the random number generator is failed FPT_RCV.3.3 The functions provided by the TSF to recover from failure or service discontinuity shall ensure that the secure initial state is restored without exceeding [quantification of TSF data or objects during failures event] for loss of TSF data or objects under the control of the TSF. FPT_RCV.3.4 The TSF shall provide the capability to determine the objects that were or were not capable of being recovered. Note: See the list of potential security violations described in FAU_SAA.1 for [List of failures/service discontinuities]. FPT_RCV.4 Function recovery Hierarchical to: No other components Dependencies: No dependencies [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 55/80 FPT_RCV.4.1 The TSF shall ensure that [Reading from and writing to static and objects’ fields interrupted by Card tearing (unexpected removal of the Card out of the CAD) and power failure] have the property that the function either completes successfully, or for the indicated failure scenarios, recovers to a consistent and secure state. FPT_TST.1 TSF testing Hierarchical to: No other components Dependencies: No dependencies FPT_TST.1.1 The TSF shall run a suite of self tests during initial start-up, at the conditions[under normal operation] to demonstrate the correct operation of the TSF. [ [Table 47] List of self tests List of Self Tests Randomness test Integrity Test ] FPT_TST.1.2 The TSF shall provide authorized issuer with the capability to verify the integrity of TSF data. FPT_TST.1.3 The TSF shall provide authorized issuer with the capability to verify the integrity of [stored TSF executable code]. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 56/80 6.2 Assurance Requirements The assurance requirements of this Security Target are composed of assurance component in the Common Criteria Part3 and added the following assurance components. [Table 48] shows the assurance components. • ATE_DPT.2 Testing: security enforcing modules • AVA_VAN.4 Methodical vulnerability analysis [Table 48] Assurance Requirements Assurance Class Assurance Components ASE: Security Target ASE_INT.1 ST introduction ASE_CCL.1 Conformance claims ASE_SPD.1 Security problem definition ASE_OBJ.2 Security objectives ASE_ECD.1 Extended components definition ASE_REQ.2 Derived security requirements ASE_TSS.1 TOE summary specification ADV: Development ADV_ARC.1 Security architecture description ADV_FSP.4 Complete functional specification ADV_IMP.1 Implementation representation of the TSF ADV_TDS.3 Basic modular design AGD: Guidance documents AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ALC: Life-cycle support ALC_CMC.4 Production support, acceptance procedures and automation ALC_CMS.4 Problem tracking CM coverage ALC_DEL.1 Delivery procedures ALC_DVS.1 Identification of security measures ALC_LCD.1 Developer defined life-cycle model ALC_TAT.1 Well-defined development tools ATE: Tests ATE_COV.2 Analysis of coverage ATE_DPT.2 Testing: security enforcing modules ATE_FUN.1 Functional testing ATE_IND.2 Independent testing - sample [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 57/80 AVA: Vulnerability assessment AVA_VAN.4 Methodical vulnerability analysis 6.2.1 Security Target ASE_INT.1 ST introduction Dependencies: No dependencies Developer action elements ASE_INT.1.1D The developer shall provide an ST introduction. Content and presentation elements ASE_INT.1.1C The ST introduction shall contain an ST reference, a TOE reference, a TOE overview and a TOE description. ASE_INT.1.2C The ST reference shall uniquely identify the ST. ASE_INT.1.3C The TOE reference shall identify the TOE. ASE_INT.1.4C The TOE overview shall summarize the usage and major security features of the TOE. ASE_INT.1.5C The TOE overview shall identify the TOE type. ASE_INT.1.6C The TOE overview shall identify any non-TOE hardware/software/firmware required by the TOE. ASE_INT.1.7C The TOE description shall describe the physical scope of the TOE. ASE_INT.1.8C The TOE description shall describe the logical scope of the TOE. Evaluator action elements ASE_INT.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_INT.1.2E The evaluator shall confirm that the TOE reference, the TOE overview, and the TOE description are consistent with each other. ASE_CCL.1 Conformance claims Dependencies: ASE_INT.1 ST introduction ASE_ECD.1 Extended components definition ASE_REQ.1 Stated security requirements Developer action elements ASE_CCL.1.1D The developer shall provide a conformance claim. ASE_CCL.1.2D The developer shall provide a conformance claim rationale. Content and presentation elements ASE_CCL.1.1C The conformance claim shall contain a CC conformance claim that identifies the version of the CC to which the ST and the TOE claim conformance. ASE_CCL.1.2C The CC conformance claim shall describe the conformance of the ST to CC Part 2 as either CC Part 2 conformant or CC Part 2 extended. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 58/80 ASE_CCL.1.3C The CC conformance claim shall describe the conformance of the ST to CC Part 3 as either CC Part 3 conformant or CC Part 3 extended. ASE_CCL.1.4C The CC conformance claim shall be consistent with the extended components definition. ASE_CCL.1.5C The conformance claim shall identify all PPs and security requirement packages to which the ST claims conformance. ASE_CCL.1.6C The conformance claim shall describe any conformance of the ST to a package as either package-conformant or package-augmented. ASE_CCL.1.7C The conformance claim rationale shall demonstrate that the TOE type is consistent with the TOE type in the PPs for which conformance is being claimed. ASE_CCL.1.8C The conformance claim rationale shall demonstrate that the statement of the security problem definition is consistent with the statement of the security problem definition in the PPs for which conformance is being claimed. ASE_CCL.1.9C The conformance claim rationale shall demonstrate that the statement of security objectives is consistent with the statement of security objectives in the PPs for which conformance is being claimed. ASE_CCL.1.10C The conformance claim rationale shall demonstrate that the statement of security requirements is consistent with the statement of security requirements in the PPs for which conformance is being claimed. Evaluator action elements ASE_CCL.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_SPD.1 Security problem definition Dependencies: No Dependencies Developer action elements ASE_SPD.1.1D The developer shall provide a security problem definition. Content and presentation elements ASE_SPD.1.1C The security problem definition shall describe the threats. ASE_SPD.1.2C All threats shall be described in terms of a threat agent, an asset, and an adverse action. ASE_SPD.1.3C The security problem definition shall describe the OSPs. ASE_SPD.1.4C The security problem definition shall describe the assumptions about the operational environment of the TOE. Evaluator action elements ASE_SPD.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_OBJ.2 Security objectives Dependencies: ASE_SPD.1 Security problem definition Developer action elements ASE_OBJ.2.1D The developer shall provide a statement of security objectives. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 59/80 ASE_OBJ.2.2D The developer shall provide a security objectives rationale. Content and presentation elements ASE_OBJ.2.1C The statement of security objectives shall describe the security objectives for the TOE and the security objectives for the operational environment. ASE_OBJ.2.2C The security objectives rationale shall trace each security objective for the TOE back to threats countered by that security objective and OSPs enforced by that security objective. ASE_OBJ.2.3C The security objectives rationale shall trace each security objective for the operational environment back to threats countered by that security objective, OSPs enforced by that security objective, and assumptions upheld by that security objective. ASE_OBJ.2.4C The security objectives rationale shall demonstrate that the security objectives counter all threats. ASE_OBJ.2.5C The security objectives rationale shall demonstrate that the security objectives enforce all OSPs. ASE_OBJ.2.6C The security objectives rationale shall demonstrate that the security objectives for the operational environment uphold all assumptions. Evaluator action elements ASE_OBJ.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_ECD.1 Extended components definition Dependencies: No Dependencies Developer action elements ASE_ECD.1.1D The developer shall provide a statement of security requirements. ASE_ECD.1.2D The developer shall provide an extended components definition. Content and presentation elements ASE_ECD.1.1C The statement of security requirements shall identify all extended security requirements. ASE_ECD.1.2C The extended components definition shall define an extended component for each extended security requirement. ASE_ECD.1.3C The extended components definition shall describe how each extended component is related to the existing CC components, families, and classes. ASE_ECD.1.4C The extended components definition shall use the existing CC components, families, classes, and methodology as a model for presentation. ASE_ECD.1.5C The extended components shall consist of measurable and objective elements such that conformance or nonconformance to these elements can be demonstrated. Evaluator action elements ASE_ECD.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_ECD.1.2E The evaluator shall confirm that no extended component can be clearly expressed using existing components. ASE_REQ.2 Derived security requirements Dependencies: [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 60/80 ASE_OBJ.2 Security objectives ASE_ECD.1 Extended components definition Developer action elements ASE_REQ.2.1D The developer shall provide a statement of security requirements. ASE_REQ.2.2D The developer shall provide a rational for security requirements. Content and presentation elements ASE_REQ.2.1C The statement of security requirements shall describe the SFRs and the SARs. ASE_REQ.2.2C All subjects, objects, operations, security attributes, external entities and other terms that are used in the SFRs and the SARs shall be defined. ASE_REQ.2.3C The statement of security requirements shall identify all operations on the security requirements. ASE_REQ.2.4C All operations shall be performed correctly. ASE_REQ.2.5C Each dependency of the security requirements shall either be satisfied, or the security requirements rationale shall justify the dependency not being satisfied. ASE_REQ.2.6C The security requirements rationale shall trace each SFR back to the security objectives for the TOE. ASE_REQ.2.7C The security requirements rationale shall demonstrate that the SFRs meet all security objectives for the TOE. ASE_REQ.2.8C The security requirements rationale shall explain why the SARs were chosen. ASE_REQ.2.9C The statement of security requirements shall be internally consistent. Evaluator action elements ASE_REQ.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_TSS.1 TOE summary specification Dependencies: ASE_INT.1 ST introduction ASE_REQ.1 Stated security requirements ADV_FSP.1 Basic functional specification Developer action elements ASE_TSS.1.1D The developer shall provide a TOE summary specification. Content and presentation elements ASE_TSS.1.1C The TOE summary specification shall describe how the TOE meets each SFR. Evaluator action elements ASE_TSS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ASE_TSS.1.2E The evaluator shall confirm that the TOE summary specification is consistent with the TOE overview and the TOE description. 6.2.2 Development ADV_ARC.1 Security architecture description [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 61/80 Dependencies: ADV_FSP.1 Basic functional specification ADV_TDS.1 Basic design Developer action elements ADV_ARC.1.1D The developer shall design and implement the TOE so that the security features of the TSF cannot be bypassed. ADV_ARC.1.2D The developer shall design and implement the TSF so that it is able to protect itself from tampering by untrusted active entities. ADV_ARC.1.3D The developer shall provide a security architecture description of the TSF. Content and presentation elements ADV_ARC.1.1C The security architecture description shall be at a level of detail commensurate with the description of the SFR-enforcing abstractions described in the TOE design document. ADV_ARC.1.2C The security architecture description shall describe the security domains maintained by the TSF consistently with the SFRs. ADV_ARC.1.3C The security architecture description shall describe how the TSF initialization process is secure. ADV_ARC.1.4C The security architecture description shall demonstrate that the TSF protects itself from tampering. ADV_ARC.1.5C The security architecture description shall demonstrate that the TSF prevents bypass of the SFR-enforcing functionality. Evaluator action elements ADV_ARC.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_FSP.4 Complete functional specification Dependencies: ADV_TDS.1 Basic design Developer action elements ADV_FSP.4.1D The developer shall provide a functional specification. ADV_FSP.4.2D The developer shall provide a tracing from the functional specification to the SFRs. Content and presentation elements ADV_FSP.4.1C The functional specification shall completely represent the TSF. ADV_FSP.4.2C The functional specification shall describe the purpose and method of use for all TSFI. ADV_FSP.4.3C The functional specification shall identify and describe all parameters associated with each TSFI. ADV_FSP.4.4C The functional specification shall describe all actions associated with each TSFI. ADV_FSP.4.5C The functional specification shall describe all direct error messages that may result from an invocation of each TSFI. ADV_FSP.4.6C The tracing shall demonstrate that the SFRs trace to TSFIs in the functional specification. Evaluator action elements [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 62/80 ADV_FSP.4.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_FSP.4.2E The evaluator shall determine that the functional specification is an accurate and complete instantiation of the SFRs. ADV_IMP.1 Implementation representation of the TSF Dependencies: ADV_TDS.3 Basic modular design ALC_TAT.1 Well-defined development tools Developer action elements ADV_IMP.1.1D The developer shall make available the implementation representation for the entire TSF. ADV_IMP.1.2D The developer shall provide a mapping between the TOE design description and the sample of the implementation representation. Content and presentation elements ADV_IMP.1.1C The implementation representation shall define the TSF to a level of detail such that the TSF can be generated without further design decisions. ADV_IMP.1.2C The implementation representation shall be in the form used by the development personnel. ADV_IMP.1.3C The mapping between the TOE design description and the sample of the implementation representation shall demonstrate their correspondence. Evaluator action elements ADV_IMP.1.1E The evaluator shall confirm that, for the selected sample of the implementation representation, the information provided meets all requirements for content and presentation of evidence. ADV_TDS.3 Basic modular design Dependencies: ADV_FSP.4 Complete functional specification Developer action elements ADV_TDS.3.1D The developer shall provide the design of the TOE. ADV_TDS.3.2D The developer shall provide a mapping from the TSFI of the functional specification to the lowest level of decomposition available in the TOE design. Content and presentation elements ADV_TDS.3.1C The design shall describe the structure of the TOE in terms of subsystems. ADV_TDS.3.2C The design shall describe the TSF in terms of modules. ADV_TDS.3.3C The design shall identify all subsystems of the TSF. ADV_TDS.3.4C The design shall provide a description of each subsystem of the TSF. ADV_TDS.3.5C The design shall provide a description of the interactions among all subsystems of the TSF. ADV_TDS.3.6C The design shall provide a mapping from the subsystems of the TSF to the modules of the TSF. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 63/80 ADV_TDS.3.7C The design shall describe each SFR-enforcing module in terms of its purpose and relationship with other modules. ADV_TDS.3.8C The design shall describe each SFR-enforcing module in terms of its SFR-related interfaces, return values from those interfaces, interaction with other modules and called SFR- related interfaces to other SFR-enforcing modules. ADV_TDS.3.9C The design shall describe each SFR-supporting or SFR-non-interfering module in terms of its purpose and interaction with other modules. ADV_TDS.3.10C The mapping shall demonstrate that all TSFIs trace to the behavior described in the TOE design that they invoke. Evaluator action elements ADV_TDS.3.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ADV_TDS.3.2E The evaluator shall determine that the design is an accurate and complete instantiation of all security functional requirements. 6.2.3 Guidance documents AGD_OPE.1 Operational user guidance Dependencies: ADV_FSP.1 Basic functional specification Developer action elements AGD_OPE.1.1D The developer shall provide operational user guidance. Content and presentation elements AGD_OPE.1.1C The operational user guidance shall describe, for each user role, the user- accessible functions and privileges that should be controlled in a secure processing environment, including appropriate warnings. AGD_OPE.1.2C The operational user guidance shall describe, for each user role, how to use the available interfaces provided by the TOE in a secure manner. AGD_OPE.1.3C The operational user guidance shall describe, for each user role, the available functions and interfaces, in particular all security parameters under the control of the user, indicating secure values as appropriate. AGD_OPE.1.4C The operational user guidance shall, for each user role, clearly present each type of security-relevant event relative to the user-accessible functions that need to be performed, including changing the security characteristics of entities under the control of the TSF. AGD_OPE.1.5C The operational user guidance shall identify all possible modes of operation of the TOE (including operation following failure or operational error), their consequences and implications for maintaining secure operation. AGD_OPE.1.6C The operational user guidance shall, for each user role, describe the security measures to be followed in order to fulfill the security objectives for the operational environment as described in the ST. AGD_OPE.1.7C The operational user guidance shall be clear and reasonable. Evaluator action elements AGD_OPE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 64/80 AGD_PRE.1 Preparative procedures Dependencies: No Dependencies Developer action elements AGD_PRE.1.1D The developer shall provide the TOE including its preparative procedures. Content and presentation elements AGD_PRE.1.1C The preparative procedures shall describe all the steps necessary for secure acceptance of the delivered TOE in accordance with the developer's delivery procedures. AGD_PRE.1.2C The preparative procedures shall describe all the steps necessary for secure installation of the TOE and for the secure preparation of the operational environment in accordance with the security objectives for the operational environment as described in the ST. Evaluator action elements AGD_PRE.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AGD_PRE.1.2E The evaluator shall apply the preparative procedures to confirm that the TOE can be prepared securely for operation. 6.2.4 Life-cycle support ALC_CMC.4 Production support, acceptance procedures and automation Dependencies: ALC_CMS.1 TOE CM coverage ALC_DVS.1 Identification of security measures ALC_LCD.1 Developer defined life-cycle model Developer action elements ALC_CMC.4.1D The developer shall provide the TOE and a reference for the TOE. ALC_CMC.4.2D The developer shall provide the CM documentation. ALC_CMC.4.3D The developer shall use a CM system. Content and presentation elements ALC_CMC.4.1C The TOE shall be labeled with its unique reference. ALC_CMC.4.2C The CM documentation shall describe the method used to uniquely identify the configuration items. ALC_CMC.4.3C The CM system shall uniquely identify all configuration items. ALC_CMC.4.4C The CM system shall provide automated measures such that only authorized changes are made to the configuration items. ALC_CMC.4.5C The CM system shall support the production of the TOE by automated means. ALC_CMC.4.6C The CM documentation shall include a CM plan. ALC_CMC.4.7C The CM plan shall describe how the CM system is used for the development of the TOE. ALC_CMC.4.8C The CM plan shall describe the procedures used to accept modified or newly created configuration items as part of the TOE. ALC_CMC.4.9C The evidence shall demonstrate that all configuration items are being maintained under the CM system. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 65/80 ALC_CMC.4.10C The evidence shall demonstrate that the CM system is being operated in accordance with the CM plan. Evaluator action elements ALC_CMC.4.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ALC_CMS.4 Problem tracking CM coverage Dependencies: No Dependencies Developer action elements ALC_CMS.4.1D The developer shall provide a configuration list for the TOE. Content and presentation elements ALC_CMS.4.1C The configuration list shall include the following: the TOE itself; the evaluation evidence required by the SARs; the parts that comprise the TOE; the implementation representation; and security flaw reports and resolution status. ALC_CMS.4.2C The configuration list shall uniquely identify the configuration items. ALC_CMS.4.3C For each TSF relevant configuration item, the configuration list shall indicate the developer of the item. Evaluator action elements ALC_CMS.4.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ALC_DEL.1 Delivery procedures Dependencies: No Dependencies Developer action elements ALC_DEL.1.1D The developer shall document and provide procedures for delivery of the TOE or parts of it to the consumer. ALC_DEL.1.2D The developer shall use the delivery procedures. Content and presentation elements ALC_DEL.1.1C The delivery documentation shall describe all procedures that are necessary to maintain security when distributing versions of the TOE to the consumer. Evaluator action elements ALC_DEL.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ALC_DVS.1 Identification of security measures Dependencies: No Dependencies Developer action elements ALC_DVS.1.1D The developer shall produce and provide development security documentation. Content and presentation elements ALC_DVS.1.1C The development security documentation shall describe all the physical, procedural, personnel, and other security measures that are necessary to protect the confidentiality and integrity of the TOE design and implementation in its development environment. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 66/80 Evaluator action elements ALC_DVS.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ALC_DVS.1.2E The evaluator shall confirm that the security measures are being applied. ALC_LCD.1 Developer defined life-cycle model Dependencies: No Dependencies Developer action elements ALC_LCD.1.1D The developer shall establish a life-cycle model to be used in the development and maintenance of the TOE. ALC_LCD.1.2D The developer shall provide life-cycle definition documentation. Content and presentation elements ALC_LCD.1.1C The life-cycle definition documentation shall describe the model used to develop and maintain the TOE. ALC_LCD.1.2C The life-cycle model shall provide for the necessary control over the development and maintenance of the TOE. Evaluator action elements ALC_LCD.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ALC_TAT.1 Well-defined development tools Dependencies: ADV_IMP.1 Implementation representation of the TSF Developer action elements ALC_TAT.1.1D The developer shall provide the documentation identifying each development tool being used for the TOE. ALC_TAT.1.2D The developer shall document and provide the selected implementation-dependent options of each development tool. Content and presentation elements ALC_TAT.1.1C Each development tool used for implementation shall be well-defined. ALC_TAT.1.2C The documentation of each development tool shall unambiguously define the meaning of all statements as well as all conventions and directives used in the implementation. ALC_TAT.1.3C The documentation of each development tool shall unambiguously define the meaning of all implementation-dependent options. Evaluator action elements ALC_TAT.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. 6.2.5 Tests ATE_COV.2 Analysis of coverage Dependencies: ADV_FSP.2 Security-enforcing functional specification ATE_FUN.1 Functional testing [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 67/80 Developer action elements ATE_COV.2.1D The developer shall provide an analysis of the test coverage. Content and presentation elements ATE_COV.2.1C The analysis of the test coverage shall demonstrate the correspondence between the tests in the test documentation and the TSFIs in the functional specification. ATE_COV.2.2C The analysis of the test coverage shall demonstrate that all TSFIs in the functional specification have been tested. Evaluator action elements ATE_COV.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_DPT.2 Testing: security enforcing modules Dependencies: ADV_ARC.1 Security architecture description ADV_TDS.3 Basic modular design ATE_FUN.1 Functional testing Developer action elements ATE_DPT.2.1D The developer shall provide the analysis of the depth of testing. Content and presentation elements ATE_DPT.2.1C The analysis of the depth of testing shall demonstrate the correspondence between the tests in the test documentation and the TSF subsystems and SFR-enforcing modules in the TOE design. ATE_DPT.2.2C The analysis of the depth of testing shall demonstrate that all TSF subsystems in the TOE design have been tested. ATE_DPT.2.3C The analysis of the depth of testing shall demonstrate that the SFR-enforcing modules in the TOE design have been tested. Evaluator action elements ATE_DPT.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_FUN.1 Functional tests Dependencies ATE_COV.1 Evidence of coverage Developer action elements ATE_FUN.1.1D The developer shall test the TSF and document the results. ATE_FUN.1.2D The developer shall provide test documentation. Content and presentation elements ATE_FUN.1.1C The test documentation shall consist of test plans, expected test results and actual test results. ATE_FUN.1.2C The test plans shall identify the tests to be performed and describe the scenarios for performing each test. These scenarios shall include any ordering dependencies on the results of other tests. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 68/80 ATE_FUN.1.3C The expected test results shall show the anticipated outputs from a successful execution of the tests. ATE_FUN.1.4C The actual test results shall be consistent with the expected test results. Evaluator action elements ATE_FUN.1.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.2 Independent testing - sample Dependencies: ADV_FSP.2 Security-enforcing functional specification AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ATE_COV.1 Evidence of coverage ATE_FUN.1 Functional testing Developer action elements ATE_IND.2.1D The developer shall provide the TOE for testing. Content and presentation elements ATE_IND.2.1C The TOE shall be suitable for testing. ATE_IND.2.2C The developer shall provide an equivalent set of resources to those that were used in the developer's functional testing of the TSF. Evaluator action elements ATE_IND.2.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. ATE_IND.2.2E The evaluator shall execute a sample of tests in the test documentation to verify the developer test results. ATE_IND.2.3E The evaluator shall test a subset of the TSF to confirm that the TSF operates as specified. 6.2.6 Vulnerability assessment AVA_VAN.4 Methodical vulnerability analysis Dependencies: ADV_ARC.1 Security architecture description ADV_FSP.4 Complete functional specification ADV_TDS.3 Basic modular design ADV_IMP.1 Implementation representation of the TSF AGD_OPE.1 Operational user guidance AGD_PRE.1 Preparative procedures ATE_DPT.1 Testing: basic design Developer action elements AVA_VAN.4.1D The developer shall provide the TOE for testing. Content and presentation elements [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 69/80 AVA_VAN.4.1C The TOE shall be suitable for testing. Evaluator action elements AVA_VAN.4.1E The evaluator shall confirm that the information provided meets all requirements for content and presentation of evidence. AVA_VAN.4.2E The evaluator shall perform a search of public domain sources to identify potential vulnerabilities in the TOE. AVA_VAN.4.3E The evaluator shall perform an independent, methodical vulnerability analysis of the TOE using the guidance documentation, functional specification, TOE design, security architecture description and implementation representation to identify potential vulnerabilities in the TOE. AVA_VAN.4.4E The evaluator shall conduct penetration testing based on the identified potential vulnerabilities to determine that the TOE is resistant to attacks performed by an attacker possessing Moderate attack potential. 6.3 Security Requirements Rationale This section proves that security requirements are suited to fulfill the security objectives described in section 4 and adequate to handle the security problem. 6.3.1 Security Functional Requirements Rationale The security requirements rationale proves the followings: • Each security objective is handled by at least one security functional requirements. • Each security functional requirements handle at least one security objective. [Table 49] Mapping of security functional requirements and security objectives Security Objectives Security Functional requirements O.Data Protection O.Issue O.Identification O.Authorized Repair O.Authentication O.Rollback O.Rem_Residue O.Leak Countermeasure O.Open Platform FAU_ARP.1 X X FAU_SAA.1 X X FCS_CKM.1 X FCS_CKM.4 X X FCS_COP.1(1) X FCS_COP.1(2) X FCS_COP.1(3) X FDP_ACC.2(1) X X X FDP_ACC.2(2) X X FDP_ACF.1(1) X X X FDP_ACF.1(2) X X X FDP_RIP.1 X X [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 70/80 FDP_SDI.2 X X FDP_UCT.1 X X FDP_UIT.1 X X X FIA_AFL.1 X X X FIA_ATD.1(1) X X X X FIA_ATD.1(2) X X X X FIA_SOS.1 X FIA_UAU.1(1) X X X X FIA_UAU.1(2) X X X X FIA_UAU.1(3) X X X X FIA_UAU.1(4) X X FIA_UAU.4 X X X FIA_UAU.6 X X X FIA_UID.1 X X X X FIA_USB.1 X FMT_MOF.1 X X FMT_MSA.1(1) X X FMT_MSA.1(2) X X FMT_MSA.3 X FMT_MTD.1 X FMT_MTD.2 X FMT_SMF.1 X FMT_SMR.1 X X X X FPR_UNO.1 X FPT_FLS.1 X FPT_RCV.3 X FPT_RCV.4 X FPT_TST.1 X X FAU_ARP.1 Security alarms This component ensures that detects potential security violation and performs adequate reactions. Thus it satisfies the security objective of O.Authorized Repair and O.Authentication. FAU_SAA.1 Potential violation analysis This component ensures to indicate a security violation and monitor the audited events. Thus it satisfies the security objective of O.Authorized Repair and O.Authentication. FCS_CKM.1 Cryptographic key generation This component ensures to generate the cryptographic key in accordance with defined cryptographic algorithm and size of key. Thus it satisfies the security objective of O.Authentication. FCS_CKM.4 Cryptographic key destruction This component ensures to destroy the cryptographic key in accordance with defined destruction method. Thus it satisfies the security objective of O.Authentication and O.Rem_Residue. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 71/80 FCS_COP.1(1) ~ (3) Cryptographic operation This component ensures that the cryptographic operation is performed in accordance with defined cryptographic algorithm and size of key. Thus it satisfies the security objective of O.Authentication. FDP_ACC.2(1) ~ (2) Complete access control This component ensures to define the security policy for TOE access control and the scope of the security policy. Thus it satisfies the security objective of O.Issue, O.Data Protection and O.Open Platform. FDP_ACC.2(1) is the requirements of access control for Card Content Management and satisfies the security objective of O.Issue, O.Data Protection and O.Open Platform. FDP_ACC.2(2) is the requirements of access control for Firewall Access Control and satisfies the security objective of O.Data Protection and O.Open Platform. Note: Loading, Installing and Deleting of Package is the part of the issue process. FDP_ACF.1(1) ~ (2)Security attribute based access control This component ensures that the security attribute based the access control policy is performed. Thus it satisfies the security objective of O.Data Protection, O.Issue, O.Identification and O.Open Platform. FDP_ACF.1(1) is the security attribute for Card Content Management and satisfies the security objective of O.Data Protection, O.Issue and O.Open Platform. FDP_ACF.1(2) is the security attribute for Firewall Access Control and satisfies the security objective of O.Data Protection, O.Identification and O.Open Platform. FDP_RIP.1 Subset residual information protection This component ensures that it is not available the remainder information of all resource related to the defined subset of controlled objects when the TSF perform the allocation and deallocation of resource. Thus it satisfies the security objective of O.Rem_Residue and O.Open Platform. FDP_SDI.2. Stored data integrity monitoring and action This component is the stored data integrity monitoring and action and ensures that the TOE monitors user data in the store area controlled by TSF and performs the action that must perform as the result of the error detection. Thus it satisfies the security objective of O.Authentication and O.Leak Countermeasure. FDP_UCT.1 Basic data exchange confidentiality This component ensures the requirement for the confidentiality of the transferred data for protection from unauthorized disclosure of user data while in transit. Thus it satisfies the security objective of O.Leak Countermeasure and O.Open Platform. FDP_UIT.1 Data exchange integrity This component ensures the integrity requirement as the integrity of transferred data for detecting the failure against modification, deletion, insertion and reuse of the user data that was transmitted. Thus it satisfies the security objective of O.Data Protection, O.Leak Countermeasure and O.Open Platform. FIA_AFL.1 Authentication failure handling [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 72/80 This component ensures that define the authentication attempt failure number of user and that perform the action when defined limits is surpassed. Thus it satisfies the security objective of O.Issue, O.Authorized Repair and O.Authentication. FIA_ATD.1(1) ~ (2) User attribute definition This component defines the list of security attribute of each user. Thus it satisfies the security objective of O.Issue, O.Identification, O.Authorized Repair and O.Authentication. FIA_SOS.1 Verification of secrets This component provides the mechanism to verify that secrets meet defined quality metrics. Thus it satisfies the security objective of O.Authentication. FIA_UAU.1(1) ~ (3) Authentication This component ensures the ability to authenticate successfully the user. Thus it satisfies the security objective of O.Data Protection, O.Issue, O.Authorized Repair and O.Authentication. Note: It is the authentication for Card Content Management and satisfy O.Data Protection, O.Issue, O.Authorized Repair and O.Authentication. FIA_UAU.1 (4) Authentication This component ensures the ability to authenticate successfully the user. Thus it satisfies the security objective of O.Identification and O.Authentication. Note: It is the authentication for CVM Management and satisfy O.Identification and O.Authentication. CVM Management control the operation related to Global PIN/PIN management of Card Manager and provide the means to identify and verify the user using PIN. Refer to 7.1.4.2 PIN Authentication for details FIA_UAU.4 Single-use authentication mechanisms This component ensures the ability to prevent the reuse of authentication data. Thus it satisfies the security objective of O.Issue, O.Authorized Repair, O.Authentication. FIA_UAU.6 Re-authenticating This component ensures the ability to state the event to need the re-authentication of user. Thus it satisfies the security objective of O.Issue, O.Authorized Repair, O.Authentication. FIA_UID.1 Identification This component allows that user performs any operation before user is identified by the TSF. Thus it satisfies the security objective of O.Data Protection, O.Issue, O.Identification and O.Authorized Repair. FIA_USB.1 User-subject binding This component ensures the ability to manage association between the user security attributes and the subjects acting on the behalf of that user. Thus it satisfies the security objective of O.Data Protection. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 73/80 FMT_MOF.1 Management of security functions behavior This component ensures the ability that the authorized user manage the security function. Thus it satisfies the security objective of O.Data Protection and O.Open Platform. FMT_MSA.1(1) ~ (2) Management of security attributes This component ensures that the authorized administrator manage the security attribute for the access control and the information flow control policy. Thus it satisfies the security objective of O.Data Protection, O.Issue and O.Identification. FMT_MSA.1(1) is the management of the security attribute for Card Content Management and satisfies the security objective of O.Data Protection and O.Issue. FMT_MSA.1(2) is the management of the security attribute for Firewall Access Control and satisfies the security objective of O.Data Protection and O.Identification. FMT_MSA.3 Static attribute initialization This component provides the initial value for the access control and the information flow control policy. Thus it satisfies the security objective of O.Data Protection. FMT_MTD.1 Management of TSF data This component provides the ability that the authorized administrator manage the TSF data. Thus it satisfies the security objective of O.Issue. FMT_MTD.2 Management of limits on TSF data This component ensures that the authorized administrator manage the limits of TSF data and that perform the action when the defined limits is surpassed. Thus it satisfies the security objective of O.Issue. FMT_SMF.1 Specification of Management Functions This component requires that specify the security functions that TSF perform and the management functions for the security attribute and the TSF. Thus it satisfies the security objective of O.Issue. FMT_SMR.1 Security roles This component ensures that a user relate to the role authorized administrator. Thus it satisfies the security objective of O.Issue, O.Identification, O.Authorized Repair and O.Authentication. FPR_UNO.1 Unobservability This component ensures that the external entity cannot discover the information related to cryptogram by abuse the physical phenomena (electric current, voltage, an electromagnetism change) that occur when the TSF performs cryptographic operations. Thus it satisfies the security objective of O.Leak Countermeasure. FPT_FLS.1 Failure with preservation of secure state This component ensures that TSF preserve the secure state when defined failure occur. Thus it satisfies the security objective of O.Rollback. FPT_RCV.3 Automated recovery without undue loss [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 74/80 This component provides automated recovery function and does not accept undue loss of the protected object. Thus it satisfies the security objective of O.Rollback. FPT_RCV.4 Function recovery This component ensures that provide recovery of the special function. And ensure that completes or recovers successfully the TSF data to the secure state. Thus it satisfies the security objective of O.Rollback. FPT_TST.1 TSF testing This component ensures self-testing for the correct operation of the TSF and verifying the integrity of the TSF data and TSF executable code. Thus it satisfies the security objective of O.Data Protection and O.Rollback. 6.3.2 Assurance Requirements Rationale The evaluation assurance level of this security target is EAL4+. Below are the assurance components added: • ATE_DPT.2 Testing: security enforcing modules • AVA_VAN.4 Methodical vulnerability analysis EAL4 is an assurance package requiring systematic design, testing and examination, enabling developers to gain as much assurance as possible from practical security engineering based on solid commercial development methodology, which is precise but does not require a vast amount of expertise, technology or other resources. EAL4 is the highest grade where the renewal of existing production lines is economically viable. EAL4 is applicable when developers or users require a medium or high level of independently guaranteed security for the conventional commercial TOE and are willing to pay more for security engineering. To understand security behaviors, EAL4 provides configuration management including functions, complete interface specification, module design descriptions, expressions on the implementation of parts of TSF, testing and automation. TOE is developed based on the open standard specification for implementation, so information on TOE design/operation can be easily obtained. Used in the open environment, it is easily accessible and can hardly track potential attacks. No understanding of hardware structure and sophisticated special equipment are needed, however, as the IC chip is not included in the TOE scope. Given these aspects of resource, motivation and expertise, the TOE should deal with attackers with medium levels of possibility for successful attack. EAL4 includes AVA_VAN.3 that corresponds to improved possibilities of successful basic attack, so AVA_VAN.4 (methodical vulnerability analysis) is added to undertake resistance analysis on attackers with medium possibilities of success as well as systematic vulnerability analysis on TOE module design documents and TSF implementation expressions. For vulnerability analysis on TOE module design, tests on the security-execution module at least should be carried out, so ATE_DPT.2 is added here. Nevertheless, there still remain possibilities of direct attacks to the IC chip from sophisticated technology-based threat agents, and evaluation and verification in this regard may be fully commissioned to the IC chip manufacturers. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 75/80 6.4 Dependencies Rationale 6.4.1 Dependencies of the Security Functional Requirements [Table 50] Dependencies of the functional components Num. Functional Component Dependencies Num. of Ref. 1 FAU_ARP.1 FAU_SAA.1 2 2 FAU_SAA.1 FAU_GEN.1 none 3 FCS_CKM.1 [FCS_CKM.2 or FCS_COP.1] FCS_CKM.4 [- or 5] 4 4 FCS_CKM.4 [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], [- or - or 3] 5 FCS_COP.1 [FDP_ITC.1 or FDP_ITC.2 or FCS_CKM.1], FCS_CKM.4 [- or - or 3], 4 6 FDP_ACC.2 FDP_ACF.1 7 7 FDP_ACF.1 FDP_ACC.1, FMT_MSA.3 6, 22 8 FDP_RIP.1 - - 9 FDP_SDI.2 - 10 FDP_UCT.1 [FDP_ACC.1 or FDP_IFC.1] [FTP_ITC.1 or FTP_TRP.1] 6 - 11 FDP_UIT.1 [FDP_ACC.1 or FDP_IFC.1] [FTP_ITC.1 or FTP_TRP.1] 6 - 12 FIA_AFL.1 FIA_UAU.1 15 13 FIA_ATD.1 - - 14 FIA_SOS.1 - - 15 FIA_UAU.1 FIA_UID.1 18 16 FIA_UAU.4 - - 17 FIA_UAU.6 - - 18 FIA_UID.1 - - 19 FIA_USB.1 FIA_ATD.1 13 20 FMT_MOF.1 FMT_SMF.1, FMT_SMR.1 25, 26 21 FMT_MSA.1 [FDP_ACC.1 or FDP_IFC.1] FMT_SMF.1, FMT_SMR.1 [6 or -] 25, 26 22 FMT_MSA.3 FMT_MSA.1, FMT_SMR.1 21, 26 23 FMT_MTD.1 FMT_SMF.1, FMT_SMR.1 25, 26 24 FMT_MTD.2 FMT_MTD.1, FMT_SMR.1 23, 26 25 FMT_SMF.1 - - 26 FMT_SMR.1 FIA_UID.1 18 27 FPR_UNO.1 - - 28 FPT_FLS.1 - - 29 FPT_RCV.3 AGD_OPE.1 EAL4 30 FPT_RCV.4 - - 31 FPT_TST.1 - - [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 76/80 Dependent upon FAU_SAA.1, FAU_GEN.1 is not satisfied. A smart card does not have enough space for recording security events. Excessive security auditing may put the safety of the card at risk, so security events are not recorded. Therefore, this protection profile does not define the requirements of FAU_GEN.1. FDP_ACF.1, FMT_MSA.1 is dependent upon FDP_ACC.1, which is satisfied by FDP_ACC.2 in a hierarchical relationship with FDP_ACC.1. Dependent upon FDP_UCT.1 and FDP_UIT.1, FTP_ITC.1 and FTP_TRP.1 are not included here. FDP_UCT.1 and FDP_UIT.1 require a safe communication channel between the interpretation system and the TOE, but this safe communication is the only channel here and thus does not have to be logically distinguished from other communication channels. For this reason, this security target does not define the requirements of FTP_ITC.1. Also, FDP_ACC.1 and FDP_IFC.1, which are dependent upon FDP_UCT.1 and FDP_UIT.1, are satisfied by FDP_ACC.2 which is in a hierarchical relationship with FDP_ACC.1. 6.4.2 Dependencies of the Assurance Requirements All the dependencies of the EAL4 assurance package offered in the Common Criteria for the Information Protection System, so the theoretical rationale for this package is not specified here. The dependencies of added assurance requirements are outlined in [Table 51], and this security target meets the dependencies of all the assurance requirements. [Table 51] Dependencies of the added assurance requirements # Assurance Component Dependency Reference Number 1 ATE_DPT.2 ADV_ARC.1 ADV_TDS.3 ATE_FUN.1 EAL4 EAL4 EAL4 2 AVA_VAN.4 ADV_ARC.1 ADV_FSP.4 ADV_TDS.3 ADV_IMP.1 AGD_OPE.1 AGD_PRE.1 EAL4 EAL4 EAL4 EAL4 EAL4 EAL4 [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 77/80 7. TOE Summary Specification This section provides a description of the security functionality of the TOE that meet the TOE security requirements. 7.1 TOE Security Functionality This section describes the security functionality of TOE that meets the security requirements. The security functionality of TOE can be broadly divided into: [Security Audit, Cryptographic Support, User Data Protection, Identification and Authentication, Security Management, Privacy and TSF Protection]. This section describes how the TOE meets its security functionality. The followings are the security functionality of TOE: 7.1.1 Security Audit TOE detects potential security violations such as the check sum values of internal data, errors in resource allocation and authentication failure events, resetting TOE operations or suspending TOE functions either temporarily or permanently. 7.1.2 Cryptographic Support TOE performs cryptographic computation such as cryptographic key generation/destruction, encryption, decryption, and electronic signature generation and verification. It also supports hash value generation and random number generation. 7.1.3 User Data Protection TOE provides card content manager and access control policies based on security attributes through Card Manager. Through JCRE, it offers firewall access control policies for all computations made in the Java Card system and between applets and data on the basis of the security attribute “Context.” 7.1.4 Identification and Authentication TOE undertakes card administrator authentication through Secure Channel Protocol (SCP 02). It also performs authentication of application providers and issuers through data authentication pattern (DAP) authentication and delegated management (DM) authentication. TOE provides means to authenticate users with PIN and controls Card Manager’s operations related to global PIN/PIN management. 7.1.5 Security Management TOE offers the function of managing security attributes for card content management through Card Manager. Through JCRE, it serves to manage security attributes for providing firewall access control security policies. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 78/80 7.1.6 Privacy TOE provides the tools to offer unobservability for external attacks during cryptographic computation. 7.1.7 Protection of the TSF TOE offers TSF protection functions through secure management. Through internal tests, it ensures the integrity of sensitive data saved in the card and maintains the safe state upon failure through automatic recovery. [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 79/80 8. Annex 8.1 References [R1] Korea IT Security Evaluation and Certification Scheme, Ministry of Public Administration and Security Notice No. 2009-52, 2009. 9. 1 [R2] Korea IT Security Evaluation and Certification Guidance, Ministry of Public Administration and Security Notice No. 2009-51, 2009. 9. 1 [R3] Common Criteria for Information Technology Security Evaluation, Part 1, Version 3.1, Revision 3, July 2009, CCMB-2009-07-001 [R4] Common Criteria for Information Technology Security Evaluation, Part 2, Version 3.1, Revision 3, July 2009, CCMB-2009-07-002 [R5] Common Criteria for Information Technology Security Evaluation, Part 3, Version 3.1, Revision 3, July 2009, CCMB-2009-07-003 [R6] Smart Card Open Platform Protection Profile V2.1, 2010. 6. 10 [R7] Java CardTM System Protection Profile Collection Version 1.0b, Sun Microsystems, August 2003 [R8] Protection Profile Smart Card IC with Multi-Application Secure Platform Version 2.0, European Smart Card Industry Association, November 2000 [R9] Smart Card Protection Profile Version 3.0(SCSUG-SCPP), Smart Card Security User Group, September 2001 [R10] GlobalPlatform 2.1.1 Card Specification (March 2003), including Amendment A and Errata Precision List 1.3(December 2004) [R11] Visa GlobalPlatform 2.1.1 Card Implementation Requirements, Version 2.0, July 2007 [R12] Application Programming Interface, Java CardTM Platform, Version 2.2.2, March 2006, Sun Microsystems [R13] Runtime Environment Specification, Java CardTM Platform, Version 2.2.2, March 2006, Sun Microsystems [R14] Virtual Machine Specification, Java CardTM Platform, Version 2.2.2, March 2006, Sun Microsystems [R15] Security Target Lite of S3CC9GC 16-bit RISC Microcontroller For Smart Cards, Version 1.0 13th February, 2007, BSI-DSZ-CC-0438-2007 [R16] Security Target Lite of S3CC9LC 16-bit RISC Microcontroller For Smart Cards Version 1.2 14th January 2009, BSI-DSZ-CC-0501-2008-MA-04 [R17] FIPS PUB 180-1: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, SECURE HASH STANDARD, 1995 April 17 [R18] FIPS PUB 180-2: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, SECURE HASH STANDARD, 2002 August 1 [R19] FIPS PUB 197: Federal Information Processing Standards Publication 197, Announcing the ADVANCED ENCRYPTION STANDARD (AES), November 26, 2001 [R20] FIPS PUB 46-3: FEDERAL INFORMATION PROCESSING STANDARDS PUBLICATION, DATA ENCRYPTION STANDARD (DES), Reaffirmed 1999 October 25, U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology [R21] PKCS #1: RSA Encryption Standard, An RSA Laboratories Technical Note, Version 2.1, June 14, 2002 [JK11 [JK11 [JK11 [JK11- - - -T T T TR R R R- - - -000 000 000 0001] 1] 1] 1] Security Target Security Target Security Target Security Target- - - -Lite Lite Lite Lite 80/80 [R22] ISO/IEC 9796-2:2002: Information technology – Security techniques – Digital signature schemes giving message recovery – Part 2: Integer factorization based mechanisms [R23] ISO/IEC 9797-1:1999: Information technology – Security techniques – Message Authentication Codes (MACs) – Part 1: Mechanisms using a block cipher [R24] Bundesanzeiger Nr. 59, Bekanntmachung zur elektronischen Signatur nach dem Signaturgesetz und der Signaturverordnung (Übersicht über geeignete Algorithmen), Regulierungsbehörde für Telekommunikation und Post, 2005-03-30 [R25] Electronic Signatures and Infrastructures (ESI); Algorithms and Parameters for Secure Electronic Signatures; Part 1: Hash functions and asymmetric algorithms, ETSI TS 102 176-1 V1.2.1 (2005-07) [R26] Security Target Lite of Samsung S3CC9LC 16-bit Secure RISC Microcontroller For Smart Cards Version with optional Secure RSA and ECC Library including IC Dedicated Software, Version 1.4, 15th December 2009, BSI-DSZ-CC-0624-2010-MA-04 [R27] American National Standard X9.62-2005, Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA), November 16, 2005. [R28] American National Standard X9.63-2001, Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography, November 20, 2001. [R29] ISO/IEC 9796-1: Information technology – Security techniques – Digital signature schemes giving message recovery – Part 1: Mechanisms using redundancy [R30] Visa GlobalPlatform 2.1.1 Card Production Guide Version 1.03, April 2007 8.2 Abbreviated terms CC Common Criteria CPU Central Processing Unit EAL Evaluation Assurance Level EEPROM Electrically Erasable Programmable Read-Only Memory IC Integrated Circuit IFD Interface Device PCD Proximity Coupling Device PICC Proximity Card RF Radio Frequency RAM Random Access Memory ROM Read-Only Memory SFP Security Function Policy TOE Target of Evaluation TSF TOE Security Functionality