Java Cards

NXP JCOP 4 Security Target Lite v3.4 4

2020-07-14 16:05:44 M&W SmartCard 0

4       Security Problem Definition (ASE_SPD)

4.1   Assets

Assets are security-relevant elements to be directly protected by the TOE. Confidentiality of assets is always intended with respect to un-trusted people or software, as various parties are involved during the first stages of the smart card product life-cycle. Details concerning the threats are given in Section 4.2 hereafter.

Assets have to be protected, some in terms of confidentiality and some in terms of integrity or both integrity and confidentiality. These assets might get compromised by the threats that the TOE is exposed to.

The assets to be protected by the TOE are listed below. They are grouped according to whether it is data created by and for the user (User data) or data created by and for the TOE (TSF data). This definition of grouping is taken from Section 5.1 of [13].

4.1.1 User Data

D.APP_CODE

The code of the applets and libraries loaded on the card. To be protected from unauthorized modification.

D.APP_C_DATA

Confidentiality - sensitive data of the applications, like the data contained in an object, a static field of a package, a local variable of the currently executed method, or a position of the operand stack. To be protected from unauthorized disclosure.

D.APP_I_DATA

Integrity sensitive data of the applications, like the data contained in an object and the PIN security attributes (PIN Try limit, PIN Try counter and State). To be protected from unauthorized modifica- tion

D.APP_KEYS

Cryptographic keys owned by the applets. To be protected from unauthorized disclosure and modification.

D.APSD_KEYS

Refinement of D.APP_KEYS of [13]. Application Provider Se-curity Domains cryptographic keys needed to establish secure channels with the AP. These keys can be used to load and install applications on the card if the Security Domain has the appropri-ate privileges. To be protected from unauthorized disclosure and modification.

D.ISD_KEYS

Refinement of D.APP_KEYS of [13]. Issuer Security Domain cryptographic keys needed to perform card management oper-ations on the card. To be protected from unauthorized disclosure and modification.

D.VASD_KEYS

Refinement of D.APP_KEYS of [13]. Verification Authority Se-curity Domain cryptographic keys needed to verify applications Mandated DAP signature. To be protected from unauthorized disclosure and modification.

D.CARD_MNGT_DATA

The data of the card management environment, like for instance, the identifiers, the privileges, life cycle states. To be protected from unauthorized modification.

D.PIN

Any end-user’s PIN. To be protected from unauthorized disclo-sure and modification.


Tab. 4.1: User Data Assets

4.1.2 TSF Data

D.API_DATA

Private data of the API, like the contents of its private fields. To be protected from unauthorized disclosure and modification.

D.CRYPTO

Cryptographic data used in runtime cryptographic computations, like a seed used to generate a key. To be protected from unau-thorized disclosure and modification.

D.JCS_CODE

The code of the Java Card System. To be protected from unau-thorized disclosure and modification.

D.JCS_DATA

The internal runtime data areas necessary for the execution of the JCVM, such as, for instance, the frame stack, the program counter, the class of an object, the length allocated for an array, any pointer used to chain data-structures. To be protected from

D.SEC_DATA

The runtime security data of the JCRE, like, for instance, the AIDs used to identify the installed applets, the currently selected applet, the current context of execution and the owner of each object. To be protected from unauthorized disclosure and modifi-cation.

D.CONFIG_ITEM

A configuration that can be changed using the Configuration Mechanism.

D.MODULE_CODE

The code of a Module. The code of a module might comprise Java code, native code, code of a native Library or a combina-tion of them. To be protected against unauthorized disclosure and modification. Further to be protected against unauthorized removal or presence forgery.

D.MODULE_DATA

Private data of a Module, like the contents of its private fields. To be protected from unauthorized disclosure and modification.

D.ATTACK_COUNTER

The Attack Counter is incremented when a potential attack is de-tected. When the Attack Counter reaches its limit, the card goes into restricted mode.


Tab. 4.2: TSF Data Assets

4.2   Threats

4.2.1 Confidentiality

T.CONFID-APPLI-DATA                    Confidentiality of Application Data

The attacker executes an application to disclose data belonging to another ap-plication. See SA.CONFID-APPLI-DATA for details. Directly threatened asset(s): D.APP_C_DATA, D.PIN and D.APP_KEYS.

T.CONFID-JCS-CODE                      Confidentiality of Java Card System Code

The attacker executes an application to disclose the Java Card System code. See SA.CONFID-JCS-CODE for details. Directly threatened asset(s): D.JCS_CODE and D.MODULE_CODE.

T.CONFID-JCS-DATA                      Confidentiality of Java Card System Data

The attacker executes an application to disclose data belonging to the Java Card System. See SA.CONFID-JCS-DATA for details. Directly threatened asset(s): D.API_DATA, D.SEC_DATA, D.JCS_DATA, D.CRYPTO and D.MODULE_CODE.

4.2.2 Integrity

T.INTEG-APPLI-CODE

Integrity of Application Code


The attacker executes an application to alter (part of) its own code or another application’s code. See SA.INTEG-APPLI-CODE for details. Directly threatened asset(s): D.APP_CODE and D.MODULE_CODE.

T.INTEG-APPLI-CODE.LOAD

Integrity of Application Code - Load


The attacker modifies (part of) its own or another application code when an appli-cation package is transmitted to the card for installation. See SA.INTEG-APPLI- CODEfor details. Directly threatened asset(s): D.APP_CODE.

T.INTEG-APPLI-DATA[REFINED]

Integrity of Application Data


The attacker executes an application to alter (part of) another application’s data. See SA.INTEG-APPLI-DATA for details. Directly threatened asset(s): D.APP_I_ DATA, D.PIN, D.APP_KEYS, D.ISD_KEYS, D.VASD_KEYS and S.APSD_KEYS. This threat is a refinement of the Threat T.INTEG-APPLI-DATA from [13].

T.INTEG-APPLI-DATA.LOAD

Integrity of Application Data - Load


The attacker modifies (part of) the initialization data contained in an applica- tion package when the package is transmitted to the card for installation. See SA.INTEG-APPLI-DATA for details. Directly threatened asset(s): D.APP_I_DATA and D.APP_KEYS.

T.INTEG-JCS-CODE

Integrity of Java Card System Code


The attacker executes an application to alter (part of) the Java Card System code. See SA.INTEG-JCS-CODE for details. Directly threatened asset(s): D.JCS_CODE and D.MODULE_CODE.

T.INTEG-JCS-DATA

Integrity of Java Card System Data


The attacker executes an application to alter (part of) Java Card System or API data. See SA.INTEG-JCS-DATAfor details. Directly threatened asset(s): D.API_ DATA, D.SEC_DATA, D.JCS_DATA, D.CRYPTO and D.MODULE_DATA.

4.2.3Identity Usurpation

T.SID.

Subject Identification


An applet or Module impersonates another application or Module, or even the Java Card RE, in order to gain illegal access to some resources of the card or with respect to the end user or the terminal. See SA.SID and SA.MODULAR- DESIGNfor details. Directly threatened asset(s): D.SEC_DATA (other assets may be jeopardized should this attack succeed, for instance, if the identity of the JCRE is usurped), D.PIN and D.APP_KEYS.

T.SID.

Subject Identification


The attacker modifies the TOE’s attribution of a privileged role (e.g. default ap-plet and currently selected applet), which allows illegal impersonation of this role. See SA.SIDfor further details. Directly threatened asset(s): D.SEC_DATA (any other asset may be jeopardized should this attack succeed, depending on whose identity was forged).

4.2.4 Unauthorized Execution

T.EXE-CODE.                                Code Execution

An applet performs an unauthorized execution of a method. See SA.EXE-JCS- CODEand SA.EXE-APPLI-CODE for details. Directly threatened asset(s): D.APP_ CODE.

T.EXE-CODE.                                Code Execution

An applet performs an execution of a method fragment or arbitrary data. See SA.EXE-JCS-CODE and SA.EXE-APPLI-CODE for details. Directly threatened asset(s):D.APP_CODE.

T.NATIVE                                       Native Code Execution

An applet executes a native method to bypass a TOE Security Function such as the firewall. See SA.NATIVE for details. Directly threatened asset(s): D.JCS_ DATA.

T.MODULE_EXECCode Execution of Modules

The attacker bypasses the presence check of a not present Module with TOE internal interface to execute arbitrary code. See SA.MODULAR-DESIGNand SA.MODULE-INVOCATIONfor details. Directly threatened asset(s): D.MODULE_ CODE.

4.2.5 Denial of Service

T.RESOURCES                               Consumption of Resources

An attacker prevents correct operation of the Java Card System through consump- tion of some resources of the card: RAM or NVRAM. See SA.RESOURCES for details. Directly threatened asset(s): D.JCS_DATA.

4.2.6 Card Management

T.UNAUTHORIZED_CARD_MNGT     Unauthorized Card Management

The attacker performs unauthorized card management operations (for instance impersonates one of the actor represented on the card) in order to take benefit of the privileges or services granted to this actor on the card such as fraudulent:

•load of a package file

•installation of a package file

•extradition of a package file or an applet

•personalization of an applet or a Security Domain

•deletion of a package file or an applet

•privileges update of an applet or a Security Domain

Directly threatened asset(s): D.ISD_KEYS, D.APSD_KEYS, D.APP_C_DATA, D.APP_ I_DATA, D.APP_CODE, D.SEC_DATA, and D.CARD_MNGT_DATA (any other as- set may be jeopardized should this attack succeed, depending on the virulence of the installed application).

This security objective is a refinement of the Threats T.INSTALL and T.DELETION from [13].

T.COM_EXPLOIT                             Communication Channel Remote Exploit

An attacker remotely exploits the communication channels established between a third party and the TOE in order to modify or disclose confidential data.

All assets are threatened.

T.LIFE_CYCLE                                Life Cycle

An attacker accesses to an application outside of its expected availability range thus violating irreversible life cycle phases of the application (for instance, an at- tacker repersonalizes the application). Directly threatened asset(s): D.APP_I_ DATA, D.APP_C_DATA, and D.CARD_MNGT_DATA.

4.2.7 Services

T.OBJ-DELETION                            Object Deletion

The attacker keeps a reference to a garbage collected object in order to force the TOE to execute an unavailable method, to make it to crash, or to gain access to a memory containing data that is now being used by another application. See SA.OBJ-DELETION for further details. Directly threatened asset(s): D.APP_C_ DATA, D.APP_I_DATA and D.APP_KEYS.

4.2.8 Miscellaneous

T.PHYSICAL                                   Physical Tampering

The attacker discloses or modifies the design of the TOE, its sensitive data or application code by physical (opposed to logical) tampering means. This threat in- cludes IC failure analysis, electrical probing, unexpected tearing, and Differential Power Analysis (DPA). That also includes the modification of the runtime execution of Java Card System or SCP software through alteration of the intended execution order of (set of) instructions through physical tampering techniques. This threat- ens all the identified assets. This threat refers to the point (7) of the security aspect SA.SCP, and all aspects related to confidentiality and integrity of code and data. Application note: If sensitive result is supported by the TOE, this threat covers the following sub- threat exploiting specifically the listed assets below:

•The attacker performs a physical manipulation to alter (part of) an applica-tion’s integrity-sensitive data. See SA.INTEG-APPLI-DATA-PHYS for details. Directly threatened asset(s): D.APP_I_DATA, D.PIN, and D.APP_KEYS.

4.2.9 Operating System

T.OS_OPERATE                              Incorrect Operating System Behavior

Modification of the correct OS behavior by unauthorized use of TOE or use of incorrect or unauthorized instructions or commands or sequence of commands, in order to obtain an unauthorized execution of the TOE code. An attacker may cause a malfunction of TSF or of the Smart Card embedded OS in order to (1) by- pass the security mechanisms (i.e. authentication or access control mechanisms) or (2) obtain unexpected result from the embedded OS behavior. Different kind of attack path may be used as:

1. Applying incorrect unexpected or unauthorized instructions, commands or command sequences,

2. Provoking insecure state by insertion of interrupt (reset), premature termina-tion of transaction or communication between IC and the reading device

Info:Any implementation flaw in the OS itself can be exploited with this attack path to lead to an unsecured state of the state machine of the OS. The attacker uses the available interfaces of the TOE. A user could have certain specified priv- ileges that allow loading of selected programs. Unauthorized programs, if allowed to be loaded, may include either the execution of legitimate programs not intended for use during normal operation (such as patches, filters, Trojan horses, etc.) or the unauthorized loading of programs specifically targeted at penetration or mod- ification of the security functions. Attempts to generate a non-secure state in the Smart Card may also be made through premature termination of transactions or communications between the IC and the card reading device, by insertion of in- terrupts, or by selecting related applications that may leave files open.

4.2.10 Random Numbers

T.RND               &nnbsp;                           Deficiency of Random Numbers

An attacker may predict or obtain information about random numbers generated by the TOE for instance because of a lack of entropy of the random numbers pro- vided. An attacker may gather information about the produced random numbers which might be a problem because they may be used for instance to generate cryptographic keys. Here the attacker is expected to take advantage of statis- tical properties of the random numbers generated by the TOE without specific knowledge about the TOE’s generator. Malfunctions or premature ageing are also considered which may assist in getting information about random numbers.

4.2.11 Configuration Module

T.CONFIG                                      Unauthorized configuration

The attacker tries to change configuration items without authorization. Directly threatened asset(s): D.CONFIG_ITEM.

4.2.12 Secure Box

T.SEC_BOX_BORDER                    SecureBox Border Infringement

An attacker may try to use malicious code placed in the Secure Box to modify the correct behavior of the Operating System (OS). With the aim to

1. disclose the Java Card System code,

2.disclose or alter applet code, disclose or alter Java Card System data, or disclose or alter applet data.

4.2.13Module replacement

T.MODULE_REPLACEMENT            Replacement of Module

An attacker loads a Module with functionality differing from a previously deleted Module to bypass TOE Security Functions. See SA.MODULAR-DESIGNfor de-tails. Directly threatened assets: D.JCS_DATA.

4.2.14 Restricted Mode

T.ATTACK-COUNTER                      Modification of the Attack Counter

The attacker tries to modify the attack counter without authorization. Directly threatened asset: D.ATTACK_COUNTER.

4.3   Organisational Security Policies

OSP.VERIFICATION

File Verification


This policy is upheld by the security objective of the environment OE.VERIFICATION which guarantees that all the bytecodes shall be verified at least once, before the loading, before the installation or before the execution in order to ensure that each bytecode is valid at execution time. This policy is also upheld by the security objective of the environment OE.CODE-EVIDENCE which ensures that evidences exist that the application code has been verified and not changed after verification, and by the security objective for the TOE O.LOAD which shall ensure that the loading of a package into the card is safe.

OSP.PROCESS-TOE

Identification of the TOE


An accurate identification must be established for the TOE. This requires that each instantiation of the TOE carries this identification.

OSP.KEY-CHANGE

Security Domain Keys Change


The Application Provider (AP) shall change its initial security domain keys (APSD) before any operation on its Security Domain.

OSP.SECURITY-DOMAINS

Security Domains


Security domains can be dynamically created, deleted and blocked during usage phase in post-issuance mode.

OSP.SECURE-BOX

Secure Box Border


Execution of untrusted native code shall be possible without any harm, manipula-tion, or influence on other parts of the TOE.

4.4   Assumptions

Note that the assumption A.DELETION is excluded. The Card Manager is part of the TOE and therefore the

assumption is no longer relevant.

A.APPLET                           Applets without Native Methods

Applets loaded post-issuance do not contain native methods. The Java Card spec- ification explicitly ”does not include support for native methods” ([40]) outside the API.

A.VERIFICATION                 Bytecode Verification

All the bytecodes are verified at least once, before the loading, before the installa- tion or before the execution, depending on the card capabilities, in order to ensure that each bytecode is valid at execution time.

A.USE_DIAG                        Usage of TOE’s Secure Communication Protocol by OE

It is assumed that the operational environment supports and uses the secure com- munication protocols offered by the TOE.

A.USE_KEYS                        Protected Storage of Keys Outside of TOE

It is assumed that the keys which are stored outside the TOE and which are used for secure communication and authentication between Smart Card and terminals are protected for confidentiality and integrity in their own storage environment. This is especially true for D.APSD_KEYS, D.ISD_KEYS, and D.VASD_KEYS.

Info:This is to assume that the keys used in terminals or systems are correctly protected for confidentiality and integrity in their own environment, as the disclo- sure of such information which is shared with the TOE but is not under the TOE control, may compromise the security of the TOE.

A.PROCESS-SEC-IC

Protection during Packaging, Finishing and Personalisation


It is assumed that security procedures are used after delivery of the TOE by the TOE Manufacturer up to delivery to the end consumer to maintain confidentiality and integrity of the TOE and of its manufacturing and test data (to prevent any possible copy, modification, retention, theft or unauthorised use). This means that the Phases after TOE Delivery are assumed to be protected appropriately. The assets to be protected are: The information and material produced and/or processed by the Security IC Embedded Software Developer in Phase 1 and by the Composite Product Manufacturer can be grouped as follows:

1. the Security IC Embedded Software including specifications, implementation and related documentation,

2. pre-personalisation and personalisation data including specifications of for-mats and memory areas, test related data,

3. the User Data and related documentation, and

4. material for software development support as long as they are not under the control of the TOE Manufacturer.

A.APPS-PROVIDER

Application Provider


The AP is a trusted actor that provides basic or secure applications. He is respon- sible for his security domain keys (APSD keys).

Info: An AP generally refers to the entity that issues the application. For instance it can be a financial institution for a payment application such as EMV or a transport operator for a transport application.

A.VERIFICATION-AUTHORITY

Verification Authority


The VA is a trusted actor who is able to guarantee and check the digital signature attached to a basic or secure application.

Info: As a consequence, it guarantees the success of the application validation upon loading.

9    Contents

1 ST Introduction (ASE_INT)

1.1 ST Reference and TOE Reference

1.2 TOE Overview


1.2.1 Usage and Major Security Features of the TOE

1.2.2 TOE Type

1.2.3 Required non-TOE Hardware/Software/Firmware

1.3 TOE Description


1.3.1 TOE Components and Composite Certi fication

1.3.2 Optional TOE Functionality

1.3.3 TOE Life Cycle

1.3.4 TOE Identification

1.3.5 Evaluated Package Types


2 Conformance Claims (ASE_CCL)


2.1 CC Conformance Claim

2.2 Package Claim

2.3 PP Claim

2.4 Conformance Claim Rationale


2.4.1 TOE Type

2.4.2 SPD Statement

2.4.3 Security Objectives Statement

2.4.4 Security Functional Requirements State ment

3 Security Aspects


3.1 Confidentiality

3.2 Integrity

3.3 Unauthorized Executions

3.4 Bytecode Verification

3.5 Card Management

3.6 Services

3.7 External Memory

3.8 Configuration Module

3.9 Modular Design

3.10 Restricted Mode

4 Security Problem Definition (ASE_SPD)


4.1 Assets


4.1.1 User Data

4.1.2 TSF Data

4.2 Threats


4.2.1 Confidentiality

4.2.2 Integrity

4.2.3 Identity Usurpation

4.2.4 Unauthorized Execution

4.2.5 Denial of Service

4.2.6 Card Management

4.2.7 Services

4.2.8 Miscellaneous

4.2.9 Operating System

4.2.10 Random Numbers

4.2.11 Configuration Module

4.2.12 Secure Box

4.2.13 Module replacement

4.2.14 Restricted Mode

4.3 Organisational Security Policies

4.4 Assumptions

5 Security Objectives


5.1 Security Objectives for the TOE


5.1.1 Identification

5.1.2 Execution

5.1.3 Services

5.1.4 Object Deletion

5.1.5 Applet Management

5.1.6 External Memory

5.1.7 Card Management

5.1.8 Smart Card Platform

5.1.9 Secure Box

5.1.10 Random Numbers

5.1.11 Configuration Module

5.1.12 Restricted Mode

5.2 Security Objectives for the Operational Environment

5.3 Security Objectives Rationale


5.3.1 Threats

5.3.2 Organisational Security Policies

5.3.3 Assumptions


6 Extended Components Definition (ASE_ECD)


6.1 Definition of Family ”Audit Data Storage (FAU_SAS)”

6.2 Definition of Family ”TOE emanation (FPT_EMSEC)”

7 Security Requirements (ASE_REQ)


7.1 Definitions


7.1.1 Groups

7.1.2 Subjects

7.1.3 Objects

7.1.4 Informations

7.1.5 Security Attributes

7.1.6 Operations

7.2 Security Functional Requirements


7.2.1 COREG_LC Security Functional Requirements

7.2.2 INSTG Security Functional Requirements

7.2.3 ADELG Security Functional Requirements

7.2.4 RMIG Security Functional Requirements

7.2.5 ODELG Security Functional Requirements

7.2.6 CarG Security Functional Requirements .

7.2.7 EMG Security Functional Requirements .

7.2.8 ConfG Security Functional Requirements

7.2.9 SecBoxG Security Functional Requirements

7.2.10 ModDesG Security Functional Requirements

7.2.11 RMG Security Functional Requirements .

7.2.12 Further Security Functional Requirements

7.3 Security Assurance Requirements

7.4 Security Requirements Rationale for the TOE


7.4.1 Identification

7.4.2 Execution

7.4.3 Services

7.4.4 Object Deletion

7.4.5 Applet Management

7.4.6 External Memory

7.4.7 Card Management

7.4.8 Smart Card Platform

7.4.9 Random Numbers

7.4.10 Configuration Module

7.4.11 Secure Box

7.4.12 Restricted Mode

7.5 SFR Dependencies


7.5.1 Rationale for Exclusion of Dependencies


7.6 Security Assurance Requirements Rationale

8 TOE summary specification (ASE_TSS)


8.1 Introduction

8.2 Security Functionality

8.3 Protection against Interference and Logical Tampering

8.4 Protection against Bypass of Security Related Actions

9 Contents

10 Glossary

11 Acronyms

12 Bibliography

13 Legal information


13.1 Definitions

13.2 Disclaimers

13.3 Licenses

13.4 Patents

13.5 Trademarks

Java Card is an open standard from Sun Microsystems for a smart card developmentplatform. Smart cards created using the Java Card platform have Java applets stored on them. The applets can be added to or changed after the card is issued.

There are two basic types of smart cards. The memory smart card is the familiar removable memory device; it usually features read and write capabilities and perhaps security features. The more complex version, the processor smart card, is a very small and extremely portable computing device that could be carried in your wallet. Java-based smart cards belong to the latter category. They store data on an integrated microprocessor chip. Applets are loaded into the memory of the microprocessor and run by the Java Virtual Machine. Similarly to MULTOS, another smart card development technology, Java Card enables multiple application programs to be installed and coexist independently. Individual applets are protected by a firewall to preserve their integrity and prevent tampering. Applications can be updated dynamically.

In the United States, the Department of Defense, Visa, and American Express are among the organizations creating Java Card-based applications.


Home
Product
News
Contact us